https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116357
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|tree-optimization |c
Last reconfirmed| |2024-09-17
CC| |jsm28 at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
The optimization issue is because we have an element type that looks like
<integer_type 0x7ffff69b27e0 spinlock_t volatile unsigned SI
size <integer_cst 0x7ffff6824198 type <integer_type 0x7ffff68220a8
bitsizetype> constant 32>
unit-size <integer_cst 0x7ffff68241b0 type <integer_type 0x7ffff6822000
sizetype> constant 4>
user align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff69b2738 precision:32 min <integer_cst 0x7ffff68241c8 0> max <integer_cst
0x7ffff6824180 4294967295>
pointer_to_this <pointer_type 0x7ffff69dd540>>
in particular with TYPE_ALIGN > TYPE_SIZE which is a "cannot happen". Because
ARRAY_REF records the element size in units of element alignment this ends
up as zero ...
In this case value-numbering makes ARRAY_REF OP2 explicit while keeping it
implicit ends up being "fine" (fine as in still densely packing
spinlock_t and thus giving elements wrong alignment).
I wonder whether the bug is that sizeof (spinlock_t) is 4, but of course
that might be difficult to change. But I suppose this is also how C works;
possibly the C frontend should build a variant type of the element type
if over-alignment should be ignored - putting in the over-aligned type
most definitely breaks the middle-end with regard to how ARRAY_REF is
defined.
This is a C frontend issue, it produces wrong GENERIC.
