|[4 earlier articles]|
|Re: compiler bugs firstname.lastname@example.org (2009-05-05)|
|Re: compiler bugs email@example.com (Christopher Glaeser) (2009-05-06)|
|Re: compiler bugs firstname.lastname@example.org (2009-05-06)|
|Re: compiler bugs cfc@shell01.TheWorld.com (Chris F Clark) (2009-05-07)|
|Re: compiler bugs email@example.com (2009-05-10)|
|Re: behavior-preserving optimization in C, was compiler bugs firstname.lastname@example.org (Christopher Glaeser) (2009-05-12)|
|Re: behavior-preserving optimization in C, was compiler bugs email@example.com (2009-05-13)|
|Re: behavior-preserving optimization in C, was compiler bugs firstname.lastname@example.org (Diego Novillo) (2009-05-15)|
|Re: behavior-preserving optimization in C, was compiler bugs email@example.com (Christopher Glaeser) (2009-05-15)|
|Re: behavior-preserving optimization in C, was compiler bugs firstname.lastname@example.org (Nathaniel McIntosh) (2009-05-16)|
|Re: behavior-preserving optimization in C, was compiler bugs email@example.com (Pertti Kellomaki) (2009-05-18)|
|Re: behavior-preserving optimization in C, was compiler bugs firstname.lastname@example.org (glen herrmannsfeldt) (2009-05-18)|
|Re: behavior-preserving optimization in C, was compiler bugs email@example.com (2009-05-19)|
|[17 later articles]|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Date:||Wed, 13 May 2009 14:22:18 GMT|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|References:||09-04-072 09-04-086 09-05-010 09-05-022 09-05-028 09-05-038 09-05-039 09-05-050 09-05-055 09-05-065|
|Posted-Date:||15 May 2009 08:05:40 EDT|
"Christopher Glaeser" <email@example.com> writes:
>Even a simple bug fix to a new release in a compiler
>can affect the behavior of C programs that have undefined behavior.
Different releases are a different issue than turning optimization on,
although changing behaviour between releases is not desirable, either.
>It's not clear where pulling on this thread would end? Do you
>advocate initializing local arrays too, and if not, why not?
If you want to implement an optimization that needs initialized local
arrays to preserve the behaviour, it's certainly worth considering.
Or you may find a different way to preserve the behaviour.
>Given that you have tossed out-of-bounds array access into the
The specific case I was thinking about was reading a specific value of
a function return address through an out-of-bounds access; this is
both hard to preserve and not worthwhile, because the programmer will
experience this as a problem even in the non-optimizing compiler
during development and will avoid that.
>are you also tossing undefined pointer use into the
>too-hard pile as well?
"Undefined pointer use" sounds like something from a standards
document, i.e., something out of the vocabulary of an apologist. I
don't know exactly what you mean by that (it's probably many different
things, at least in their effect on behaviour-preserving
optimization), and therefore cannot answer the question.
>Given that pointers are so pervasive in C, doesn't this miss one of
>the more common reasons why incorrect programs can change behavior
"Incorrect programs"? Definitively apologist lingo in this context.
>More to the point, I still don't understand your basic position. In
>your original post, you accussed some compiler writers of being
>"apologists" becuase they designed the optimizer to the lanauge
>standard and you asserted that they should be designing the optimizer
>to maintain the behavior of programs that use undefined behavior, and
>then made some room for ignoring behavior like out-of-bound arrays.
>This exception seems a bit arbitrary. How is a compiler writer to
>know if they are an apologist?
The test is pretty simple: What happens if you get a bug report that
shows that your optimizer changes the behaviour of the program?
* Do you analyse the program to see if it is actually
standard-conformant? If it isn't, do you consider the program to be
incorrect, the optimizer to be correct, and do you mark the bug
report as invalid? Then you are an apologist. If you don't write
optimizers, but think that this attitude is ok, then you are also an
* Do you consider the behaviour change as an optimizer bug, and think
about how it can be fixed, and suggest workarounds to the programmer
for the meantime? Then you are no apologist. The cases where you
cannot fix the optimizer bug should be the exception, not the rule,
and these should all be cases where the programmer considers his
program buggy himself anyway once you make him aware of why the
optimizer changed the behaviour (without you citing the standard or
M. Anton Ertl
Return to the
Search the comp.compilers archives again.