>>> What does "the strictest aliasing rules ..." means ? >> >> It means the compiler is allowed to only guarantee behaviour that >> the relevant standards guarantee, treat undefined behaviour as >> undefined, etc. > > Ok, then what's the point to have an option which make Gcc conformant ? With -fno-strict-aliasing, GCC is _also_ conformant. But in that case, it accepts programs that aren't conformant (in this aspect) and compiles them the way the user expects, at the cost of some missed optimisations. > Is it because some programs out there don't care to be compliant and > want play trick with aliasings with -fno-strict-aliasing ? Yes. Quite a lot of programs actually; largely not on purpose. > That sounds weird since -fno-strict-aliasing seems to be enabled when no > optimisation levels have been passsed. -fstrict-aliasing is enabled at -O2 and up, yes. I don't understand what you find strange here? >>> AFAIK, this type of aliasing is defined by the standard. >> >> It is not. You're accessing an object of type "double" using >> an lvalue of type "int". This is not ok; see C99 6.5/7. > > Yes I think it's incorrect not because of aliasing issue, but because > of type punned stuff. Those issues are really the same thing. The only thing the standard specifies is what type lvalues you are allowed to use to access an object of given effective type (namely, that type (or qualified and/or signedness changed), or a union with a member of that type, or char). > And since the whole paragraph is about aliasing, I don't see the point > of this example. Some people mistakenly assume it will work. It does not. That's why the documentation warns about it. >>> Again in my understanding of the standard, this is an undefined >>> behaviour. So why does man page mention this case ? >> >> Because it is a common misunderstanding. > > Ok. So why not make it clear in the man page: "Note: since it's a common > mistake to think that the following code is correct, it's worth to > outline that it's not, and therefore Gcc assumes so." > > That would remove so much trouble to understand this paragraph. We could precede every statement in the manual with "the following might be useful to you:" :-) I don't find these paragraphs particularly confusing; maybe you can suggest a patch to make it even clearer though? Segher
