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

On Sat, 16 May 2009 08:39:28 +0100, Nathaniel McIntosh
<mcintosh@cup.hp.com> wrote:


>
> foo.c bar.c
> ----- -----
> ... ...
> double x; int x = 0;
> ... int garbage;
>
>Most C compilers will compile these two modules without complaint;
>when you link foo.o and bar.o into an executable, the "strong"
>definition of "x" from bar.o is favored over the "weak" definition in
>foo.o, and you wind up with a final "x" entity that is 4 bytes in size
>(assuming an ILP32 compilation model), not 8 bytes.
>
>In spite of the fact that foo.c contains functions that store 8-byte
>values to "x", the program works without optimization because the
>variable "garbage" (unused as it turned out) happens to be allocated
>just after "x" in memory. If the optimizer plays with the storage
>allocation such that some other critical variable appears just after
>"x", then the application fails.


No. Your example will work regardless. Assuming those definitions
were global in the source files, the result will be 2 different
variables named 'x' - an integer in bar.o and a double real in foo.o.


If, OTOH, the code was:


        foo.c bar.c
        ----- -----
        ... ...
        extern double x; int x = 0;
        ... int garbage;
                                                ...


then the compiler/linker would create only the integer "x" and any
functions in foo that accessed "x" as a double real would do so in
error.


Apart from being a programming mistake and semantically wrong, there
might make no noticeable error on a machine with a 64-bit "int" type.




>I would in fact argue, however, that the compiler is doing the
>programmer a favor by causing the program to crash when compiled with
>optimization.


On this point I agree with you. I don't ever want a customer to see a
program crash or even misbehave. I want the incorrect program to be
correct before it is shipped.


I used to work in RT industrial QA/QC systems where the application
runs 24/7 and the computers are normally inaccessible to production
workers. A software crash in the field typically means the customer
is losing money by the second until a supervisor arrives to restart
the application. A crash on 3rd shift with supervisors home in bed
might result in an hour or more of down time. For some of the
customers whose systems I worked on, a 1 hour outage on a single
production line could mean millions of dollars in lost sales
opportunities.


George

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