dereferencing type-punned pointer will break strict-aliasing rules

[jorba101]

I'm developing an application with GCC 3.4 for ARM7.

When doing following:

T_f32 temp_f32;
T_u32 temp_u32;
 
temp_u32 = *((T_u32 *) &temp_f32);

(where T_u32 is unsinged int, and T_f32 is 32-bit is float)

I'm getting following warning:

dereferencing type-punned pointer will break strict-aliasing rules

It only happens using -O2 optimization (-O0 reports no warning)

What is exactly strict aliasing? So far, I know there's lot of stuff to be taken into account regarding the way ARM aligns pointers. I do the code above to get a temp_u32 containing the four bytes in the float, as they come. Am I going to have trouble?

[JosAH]

Aliasing or anti aliasing is a subject that never made it in any of the C Standards.
The intention was what the compiler could keep track of pointers pointing to
something and that something itself (two aliases). It was shown that a compiler
can't do that and your code is an example thereof.

Unless one of the types has a stricter alignment than the other, you can safely
copy the 32 bits of a float to the 32 bits of your unsigned int. Note that alignment
has nothing to do with aliasing.

Concluding: there's no need to worry; gcc tries to be more law obedient than
the actual law.

kind regards,

Jos

[RRick]

Any idea why -O2 optimization would turn on this warning?

My guess is that some code optimization is tiggered by this code.

[jorba101]

Wait wait.

I'm not so sure now it's the optimization. The warning appeared when I changed my makefile from debug to release.

The change from -O0 to -O2 is only one of the changes (so, I incorrectly said that it was the only). I'll double check what is the change that actually produces that (on monday, at work), and post it here.

[JosAH]

Wait wait.

I'm not so sure now it's the optimization. The warning appeared when I changed my makefile from debug to release.

The change from -O0 to -O2 is only one of the changes (so, I incorrectly said that it was the only). I'll double check what is the change that actually produces that (on monday, at work), and post it here.

The DEBUG flag could also have affected the -O flag: suppose the compiler had
figured out that, say, an int* ip was an alias for an int i; in debug mode you
would've been surprised to see variable i being changed if in your opinion just
the value *ip was changed. The compiler could've turned off that strict aliasing
rule. In release mode however, if the above was true, a direct change of variable
i would've been legitimate but your other code (see your OP) breaks that strict
aliasing rule and your compiler warns you for it.

According to the Standard, a compiler is allowed to issue warning diagnostic
messages whenever and whereever it wants so that could explain it all.

kind regards,

Jos

[Joinz]

I just add '-fno-strict-aliasing' in Makefile.

[Patrick Horgan]

Short answer,
struct either{
T_f32 asf32;
T_u32 asu32;
};
struct either e;
e.asu32=temp_u32;
temp_f32=e.asf32;

Or you could use memcpy casting each to char * since
a char* can alias anything.

Long answer, http://dbp-consulting.com/StrictAliasing.pdf, a white paper I wrote because this question comes up over and over. It explains what strict aliasing is and isn't, why developers get confused about it, why it's needed for good optimization, and how to do the sorts of things that people want to do that come afoul of strict-aliasing rules.

Patrick