Ian Lance Taylor <iant@xxxxxxxxxx> writes: > Francis Moreau <francis.moro@xxxxxxxxx> writes: [...] >> But I think I got it now, although I still don't know which exactly >> undefined behaviours are defined by GCC's -fno-strict-aliasing. > > In the definitions that I use, I would say that no undefined behaviours > are defined. That really makes '-fno-strict-aliasing' scary... > The -fno-strict-aliasing option disables a class of optimizations. > These are optimizations which look at two pointer references and > consider whether the two pointers might be pointing at the same memory > location. When -fno-strict-aliasing is in effect, these optimizations > do not consider the types of the pointers. When -fstrict-aliasing is in > effect, these optimizations do consider the types of the pointers. > > That's a moderately precise definition, but you'll note that it does not > really describe the effects on the generated code, nor does it describe > the types of source code that are supported. It's tempting to say that > the -fno-strict-aliasing option removes paragraph 7 from C99 section > 6.5, which begins "an object shall have its stored value accessed only > by an lvalue expression that has one of the following types." But > that's incomplete, because it doesn't describe what happens if you do > make such an access, and the compiler doesn't make any particular > promises. > > The most common effect of the optimizations I mention is to permit > rearranging the order of memory references. For example, they permit a > load which uses one effective type to be moved ahead of a store which > use a different effective type, even if there is no other information > which would permit that load and store to change places. Making that > switch can have knock-on effects. For example, the store may now appear > to be dead, and it may be omitted. The load may now appear to load from > uninitialized memory, and it may also be omitted. In some cases, the > entire function may evaporate and turn into a nop. Thanks, it does clarify. Maybe somthing similar should be added in the man page, with a note insisting on the fact that using '-fno-strict-aliasing' is really a bad thing. Also the term 'strictest aliasing' can be clarified. It's actually the effective aliasing rules of the standard, and with no assumption made by GCC about undefined behaviours for optimisation purposes. Thanks -- Francis
