Re: new test will hang 'make check-g77'

[Dave Love <d.love@dl.ac.uk>]

[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.