"John David Anglin" <[EMAIL PROTECTED]> writes: > I have a question about storage for uninitialized objects. > > I made the mistake of looking at the code being generated for > testcase #2 in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626. > I noticed that reload used the same register r3 for the variables > "call_result" and "node" after the call to after_node_func (). > This appears to occur because "node" is an uninitialized variable. > > It seems to me that automatic variables with similar storage > duration should be allocated different storage. This would ensure > that the same value of "node" is passed in the calls to after_node_func > and T. With the current code, different values might be passed, and T > could detect the difference in values in a way that doesn't invoke > undefined behavior. > > Am I wrong about this? The main reason I'm concerned about this > is that there have been quite a few optimization issues in GCC 4.0 > that have been difficult to debug on the PA-RISC port.
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. Ian
