strict aliasing question

Howard Chu hyc@highlandsun.com
Fri Nov 10 22:33:00 GMT 2006


Mike Stump wrote:
> On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
>> Richard Guenther wrote:
>>> If you compile with -O3 -combine *.c -o alias it will break.
>
>> Thanks for pointing that out. But that's not a realistic danger for 
>> the actual application. The accessor function is always going to be 
>> in a library compiled at a separate time. The call will always be 
>> from a program built at a separate time, so -combine isn't a factor.
>
> We are building a compiler to outsmart you.  We presently working on 
> technology (google ("LTO")) to break your code.  :-)  Don't cry when 
> we turn it on by default and it does.  I'd recommend understanding the 
> rules and following them.
>
Heh heh. Looking forward to using that. Google further back and you'll 
see that I did link time optimization with gcc 1.4 for m68k/Atari, 
almost 20 years ago. More power to you. (Why in my day, we had to carry 
bitbuckets twenty miles uphill, BOTH DIRECTIONS!)

As for following the rules, I didn't define the SASL API. It strikes me 
that (void **) is pretty unfriendly as an argument type. While it's easy 
to make the warning go away with a union, that doesn't actually 
guarantee that the memory being pointed to will be in a defined state.

With the previous example, if alias1.c was instead:

####
#include <stdio.h>

extern void getit( void **arg );

main() {
        union {
                int *foo;
                void *bar;
        } u;

        getit( &u.bar );
        printf("foo: %x\n", *u.foo);
}
####

gcc no longer complains, but according to the spec, the code is not any 
more reliable.

On the other hand, I don't see any good reason for an optimizer to break 
this code. The compiler knows absolutely that the two pointers have 
identical values and therefore point to the same piece of memory. There 
is no way it can legitimately squash out any loads or stores here - it's 
not executing in a loop, where a prior load may have already fetched the 
data.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/



More information about the Gcc mailing list