This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Undefined behavior due to 6.5.16.1p3


On 03/11/2015 07:27 AM, Robbert Krebbers wrote:
Dear Joseph,

On 03/10/2015 11:01 PM, Joseph Myers wrote:
and did "u.b.b2 = f (u.a);" instead of "u.b.b2 = u.a;", that would not be
undefined (see 6.8.6.4 and GCC PR 43784).
Thanks for the references, those are useful!

But what about "long long" on 32 bits machines. For example:

union {
   long long a;
   struct { char b1; long long b2; } b;
} u;

Will GCC perform similar optimizations as for the case of big structs? I
tried to play around with long long in Martin's example, but failed to
trigger "unexpected" behaviors in GCC.

Whether or not this will preserve the source value will depend
on the alignment of long long (32 or 64 bits) and on how gcc
decides to copy the contents of the operands.

Commonly 8-byte aligned long longs will not overlap in the union
above so the value will always be preserved.

When long long is aligned on a 4 byte boundary (as in the i386
ABI) the two long long members will overlap, but if the whole
source operand is read into a pair of registers first and only
then written out into the destination operand then the original
value will also be preserved.

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]