Arnd,
I just noticed this on stable@. Do you have more of the gcc-13-enum
patches? I sent some (this one incl.), but didn't have time for v2 of
some of them. So should I respin the rest or have you fixed them all yet?
> [PATCH] ath11k (gcc13): synchronize
ath11k_mac_he_gi_to_nl80211_he_gi()'s return type - "Jiri Slaby (SUSE)"
<jirislaby@xxxxxxxxxx> - 2022-10-31 1243.eml:Message-Id:
<20221031114341.10377-1-jirislaby@xxxxxxxxxx>
> [PATCH] block_blk-iocost (gcc13): cast enum members to int in prints
- "Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1245.eml:Message-Id: <20221031114520.10518-1-jirislaby@xxxxxxxxxx>
> [PATCH] bonding (gcc13): synchronize bond_{a,t}lb_xmit() types -
"Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1244.eml:Message-Id: <20221031114409.10417-1-jirislaby@xxxxxxxxxx>
> [PATCH] drm_amd_display (gcc13): fix enum mismatch - "Jiri Slaby
(SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31 1242.eml:Message-Id:
<20221031114247.10309-1-jirislaby@xxxxxxxxxx>
> [PATCH] drm_nouveau_kms_nv50- (gcc13): fix nv50_wndw_new_ prototype -
"Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1242.eml:Message-Id: <20221031114229.10289-1-jirislaby@xxxxxxxxxx>
> [PATCH] init: Kconfig (gcc13): disable -Warray-bounds on gcc-13 too -
"Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1242.eml:Message-Id: <20221031114212.10266-1-jirislaby@xxxxxxxxxx>
> [PATCH] i40e (gcc13): synchronize allocate_free functions return type
& values - "Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1244.eml:Message-Id: <20221031114456.10482-1-jirislaby@xxxxxxxxxx>
> [PATCH] qed (gcc13): use u16 for fid to be big enough - "Jiri Slaby
(SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31 1243.eml:Message-Id:
<20221031114354.10398-1-jirislaby@xxxxxxxxxx>
> [PATCH] RDMA_srp (gcc13): force int types for max_send_sge and
can_queue - "Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1245.eml:Message-Id: <20221031114506.10501-1-jirislaby@xxxxxxxxxx>
> [PATCH] sfc (gcc13): synchronize ef100_enqueue_skb()'s return type -
"Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1244.eml:Message-Id: <20221031114440.10461-1-jirislaby@xxxxxxxxxx>
> [PATCH] thunderbolt (gcc13): synchronize tb_port_is_clx_enabled()'s
2nd param - "Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1243.eml:Message-Id: <20221031114323.10356-1-jirislaby@xxxxxxxxxx>
> [PATCH] wireguard (gcc13): cast enum limits members to int in prints
- "Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1244.eml:Message-Id: <20221031114424.10438-1-jirislaby@xxxxxxxxxx>
> [PATCH 1_2] ata: ahci (gcc13): use BIT() for bit definitions in enum
- "Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1243.eml:Message-Id: <20221031114310.10337-1-jirislaby@xxxxxxxxxx>
> [PATCH 2_2] ata: ahci (gcc13): use U suffix for enum definitions -
"Jiri Slaby (SUSE)" <jirislaby@xxxxxxxxxx> - 2022-10-31
1243.eml:Message-Id: <20221031114310.10337-2-jirislaby@xxxxxxxxxx>
thanks,
On 06. 12. 22, 7:46, Damien Le Moal wrote:
On 12/3/22 19:54, Arnd Bergmann wrote:
From: Arnd Bergmann <arnd@xxxxxxxx>
gcc-13 slightly changes the type of constant expressions that are defined
in an enum, which triggers a compile time sanity check in libata:
linux/drivers/ata/libahci.c: In function 'ahci_led_store':
linux/include/linux/compiler_types.h:357:45: error: call to '__compiletime_assert_302' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
357 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
The new behavior is that sizeof() returns the same value for the
constant as it does for the enum type, which is generally more sensible
and consistent.
The problem in libata is that it contains a single enum definition for
lots of unrelated constants, some of which are large positive (unsigned)
integers like 0xffffffff, while others like (1<<31) are interpreted as
negative integers, and this forces the enum type to become 64 bit wide
even though most constants would still fit into a signed 32-bit 'int'.
Fix this by changing the entire enum definition to use BIT(x) in place
of (1<<x), which results in all values being seen as 'unsigned' and
fitting into an unsigned 32-bit type.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107917
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
Reported-by: Luis Machado <luis.machado@xxxxxxx>
Cc: linux-ide@xxxxxxxxxxxxxxx
Cc: Damien Le Moal <damien.lemoal@xxxxxxxxxxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
Cc: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
Applied to for-6.2. Thanks !
--
js
suse labs
