Re: Use -fomit-frame-pointer when no debugging info is required

[Cosmin Truta <cosmin at cs dot toronto dot edu>]

On Fri, 29 Dec 2000, Geoff Keating wrote:

> 
> Cosmin Truta <cosmin@cs.toronto.edu> writes:
> 
> > On Thu, 28 Dec 2000, Geert Bosch wrote:
> > 
> > > It essential that we generate byte-for-byte identical code whether -g is 
> > > present or not. Otherwise, we'd soon find ourselves in a situation where
> > > we have programs that run fine with -g, but mysteriously fail without
> > > debugging enabled.
> > 
> > You mean that it is possible to have buggy versions of gcc that will
> > produce erroneous code when -fomit-frame-pointer is on? That would be too
> > bad...
> 
> It's possible to have buggy programs, that will crash when compiled
> with -fomit-frame-pointer but not without; for instance, if they try
> reading through an uninitialized pointer variable that just happens to
> have an OK value when compiled without -fomit-frame-pointer.

Well, in that case, why is it essential to have byte-for-byte identical
code regardless of the presence of the -g option?
I admit gcc _must_ and I believe it _does_ generate executable code that
is _semantically_ equivalent whether -g is present or not. But semantic
equivalence is conditioned by the non-existence of unexpected behavior.

Uninitialized variables yield "unexpected behavior" by the definition of
both C and C++ languages, and to use uninitialized vars does not mean to
benefit from some gcc "features", but merely to have bugs; no C or C++
compiler is ever required to hide such bugs, and more, the sooner the
bugs are revealed (by crashing code), the better for the user.

If it happens, by accident, that a certain compiler with a certain
optimization option hides a certain user bug, that compiler should *not*
be required to do that consistently, not even at the expense of code
performance. Or, do you have counter-examples (e.g. buggy, but legacy code
that must continue to run the same way when compiled with the new
compiler)?

Cheers,
Cosmin