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)
|