> > 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.
I don't think it is too much to ask. At least some vendors have this
list which Clive wants: it's in the release notes for the next version
of the compiler, which detail, among other things, which problems were
fixed since the last compiler. I think Clive would be happy if these
could be made available BEFORE the next version, where they have been
fixed, is available. (Of course, this IS the case if you are still
using an old version. :-) ) See, for example,
http://www.compaq.com/fortran/dfav-rn.txt
(though it is not clear to me while LYNX wants to download it rather
than display it as is normally the case with text files; perhaps a
problem at the server end) where one can find things like
o Eliminate E-level error when a BLOCK DATA subprogram |
name is the same as that of a COMMON block. A future |
revision will cause an appropriate diagnostic to appear. |
I think this is the kind of stuff Clive is looking for, and it obviously
does exist and is publicly available (at least from this vendor). The
icing on Clive's cake, I guess, would be access to this list as it was
built up, so to speak.
|