Re: Storage for uninitialized objects (PR 24626)

[Paul Schlie <schlie at comcast dot net>]

Thank you for the explanation.

Given that it would appear that the only time the compiler may attempt
to optimize the allocation/use of an un-initialized variable, is when it
knows for certain it hasn't been initialized; might it be preferable to
then assign it a deterministic cheap value such as 0 which it may then
presume during optimization, given all remaining alternatives would seem
to have less desirable potential consequences?

> From: Ian Lance Taylor <ian@airs.com>
>. Paul Schlie <schlie@comcast.net> writes:
>>   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;
> 
> No, the ISO C standard is clear that an uninitialized variable may be
> set to a trap representation (6.7.8, 3.17.2).  So in this case x might
> be a signalling NaN, and executing sin (x) might well terminate the
> program with a floating point exception.  That would be a valid
> translation of the program by the compiler, and would even be
> reasonable and appropriate in a non-optimized compilation.
> 
>>  (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, the ISO C standard is clear that the value of an uninitialized
> variable is indeterminate.  It may be a trap representation, or it may
> be an unspecified value.  In the latter case it must have the correct
> type.  But there is no other restriction on it, and the standard
> specifically says (3.17.3) it "imposes no requirements on which value
> is chosen in any instance."
> 
> Ian