----- Original Message -----
From: "Toon Moene" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, November 30, 2000 2:54 PM
Subject: Re: Suspected bugs... (fwd)


> Clive Page wrote:
>
> [ Given that Clive doesn't agree with me while Steve Lionel does,
>   I think I should spend more effort to bridge the gap between
>   Ye Average Physicist (in my case: meteorologist) and the compiler
>   writer (in my case: current maintainer of GNU Fortran 77 ]
>
> > On Wed, 29 Nov 2000, Toon Moene wrote:
> >
> > > Well, that's not surprising, because it is impossible to fix bugs
> > > without having the (preprocessed, if necessary) source code.
> >
> > > Sometimes people give a few sketchy facts and ask, ``Does this ring a
> > > bell?''  This cannot help us fix a bug, so it is basically useless.
> >
> > I don't think you have understood my point at all.
>                 ^^^
> Be careful - I was quoting a piece of GCC manual that - given that I've
> read it about 8 years ago for the first time and judging its style - was
> probably written by Richard Stallman.  It is not my style; I just agree
> with the content.
>
> > So, sorry to repeat myself, but:
> >
> > I fully understand that to get a bug fully investigate, and with luck,
> > fixed, the customer needs to submit source code and full details.
> > But as you say:
> >
> > > Try to make your bug report self-contained.
> >
> > Making a short self-contained piece of code which shows the problem,
with
> > no dependency on external libraries, often takes days or even weeks of
> > work.
>
> Yes, unfortunately - donning my physicist's hat - this also indicates
> the level of understanding physicists have of the numerical properties
> of the code they "own" (whether it is the code they wrote or the code
> they use).
>
> This is my every-day experience in maintaining a medium-large weather
> forecasting code:  If it goes berserk, it could be I'm:
>
> 1. Operating it outside its limits of validity.
>
> 2. Hitting a algorithmic problem.
>
> 3. Hitting a numeric problem (should switch from 32- to 64-bit
>    floating point - or worse).
>
> 4. Hitting a system error (a race condition in the OS that scrambles
>    the floating point register set - yes, I've seen this done).
>
> 5. Hitting a hardware error.
>
> 6. Hitting a compiler error.
>
> No matter how well I know the code (and I've really really studied it
> the last 8 years), I cannot *without thorough investigation* determine
> in which of the 6 classes the problem falls.
>
> By the time you've done this thorough investigation, you should have a
> testcase to send to the compiler writer *if it turns out to be a
> compiler problem*.
>
> > Many times when I have taken the time to submit a full bug report I have
> > found that all that effort has been wasted, as the vendor simply replies
> > saying "we already know all about that bug, you can get the fix
here...".
>
> Yep - this an error on the part of the compiler writer (or vendor, as
> you say):  Your bug report is *just another expression* of a particular
> compiler bug.  It doesn't mean that this expression was already known;
> it just means that this expression happens to hit a mistake in the
> compiler that was already known.
>
> Apparently, the compiler writer is not communicating well with you - and
> I wouldn't be surprised if I (GNU Fortran maintainer hat on) made this
> mistake in the past.
>
> Apologies.
>
> > Yes, of course.  But in turn vendors should help potential bug reporters
> > by giving them information on known bugs.
> >
> > Is that too much to ask?
>
> Yes, it is, simply because there's no measure on the manifold of
> "expressions of compiler bugs" to define a neighborhood.  There's no way
> to express:  This compiler bug will cause this [ exhaustive list
> included ] source codes fail to return the correct results.
>
> Sorry - that's life.
>
> --
> Toon Moene - mailto:[log in to unmask] - phoneto: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
> GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
>