http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> 2013-04-03 07:55:34 UTC --- On Wed, 3 Apr 2013, ebotcazou at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 > > --- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-04-03 > 07:29:51 UTC --- > > Not sure if I can agree with (or understand) this comment. If we use my > > example > > of the address of an int in a packed structure being assigned to an int* > > then > > one could argue that there is a kind of implicit cast happening. The > > pointer is > > to an integer WITH the default alignment which would be 4 on the ARM system > > I > > work with. The int in the struct has an alignment of 1 and so the two types > > need to be regarded as being incompatible and there should be an > > unconditional > > warning or at least -Wcast-align should enable such a warning. > > Yes, a warning should probably be implemented in the C family of compilers, > but > this is a very old issue and nobody is really interested. Note that taking > the > address of the field is OK, the problem is dereferencing it. One of the C frontend issues is that the type of the address of the field of the packed struct is int *, not int attribute((aligned(1))) *. And this is so because nothing adjusts the type of the FIELD_DECL to be a less aligned type. That is, we have <field_decl 0x7ffff6d245f0 i type <integer_type 0x7ffff6d175e8 int public SI size <integer_cst 0x7ffff6d1a0c0 constant 32> unit size <integer_cst 0x7ffff6d1a0e0 constant 4> align 32 symtab 0 alias set -1 canonical type 0x7ffff6d175e8 precision 32 min <integer_cst 0x7ffff6d1a060 -2147483648> max <integer_cst 0x7ffff6d1a080 2147483647> pointer_to_this <pointer_type 0x7ffff6d1f2a0>> packed SI file t.c line 2 col 9 size <integer_cst 0x7ffff6d1a0c0 32> unit size <integer_cst 0x7ffff6d1a0e0 4> align 8 offset_align 128 offset <integer_cst 0x7ffff6d02d80 type <integer_type 0x7ffff6d17000 sizetype> constant 0> bit offset <integer_cst 0x7ffff6d02e00 type <integer_type 0x7ffff6d170a8 bitsizetype> constant 0> context <record_type 0x7ffff6e1c3f0 Foo>> and alignof (x.i) and alignof (*&x.i) would not agree (if the latter were not folded to x.i) for struct Foo { int i; } __attribute__((packed)) ; struct Foo x; for example (surprisingly) __alignof__ (*(char *)&x.i) is 4 while __alignof__ (*&x.i) is 1 (due to folding) and __alignof__ (x.i) is 1 as well. I'm quite sure that "fixing" this will have loads of fallout throughout the frontend(s if 'fixed' in stor-layout.c). Which is why this issue is so old and unfixed.
