new test will hang 'make check-g77'

new test will hang 'make check-g77'

[Robert Lipe]

This isn't going to be popular, but it should be motivational. :-)

The new testcase
	g77.f-torture/execute/980310-5.f

will hang forever when compiled with -O2 or higher, as a 'make check'
will do by default. It will consume mass quantities of clock cycles and
generally screw up your automated build and test processes.  I have
verified this behaviour on the current egcs on i586-pc-sco3.2v5.0.4, but
the original report was under Linux.

If this causes enough grief during testing and is deemed benign enough
by the wizards, perhaps we can set it to xfail as we did for the recent
961203 tests.

robert "i don't write 'em, I just paste 'em" l

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

[Dave Love]

>>>>> "Robert" == Robert Lipe <robertl@dgii.com> writes:

 Robert> This isn't going to be popular, but it should be motivational. :-)
 Robert> The new testcase
 Robert> 	g77.f-torture/execute/980310-5.f

 Robert> will hang forever when compiled with -O2 or higher, as a
 Robert> 'make check' will do by default.

The code is bogus, and I'd been meaning to track down and withdraw my
unfortunate forwarding of it on a bad day after Craig examined it
properly.  It's just a case of the classic numerical problems exposed
by use of x86 FP registers (-ffloat-store is your friend, to some
extent).  Sorry for confusion, and thanks for digging these things
out.

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

[Craig Burley]

>The new testcase
>	g77.f-torture/execute/980310-5.f
>
>will hang forever when compiled with -O2 or higher, as a 'make check'
>will do by default. It will consume mass quantities of clock cycles and
>generally screw up your automated build and test processes.  I have
>verified this behaviour on the current egcs on i586-pc-sco3.2v5.0.4, but
>the original report was under Linux.

Could you email me this code?  I might already have a fix for
it in g77 0.5.21's patches to the gcc back end, which egcs
does not (currently) incorporate -- probably because it's
just an optimization, maybe also because I had to issue a patch
to fix a thinko in it (< ftp://alpha.gnu.org/g77.plan > has a list
of such patches, including the one in question).  Basically, this
patch fixes the problem of "hanging" in safe_from_p(), resulting
from g77 trying to compile code with a fairly complicated expression
involving stuff like COMPLEX types.

Also, I do plan on submitting pending g77 bugs myself as well,
so, to avoid duplicating work, could you email me summaries of
each bug report or test case you're working on adding to the
data base?  (Note that your doing this instead of me amounts
to a *huge* potential improvement in my own productivity right
now, as I've got lots of things on my plate that have been
suffering lately; adding g77 test cases to the egcs suite is
quite important, IMO, so whatever you can't get to yourself, I
do want to make time to do.)

        tq vm, (burley)

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

[Robert Lipe]

> >The new testcase
> >	g77.f-torture/execute/980310-5.f
> >
> >will hang forever when compiled with -O2 or higher, as a 'make check'
> 
> Could you email me this code?  I might already have a fix for

I will.  If you have cvs access, you can just do a 'cvs update' and 
see the file.

> Also, I do plan on submitting pending g77 bugs myself as well,
> so, to avoid duplicating work, could you email me summaries of
> each bug report or test case you're working on adding to the
> data base?  (Note that your doing this instead of me amounts

Basically I've been picking through the egcs-bugs archives.  There
haven't been a whole lot of fortran cases.   If you're not CVS enabled,
I'll send you the 8 or 9 I committed yesterday.

> now, as I've got lots of things on my plate that have been
> suffering lately; adding g77 test cases to the egcs suite is
> quite important, IMO, so whatever you can't get to yourself, I
> do want to make time to do.)

Thanx for the help.

RJL

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

[Robert Lipe]

Dave Love wrote:

> >>>>> "Robert" == Robert Lipe <robertl@dgii.com> writes:
>
>  Robert> The new testcase g77.f-torture/execute/980310-5.f will hang
>  Robert> forever when compiled with -O2 or higher, as a
>
> The code is bogus,

The generated x86 code is bogus or the input (the fortran source)
is bogus?


> and I'd been meaning to track down and withdraw my
> unfortunate forwarding of it on a bad day after Craig examined it
> properly.  It's just a case of the classic numerical problems exposed

Since your name appears on the submission and you and Craig are the
Fortran experts I recognize, if you agree it's bogus source, let me know
and I'll pull the test case.

> Sorry for confusion, and thanks for digging these things out.

Actually, this is exactly what I hope to accomplish in this exercise.
If I can reduce the 3000 messages into about 200 testcases that I
can't dismiss as completely bogus and our respective experts can only
have to look at 200 (probably to dismiss 150 ;-) we'll harvest 50 good
testcases if we're lucky and hopefully not burn a lot of "expert-time"
in the process.

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

[Robert Lipe]

Re: 980310-5.f

> Okay, I've already sent you email suggesting the case you were
> asking about is inappropriate (it's a user bug, not a compiler
> bug).  Probably best to remove it from the test suite, as it

Done!

Thanks to you and Dave Love for your help on this.

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com

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

[Robert Lipe]

> [Is Kate H no longer maintainer for the Fortran tests?]

I don't know.   I'm not planning to maintain anything - I'm just
kicking in some help.

>  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

It's gone.

> 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

Good catch.  Since 971014 has been there for some time and isn't on
the list of things known to fail, something must have fixed it.

IMO, you can vote which one stays and which one goes.  You can even
make the changes yourself if you like.

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

This is why I'm leaning toward the liberal inclusion of testcase
information in the cases themselves.  I haven't been that liberal with
everything, trying to strike a balance between volume and completeness.


> Please remove my commentary from 980310-1.f as it got my wrist slapped

Done.

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

It failed on egcs 1.0.1 when I tried it last night.   Aaah.  I see the
fix in 1.0.2.

> 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)

Does anyone know how we can make those tests run with '-fPIC -O' so they'll
show up as a failure?

Dave, you get the vote which of those tests we keep.


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

I think it was this fix:

Mon Jan 19 21:57:00 1998  Richard Henderson  <rth@cygnus.com>

        * i386.md (push): Prohibit symbolic constants if flag_pic.
        (movsi+1): Likewise for move to non-register.

If you decide that either or both of these tests stay, one of us can
blow this reference into the testcases if you like.

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

That's the same file twice.   Presumably you mean *-6.f  and *-8.f.

I'll let you pick which stays.

> It would probably be worth a
>  M-x delete-matching-lines ^c
> on well-commented (!) large examples to save some space.

I hate to admit this in this crowd, but I don't do emacs.   Are you
saying that the value of the space is greater than the value
of the comments?   If so, I can swing back the other way and not
retain sender information, etc.


Thanx for the help.

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com

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

[Craig Burley]

>I will.  If you have cvs access, you can just do a 'cvs update' and 
>see the file.

No CVS access (yet).  Thanks!

>> Also, I do plan on submitting pending g77 bugs myself as well,
>> so, to avoid duplicating work, could you email me summaries of
>> each bug report or test case you're working on adding to the
>> data base?  (Note that your doing this instead of me amounts
>
>Basically I've been picking through the egcs-bugs archives.  There
>haven't been a whole lot of fortran cases.   If you're not CVS enabled,
>I'll send you the 8 or 9 I committed yesterday.

Okay, I've already sent you email suggesting the case you were
asking about is inappropriate (it's a user bug, not a compiler
bug).  Probably best to remove it from the test suite, as it
doesn't really illustrate anything particularly useful (although
it might be nice to have a subdirectory called "userbugs" for
known user bugs that have behaviors like "-fno-caller-saves
makes the problem go away" ;-).

>> now, as I've got lots of things on my plate that have been
>> suffering lately; adding g77 test cases to the egcs suite is
>> quite important, IMO, so whatever you can't get to yourself, I
>> do want to make time to do.)
>
>Thanx for the help.

Ditto!!

        tq vm, (burley)

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

[Dave Love]

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

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

[Joe Buck]

> > Could you email me this code?  I might already have a fix for
> 
> I will.  If you have cvs access, you can just do a 'cvs update' and 
> see the file.

Note that folks without CVS access can use the Web interface to grab
the very latest version of some file, see changes between any two
versions, etc.

Try

http://egcs.cygnus.com/cgi-bin/cvsweb/ .  I just tried it to find out
what Robert Lipe got his wrist slapped for (980310-1.f).

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

[Craig Burley]

>This is why I'm leaning toward the liberal inclusion of testcase
>information in the cases themselves.  I haven't been that liberal with
>everything, trying to strike a balance between volume and completeness.

Note that I started doing this myself, a few years back, for
g77 tests.  Better to include the entire original email, plus
annotations, as comments to the source code than to try and
cobble together some kind of system to track such info separately
(especially when such a system involves use of pencil and paper,
in my office, where paper has a poor track record for keeping
itself organized ;-).

When I start submitting some of the g77 tests I've been accumulating,
I might try to cull out a bit of the redundant info, but will also
try and add more definitive commentary of my own.

BTW, I've been assuming I should submit these to Jeff Law for actual
installation via CVS, but, perhaps, Robert Lipe, you'd be willing to
do this -- especially since that'd give you a direct opportunity
to once-over my submissions to help avoid duplication?  Even if
I had my own CVS access, that might be good, but let me know if
that seems okay.

        tq vm, (burley)

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

[Dave Love]

>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:

 Craig> Better to include the entire original email, plus annotations,

I'll defer to that.

 Craig> BTW, I've been assuming I should submit these to Jeff Law for
 Craig> actual installation via CVS, but, perhaps, Robert Lipe, you'd
 Craig> be willing to do this

Wouldn't it be a better use of resources if I or Toon did this, since
we're likely familiar with the bugs, and have Robert's time &
expertise devoted to something else (not that I particularly need work
and am obviously grateful for it being done one way or another)?  Or
is it actually better if someone else does it?

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

[Dave Love]

>>>>> "Robert" == Robert Lipe <robertl@dgii.com> writes:

 Robert> That's the same file twice.   Presumably you mean *-6.f  and
 Robert> *-8.f.

Yes, sorry.  And I was obviously wrong about the fix, which presumably
should be:
 
Wed Feb 11 01:44:48 1998  Richard Henderson  (rth@cygnus.com)

	* com.c (ffecom_ptr_to_expr) [FFEBLD_opARRAYREF]:  Do upper - lower
	in the native type, so as to properly handle negative indices.

 Robert> I hate to admit this in this crowd, but I don't do emacs.

At least you recognise it :-)

 Robert> Are you saying that the value of the space is greater than
 Robert> the value of the comments?

I'd have thought so in these cases, but don't feel strongly about it.
I mean the user-level Fortran comments, of course.  I wouldn't include
the sender info myself, but perhaps someone should make policy on that
and make it clear that bug reports may end up verbatim in the
testsuite if necessary.

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

[Toon Moene]

 Craig> BTW, I've been assuming I should submit these to Jeff Law for
 Craig> actual installation via CVS, but, perhaps, Robert Lipe, you'd
 Craig> be willing to do this

Well, there's the assumption that, once you have your network up,  
you should switch to CVS and take over the Fortran related part of  
committing changes ...

>  Wouldn't it be a better use of resources if I or Toon
>  did this, since we're likely familiar with the bugs, and
>  have Robert's time & expertise devoted to something else
>  (not that I particularly need work and am obviously
>  grateful for it being done one way or another)?  Or is
>  it actually better if someone else does it?

I certainly think that's a better use of Robert's time.  However,  
as I can't run dejagnu on m68k-next-nextstep3, I need to do some  
hand-fixing of sources before I can compile them.

And, on another thread:

 Robert> I hate to admit this in this crowd, but I don't do emacs.

>  At least you recognise it :-)

Dave probably knows how to get out of it (control-z, kill %1  
doesn't work over here).

Cheers,
Toon.

Adding g77 test cases to egcs

[Craig Burley]

> Craig> BTW, I've been assuming I should submit these to Jeff Law for
> Craig> actual installation via CVS, but, perhaps, Robert Lipe, you'd
> Craig> be willing to do this
>
>Well, there's the assumption that, once you have your network up,  
>you should switch to CVS and take over the Fortran related part of  
>committing changes ...

Yes, I look forward to that day.  I do have my LAN set up, but
I'm chicken about undertaking the whole new-ISP/PPP/cvs thing,
given how many other projects are still half-done or not-quite-
working (remember how long ago I was supposed to have a working
Alpha for g77 development? one's sitting next to me, taken apart,
awaiting more info on how to configure the SCSI card to see if
that'll fix problems ;-).

So, I'd like to "clear the decks" as much as possible before
upgrading my Internet access sufficiently to use CVS, have reliable
and speedy email/USENET access, and so on.  Since that process
might render my Pentium, or my own brain, somewhat dysfunctional
for a time, things I'd rather people *not* be waiting on from
me include:

  -  Submitting g77 test cases that I (and, in some cases, only I)
     have, along with the info I've developed on them

  -  Submitting gcc-2.7.x patches g77 has been using so they
     can be evaluated for inclusion into egcs and gcc

  -  Getting 0.5.22, and maybe 0.5.23 as well, out the door

  -  Some other stuff

So I want to take care of these first.

>>  Wouldn't it be a better use of resources if I or Toon
>>  did this, since we're likely familiar with the bugs, and
>>  have Robert's time & expertise devoted to something else
>>  (not that I particularly need work and am obviously
>>  grateful for it being done one way or another)?  Or is
>>  it actually better if someone else does it?
>
>I certainly think that's a better use of Robert's time.  However,  
>as I can't run dejagnu on m68k-next-nextstep3, I need to do some  
>hand-fixing of sources before I can compile them.

I picked on Robert Lipe only because he showed signs of actually
caring enough about g77 to review past bug reports and install
test cases into egcs, which also meant he has CVS access.  In other
words, the squeaky grease got the wheel.  ;-)  Seriously, anyone
who has those qualities is welcome to do my dirty work until I get
my own CVS access -- I already know how dedicated Dave Love, Toon
Moene, and Kate Hedstrom are to g77, so if y'all have CVS access and
are willing to take some time to submit test cases that I email to
you, great!  Originally I was going to email them to Jeff Law,
seeing as he's done such great work making egcs-with-g77 happen
and installs my patches so quickly (sometimes before I finish
them ;-), but if I can help reduce his load by finding one or two
other people to do the CVS stuff....

What I plan to do is email these test cases to <fortran@gnu.org>,
<egcs-bugs@cygnus.com>, and anyone else who wants to see them as
well -- just let me know.  (I assume Robert Lipe is on the egcs-bugs
email list.  I'm not, but probably should subscribe.  In fact, I
think I'll do that next.  Anything to bring my spam ratio back
below 50%.  :)

These submissions will include explicit commentary that the bug
reports are old ones that are now packaged, modified as appropriate,
for inclusion in a particular area of the g77 test suite, and a
request for one individual (Robert, Dave, Toon, Kate...whoever
volunteers, maybe I'll rotate test by test to spread the load) to
actually add it.

That way, even without CVS access, everyone gets to look over the
test and see if they see any obvious problems or if it rings any
bells in terms of past bug reports...and might help ring one or
two if future bug reports come along identifying similar problems.
Mainly, I'm hoping this approach reduces both duplication of
work (submissions) and submission of test cases about which I
already have info I haven't done a sufficient job of sharing to date.

If anyone has feedback on this approach, let me know.

>>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:
>
> Craig> Better to include the entire original email, plus annotations,
>
>I'll defer to that.

But, what do other people do with submissions from outside --
can we just assume, barring explicit copyright notices to the
contrary, that turning the program and emailed info into a
GPL'ed (?) test case is okay?  Or should we ask permission (seems
like a good idea to me anyway)?  Are there guidelines to these
issues somewhere I can read?

> Craig> BTW, I've been assuming I should submit these to Jeff Law for
> Craig> actual installation via CVS, but, perhaps, Robert Lipe, you'd
> Craig> be willing to do this
>
>Wouldn't it be a better use of resources if I or Toon did this, since
>we're likely familiar with the bugs, and have Robert's time &
>expertise devoted to something else (not that I particularly need work
>and am obviously grateful for it being done one way or another)?  Or
>is it actually better if someone else does it?

I hope I've explained that above.  I do like the idea of more people
seeing the tests I submit, but if I had CVS access I'd just do the
work, so I definitely wasn't overlooking you or Toon (or Kate!),
just wasn't sure how your time and other resources fit in with things.

Whoever is willing to add test cases to egcs via CVS that I submit to
them for exactly that purpose, just let me know!  The more the merrier,
I'll just rotate appropriately until I get dizzy.

        tq vm, (burley)