tools which indiscriminately alter non-portable observable behavior during optimization aren't doing anyone any favors.
conversely, tools which focus on optimizing portable behavior, while attempting to preserve non-portable behavior, are always preferable. > From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: >>> Ian Lance Taylor writes: >>> >>> gcc assumes that if a variable is uninitialized, it can use any value >>> whatsoever for any use of the variable. gcc does not assume that all >>> uses of an uninitialized variable must have the same value. >>> >>> It is of course possible to write a correct program which uses an >>> uninitialized variable. However, I believe that such a program must >>> never examine the variable in any way whatsoever, so I don't agree >>> that it is possible to detect the difference in values. Even >>> comparing the uninitialized variable to itself is undefined behaviour. >>> Given that, I think that gcc's current approach will generate the most >>> efficient code for correct programs which have uninitialized >>> variables. >>> >> >> - I believe that it is a grave mistake to conclude that a well defined >> semantic operation on an indeterminate value, has undefined semantics. >> >> > Well the standards committee made the grave mistake if it is one, so if > you want to challenge this, take it up with the standards committee > >> As this is simply an erroneous conclusion. >> >> > No, it is an exactly correct conclusion of the standard > >> As a simple example, although x may be indeterminate -1 < sin(x) < +1 >> is unconditionally true, as must be tan(x) = sin(x)/cos(x), and x^x = 0; >> >> > Nonsense, in this case x is a floating-point number, and it is not at all > true that sin(signalling NaN) is anything at all. So here, even from a > pragmatic point of view, this is wrong, and of course sin(x) is entirely > undefined in the standard if x is uninitialized. > >> So although neither the compiler (nor program) may know what the value >> of x may be until run-time (unless it is chosen to be given a default >> initialized value of convenience by the compiler); regardless of that >> value, it must be utilized in a semantically consistent manor. >> >> > When a variable is uninitialized, it is not the case that it has > some value that is defined, it is undefined, and any reference > that reads the value of such a variable is undefined. A > compiler that deleted the system disk when you did this > would be impolite, but still conforming. > >> (as a general rule, optimization should never alter observable semantics >> of a program within it's control; so if GCC chooses not to assign a >> default value to an otherwise un-initialized variable; it must assume >> it may be any single value, not any multiple value; although should >> feel free to complain loudly about it in either case.) >> >> > No, that is not the way the language is defined. Sorry! > >
