This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Undefined behavior due to 6.5.16.1p3
- From: Jakub Jelinek <jakub at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 11 Mar 2015 17:11:55 +0100
- Subject: Re: Undefined behavior due to 6.5.16.1p3
- Authentication-results: sourceware.org; auth=none
- References: <54FDF3CE dot 6030507 at robbertkrebbers dot nl> <54FF195B dot 5060604 at redhat dot com> <54FF1F7C dot 5050501 at robbertkrebbers dot nl> <54FF2182 dot 1090800 at robbertkrebbers dot nl> <alpine dot DEB dot 2 dot 10 dot 1503102153590 dot 10726 at digraph dot polyomino dot org dot uk> <550042BD dot 8000608 at robbertkrebbers dot nl> <20150311160815 dot GA2967 at ypig dot lip dot ens-lyon dot fr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Mar 11, 2015 at 05:08:16PM +0100, Vincent Lefevre wrote:
> On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote:
> > 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.
>
> I've not tried, but how about something like:
>
> struct S { long a, b, c, d; };
> union U {
> struct S a;
> struct { char b1; struct S b2; } b;
> };
> u.b.b2 = u.a;
>
> or: u.a = u.b.b2;
>
> IMHO, struct S should be large enough to avoid using registers as
> a temporary area (just in case...).
There is some PR about it in our bugzilla, and the conclusion is that
it is both invalid (in C only one union member can be active at any time,
we as extension allow type punning through unions etc.)
and we really don't want to support it.
Jakub