This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: new test will hang 'make check-g77'
[Is Kate H no longer maintainer for the Fortran tests?]
>>>>> "Robert" == Robert Lipe <robertl@dgii.com> writes:
>> The code is bogus,
Robert> The generated x86 code is bogus or the input (the fortran
Robert> source) is bogus?
The source.
Robert> Since your name appears on the submission and you and Craig
Robert> are the Fortran experts I recognize, if you agree it's bogus
Robert> source, let me know and I'll pull the test case.
It should go. I presume you don't need Craig's analysis; it's pretty
much wrong by inspection with a -ffloat-store clue.
I had a quick look at the others.
971014-1.f and 980301-2.f are clearly the same case, but the latter
has more info. It's not something I ever remember seeing. Is it
known what change fixed it? (From chasing things in the past, I think
this info should be recorded with tests, even if something else could
break them later.)
Please remove my commentary from 980310-1.f as it got my wrist slapped
and note that the relevant change is
Thu Dec 4 06:34:40 1997 Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
* stmt.c (pushcase_range): Clean up handling of "infinite" values.
980310-3.f and 980310-4.f are the same bug AFAICT, showing up with
prerelease g77-0.5.22 -fPIC -O0 on x86 redhat 4.2 like:
/tmp/cca11130.s: Assembler messages:
/tmp/cca11130.s:238: Error: operands given don't match any known 386 instruction
leal .LC0@GOTOFF(%ebx),-864(%ebp)
This is fixed in the 980302 snapshot. If anyone knows by what, it
might be helpful for the g77 release. (I should know, but I can't
remember/find the info; I suspect it was Schmidt-ten.)
980310-6.f and 980310-6.f are the same thing, probably also cured by
the Kenner change above, but I don't think I've seen it reported
and I'm not sure.
It would probably be worth a
M-x delete-matching-lines ^c
on well-commented (!) large examples to save some space.