Andreas Schwab wrote:
Howard Chu <[EMAIL PROTECTED]> writes:
I understand that logic, in the general case. In this specific example,
none of those conditions apply. foo is an uninitialized local
variable. Therefore the compiler cannot know that it has a valid copy of
it in any register. In fact what it should know is that it has no valid
copy of it. And of course, there are no loops to consider here, so that
type of reload optimization isn't relevant. As such, the compiler has no
choice but to do the right thing, and load the value from memory, thus
getting the correct result. Which it does.
It will load the value from memory, true, but who says that the store to
memory will happen before that? The compiler is allowed to reorder the
statements since it "knows" that foo and *arg cannot alias.
If the compiler is smart enough to know how to reorder the statements,
then it should be smart enough to know that reordering will still leave
foo uninitialized, which is obviously an error. Any time an
optimization/reordering visibly changes the results, that reordering is
broken. And we already know that gcc is smart enough to recognize
attempts to use uninitialized variables, so there's no reason for it to
go there.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
