This is the mail archive of the
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 <firstname.lastname@example.org> writes:
>> The code is bogus,
Robert> The generated x86 code is bogus or the input (the fortran
Robert> source) is bogus?
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 <email@example.com>
* 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
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.