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