Francis Moreau <francis.moro@xxxxxxxxx> writes: > Ian Lance Taylor <iant@xxxxxxxxxx> writes: > >> "Segher Boessenkool" <segher@xxxxxxxxxxxxxxxxxxx> writes: >> >>>> BTW, I tried to compile the last example, and we agreed that it invokes >>>> undefined behaviour. >>> >>> I did no such thing. With -fno-strict-aliasing, the code is well-defined. >> >> I think I would say this slightly differently. The code is still >> undefined according to the C/C++ language standards. When you use >> -fno-strict-aliasing, gcc is promising to avoid using a class of >> optimizations based on those portions of the language standards. >> Another way to say this is that gcc is promising to not optimize based >> on the fact that memory locations are accessed using different types. >> That is, the code is still incorrect; gcc is just avoiding a class of >> optimizations which are known to cause trouble with real programs. >> >> I also am having trouble understanding what the OP is asking for here. > > Clarification on GCC's strict aliasing rules. > > 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. 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. Ian
