This is the mail archive of the gcc-help@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: Some strict aliasing related fun


Thanks for the tips, Corey!

corey taylor wrote:
On Nov 27, 2007 9:09 PM, Raymond Sheh <rsheh@cse.unsw.edu.au> wrote:
whole thing goes random with -O3. Adding -fno-strict-aliasing makes it
work again but compiling with only -fstrict-aliasing doesn't break it so
it looks like a combination of things.

You don't see warnings with -fstrict-aliasing?
Now that you mention it, turning on "-W -Wall -fstrict-aliasing" does give a warning about "dereferencing type-punned pointer will break strict-aliasing rules" (but not if I don't turn on -W -Wall) ... for some reason I always thought "-W -Wall" warned about everything regardless of optimiser settings ... chalk one up to experience I guess!

float floatblah(float in)
{
unsigned long retval =
byte_manipulation_function_that_happens_to_take_ulongs(*((unsigned
long*)(&in)));
return *((float*)(&retval));
}

You realize of course, this is invalid for 64-bit since float is
32-bit and unsigned long is 64-bit on 64-bit linux.
Yup ... I'm not sure what the alternative is though given at the end of the day this has to go through htonl/ntohl in preparation for network transmission and I'm not aware of any word-length-transparent way of doing THAT ... of course, it's possibly more due to my ignorance than there actually not being a way, if there is I'd be most happy to find out! :-)

Why can't you use the union for type-punning here?
union { float a; unsigned long b; };
a = in;
b = im_not_typing_that(b);
return a;

corey
I could and will probably end up doing that ultimately ... I just was of the impression that the sort of casting I was using was reasonably widely accepted and was a little confused when it worked fine up until when I tried compiling it on a GCC 4.x system (at which point it gave me random stack-corrupting segfaults - always a pain to debug!) ... ah well ... I notice this sort of casting in a few other libraries I use - and I've just found that their autoconf'd makefiles all seem to have -fno-strict-aliasing in them so I might just do that for now so I can actually get some results!


Cheers!


- Raymond


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