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

George Neuner <gneuner2@comcast.net>
Tue, 19 May 2009 14:42:40 -0400

          From comp.compilers

Related articles
[12 earlier articles]
Re: behavior-preserving optimization in C, was compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-15)
Re: behavior-preserving optimization in C, was compiler bugs mcintosh@cup.hp.com (Nathaniel McIntosh) (2009-05-16)
Re: behavior-preserving optimization in C, was compiler bugs pertti.kellomaki@tut.fi (Pertti Kellomaki) (2009-05-18)
Re: behavior-preserving optimization in C, was compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-05-18)
Re: behavior-preserving optimization in C, was compiler bugs torbenm@pc-003.diku.dk (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs torbenm@pc-003.diku.dk (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs gneuner2@comcast.net (George Neuner) (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs bobduff@shell01.TheWorld.com (Robert A Duff) (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs bobduff@shell01.TheWorld.com (Robert A Duff) (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
[9 later articles]
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Tue, 19 May 2009 14:42:40 -0400
Organization: A noiseless patient Spider
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 09-05-069 09-05-073
Keywords: optimize, debug
Posted-Date: 20 May 2009 09:56:53 EDT

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



Post a followup to this message

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