This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RTL alias analysis
On Jan 22, 2006, Richard Guenther <richard.guenther@gmail.com> wrote:
> On 1/22/06, Alexandre Oliva <aoliva@redhat.com> wrote:
>> I don't think it is any different. GCC's exception for unions only
>> applies if the object is accessed using the union type. So they are
>> indeed equivalent. The scary thing is that I don't think they
>> actually violate the ISO C strict aliasing rules, but they might still
>> be mis-optimized by GCC, assuming I understand correctly what GCC
>> does.
> ISO C says that the following violates aliasing rules:
> int foo(float f) { union { int i; float f; } u; i.f = f; return i.i; }
Yes, but this was not what the example I quoted from Richard Sandiford
was about. The example only accessed a memory region using its
effective type:
> int ii; double dd; void foo (int *ip, double *dp) {
> *ip = 15; ii = *ip; *dp = 1.5; dd = *dp; }
> void test (void) { union { int i; double d; } u;
> foo (&u.i, &u.d); }
So it is perfectly valid, but if GCC reorders the read from *ip past
the store to *dp, it turns the valid program into one that misbehaves.
Unless the undefined behavior is taking the address of both u.i and
u.d, when only one of them is well-defined at that point. I don't
think taking the address of a member of a union counts as accessing
the stored value of the object, since if the member is volatile, a
read from memory is not expected.
> The correct solution for converting
> a float to an integer (bit-representation) as in the expample is to use
> two different memory locations and memcpy (which avoids aliasing
> issues by means of using the special rules for access through 'char').
It does avoid aliasing issues, but it does not avoid the propagation
of the effective type (see 6.5/6), so accessing the result of the copy
using a different type still invokes undefined behavior. It's just
that current compilers don't take advantage of this fact.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}