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: Vincent Lefevre <vincent+gcc at vinc17 dot org>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 11 Mar 2015 17:08:16 +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>
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...).
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)