 |
 |
----- Original Message ----- From: "Phillip Helbig" <[log in to unmask]> To: <[log in to unmask]> Sent: Thursday, November 30, 2000 4:02 PM Subject: Re: Suspected bugs... (fwd) > > > 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. >