On Sat, 9 May 1998, [iso-8859-1] Linus Åkerlund wrote:
> something wrong, probably something with malloc(), but how come it
> works when I compile it without optimization? There really shouldn't
> be a difference in whether the program works or not, right?
No; optimization changes your code, after all, and so it can reveal a
hidden bug. Yes, optimization will not change the literal interpretation
of your code, but it will often change what happens when you do something
which is "undefined" such as free()'ing unallocated memory (a common
problem) or using unititialized pointers (which is another common
problem). Optimized code might have different starting values for
unitialized pointers. The optimizer will often not store data into
variables that will not be used again, for example, or will not allocate
them at all if the scope of the variable is small enough and can be
handled entirely within registers. Then it might just so happen that your
uninitialized pointer is using the same physical memory that your variable
was using before; and that variable just happens to be set to the right
value (like 0, perhaps) and everything works. But now in the optimized
version, that variable doesn't exist any more, and so the space is
uninitialized to some other value; and now it doesn't work.
The short answer, then, is yes, optimization can affect your code if your
code is buggy to begin with. :) Try using the -Wall option to gcc and
see if it turns up any obvious errors.
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
