http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55614
--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-07
14:57:28 UTC ---
> The difference from broken to working starts at the esra pass:
> <bb 3>:
> - MEM[(char * {ref-all})x_1].v = r$v_15;
> + MEM[(char * {ref-all})x_1] = r$v_15;
> x_8 = x_1 + 16;
> y_9 = y_2 + 18446744073709551600;
>
> Note that the MEM[(char * {ref-all})x_1] is
> <mem_ref 0x7ffff1a93d48
> type <union_type 0x7ffff1a9cb28 sizes-gimplified type_0 TI
> size <integer_cst 0x7ffff1982dc0 constant 128>
> unit size <integer_cst 0x7ffff1982de0 constant 16>
> align 8 symtab 0 alias set -1 canonical type 0x7ffff1a9c738
> fields <field_decl 0x7ffff19a45f0 v type <vector_type 0x7ffff1a9c498
> T>
> unsigned V4SI file rh885082.c line 7 col 13 size <integer_cst
> 0x7ffff1982dc0 128> unit size <integer_cst 0x7ffff1982de0 16>
> align 128 offset_align 128
> offset <integer_cst 0x7ffff1982d80 constant 0>
> bit offset <integer_cst 0x7ffff1982e00 constant 0> context
> <union_type 0x7ffff1a9c738>> context <function_decl 0x7ffff1a9ba00 foo>>
How can a union have alignment 8 if it contains a field with alignment 128?
That should only happen if the field is a bit-field...
> thus it has the right TYPE_ALIGN. But when it is wrapped into COMPONENT_REF,
> while the inner MEM_REF still has TYPE_ALIGN 8, the FIELD_REF has DECL_ALIGN
> 128, which is probably why the expansion expands it as aligned.
...in which case the expansion should expand it as a bit-field.
> If the r186501 patch is too risky for the release branches (did it need any
> follow-ups so far?), an alternative would be to start doing what trunk does
> only if the MEM_REF has lower alignment than the field.
I don't think that r186501 can be backported, unless you want to break again
the strict-alignment platforms. r161958 just fixed the disaster introduced on
them by an ealier patch, see PR middle-end/44843.
