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

torbenm@pc-003.diku.dk (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen)
Tue, 19 May 2009 10:40:40 +0200

          From comp.compilers

Related articles
[10 earlier articles]
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-13)
Re: behavior-preserving optimization in C, was compiler bugs dnovillo@acm.org (Diego Novillo) (2009-05-15)
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)
[11 later articles]
| List of all articles for this month |
From: torbenm@pc-003.diku.dk (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen)
Newsgroups: comp.compilers
Date: Tue, 19 May 2009 10:40:40 +0200
Organization: Department of Computer Science, University of Copenhagen
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-072
Keywords: debug, optimize
Posted-Date: 19 May 2009 07:51:15 EDT

"Christopher Glaeser" <cdg@nullstone.com> writes:




> Suppose you are responsible for maintaining a C compiler and you
> receive a defect report with a program that works fine without
> optimization but generates a divide by zero exception with
> optimization. You analyze the program and determine that the divide
> by zero is in a function that references an uninitialized local array
> element. Without optimization, the array element has a value of 1 due
> to the more-or-less random state of the stack on entry to the
> function. With optimization, changes to register and stack
> assignments cause changes to the state of the stack on entry to the
> function, and now the uninitialized local array element has the value
> 0, which causes the divide by zero exception.
>
> How would you respond to this defect report?


I would tell the programmer what the problem is and, if time allows,
add an analysis that detects potential uses of uninitialised variables
or array elements and issue warnings if such occur. I would also make
sure the policy for bug reports will only accept programs where the
compiler does not issue warnings.


But for a language like C, it is a futile job. There are so many
unspecified behaviours that you can't realistically preserve all or
issue warnings where you don't.


And, to a degree, preserving unspecified behaviour at optimisation is
not doing the programmer any favours: If the same compiler does not
preserve this behaviour across optimisation levels, it is very
unlikely that it will be preserved if you change compiler (or even
target architecture).


Torben



Post a followup to this message

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