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

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

[Kate Hedstrom]

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

I had once said that I would organize the Fortran tests,
although I have to admit that I've been ignoring the egcs lists
for the past several months.  I have some old snippets of code
which once failed under g77, but no commentary about what the
problem was or what fixed it.

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

I will look into it this weekend unless someone fixes it first.

Kate

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'

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

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

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

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

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

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'

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

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

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

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