----- Original Message -----
From: "Toon Moene" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, November 30, 2000 6:37 PM
Subject: Re: Suspected bugs...
> Phillip Helbig wrote:
>
> > Clive Page wrote:
>
> > > "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..."."
>
> > As I pointed out, if he's using an older version he might find what he
> > wants in the release notes of the newer version, or, as I suggested
> > (don't know if this is available) the vendor could make some "running
> > total" list of fixes which later show up in the release notes---this
> > obviously exists as an internal list.
>
> Yeah - sigh - I see the hand waving you two apply to this problem, but
> try to get these words into actual binary decisions.
>
> Explain to me how you can determine, based on the "list of fixes" a
> compiler writer puts out (or keeps secret) that - say:
>
> SUBROUTINE SAXPY(X,Y,A,N)
> DIMENSION X(N), Y(N)
> DO I = 1, N
> Y(I) = Y(I) + A * X(I)
> ENDDO
> END
>
> will be compiled correctly, given the myriad combinations of compiler
> flags, optimizations, OS's and architectures you could compile this with
> / for / run it on.
>
> In case you think I'm kidding, consider the following:
>
> Just this week, a Red Hat engineer fixed a long standing (>2 months) bug
> report in the GCC development tree. The test case was in Fortran, and
> the failure was on the Intel architecture, under Linux (at least, that's
> what we concluded from the testresults we received).
>
> The bug turned out to be a fairly general loop hoisting problem, that
> showed up when a loop was left via an early exit. After the fact we
> concluded the following:
>
> 1. The bug must have been there for more than a year (the last time
> that particular code had been changed).
>
> 2. The bug was very general, in that it hit all architectures and
> all frontends (i.e. all languages). Yet it was only reported and
> triggered with a Fortran example on an Intel chip.
>
> 3. The RH engineer was so uncertain about the actual origin of the
> bug that he constructed his own "bug report" in C to study the
> problem - so now we have a C and a Fortran "version" of the
> regression test for this bug.
>
> Please understand that not giving out "complete bug fix lists" isn't a
> matter of ill-conceived secrecy, but an impossibility due to the nature
> of the problem.
>
> --
> 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)
>
|