Re: compiler bugs

Walter Banks <walter@bytecraft.com>
Thu, 30 Apr 2009 04:25:13 -0500

          From comp.compilers

Related articles
[11 earlier articles]
Re: compiler bugs marcov@stack.nl (Marco van de Voort) (2009-04-29)
Re: compiler bugs torbenm@pc-003.diku.dk (2009-04-29)
Re: compiler bugs dot@dotat.at (Tony Finch) (2009-04-29)
Re: compiler bugs derek@knosof.co.uk (Derek M. Jones) (2009-04-29)
Re: compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-04-29)
Re: compiler bugs r3jjs@yahoo.com (Jeremy J Starcher) (2009-04-29)
Re: compiler bugs walter@bytecraft.com (Walter Banks) (2009-04-30)
Re: compiler bugs cfc@shell01.TheWorld.com (Chris F Clark) (2009-04-30)
Re: compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-01)
Re: compiler bugs gene.ressler@gmail.com (Gene) (2009-05-01)
Re: compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-04)
Re: compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-05)
Re: compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-05-05)
[6 later articles]
| List of all articles for this month |

From: Walter Banks <walter@bytecraft.com>
Newsgroups: comp.compilers
Date: Thu, 30 Apr 2009 04:25:13 -0500
Organization: Aioe.org NNTP Server
References: 09-04-077 09-04-081
Keywords: errors
Posted-Date: 01 May 2009 19:19:09 EDT

Quinn Tyler Jackson wrote:


> I can count on one hand the number of genuine compiler bugs I've been able
> to isolate and reproduce well enough to report as official bugs. (Even the
> so-called optimization bugs turned out to be my violation of some contract
> with the compiler, such as aliasing when I oughtn't have.)


Good test software is incredibly hard to write often taking more
resources than the compiler function it was meant to test.


It is difficult in many cases to create a simple example of a compiler
bug due to the kind of optimization that is found in many
compilers. It is common that code generation for syntactically
identical sequences to generate substantially different code due to
some overall application consideration. Two simple examples are
spilled registers and even simple instruction addressing modes. (This
alone should be enough to do testing at the optimization level of code
for the final product)


Compiler bugs are a function of the degree of optimization that is in
the compiler. As soon as alternative code generation sequences are
added testing becomes much more complex and the probability of a
customer encountering a compiler bug is higher.


We use both random testing and syntax directed testing with our
compilers because the payoff to effort is high. Both of these
techniques are a single tool in a very large toolbox.


Eric Eide and John Regehr are to be commended for their work on
Volatiles. The success of their work was careful planning on the
design of the random tests and some very good analysis work. Their
paper illustrates just how difficult a simple language feature is to
both implement and validate.


Application specific testing tends to have a high payoff. Using
reference designs and customer application code as part of the
regression tests while tracking compiler generated metrics will tend
to uncover induced bugs as the compiler evolves and will focus effort
to the compiler area's that customers actually will be using.


Regards,


--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com


Post a followup to this message

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