470,596 Members | 1,573 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,596 developers. It's quick & easy.

dereferencing type-punned pointer will break strict-aliasing rules

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

When doing following:

Expand|Select|Wrap|Line Numbers
  1. T_f32 temp_f32;
  2. T_u32 temp_u32;
  3.  
  4. 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?
Jun 20 '08 #1
6 11454
JosAH
11,448 Expert 8TB
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
Jun 20 '08 #2
RRick
463 Expert 256MB
Any idea why -O2 optimization would turn on this warning?

My guess is that some code optimization is tiggered by this code.
Jun 20 '08 #3
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.
Jun 21 '08 #4
JosAH
11,448 Expert 8TB
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
Jun 22 '08 #5
I just add '-fno-strict-aliasing' in Makefile.
Oct 9 '10 #6
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
Dec 30 '10 #7

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

8 posts views Thread by Jan Decaluwe | last post: by
2 posts views Thread by Matthias Kaeppler | last post: by
11 posts views Thread by jlara | last post: by
4 posts views Thread by Max Sandman | last post: by
16 posts views Thread by Michael Maes | last post: by
reply views Thread by Chris Fink | last post: by
28 posts views Thread by Martin Jørgensen | last post: by
5 posts views Thread by sebastian | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.