Re: behavior-preserving optimization in C, was compiler bugs

"Christopher Glaeser" <cdg@nullstone.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
>too-hard pile,


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
>when optimized?


"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
    apologist.


* 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
    anything).


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

Return to the comp.compilers page.
Search the comp.compilers archives again.