Results for egcs-2.91.55 19980824 (gcc2 ss-980609 experimental) testsuite on sparc-sun-solaris2.5.1

Results for egcs-2.91.55 19980824 (gcc2 ss-980609 experimental) testsuite on sparc-sun-solaris2.5.1

[Matthias Mueller]

Native configuration is sparc-sun-solaris2.5.1

		=== gcc tests ===


Running target unix
FAIL: gcc.c-torture/execute/980506-2.c execution,  -O2 
FAIL: gcc.c-torture/execute/980506-2.c execution,  -O2 -g 
FAIL: gcc.c-torture/execute/980506-2.c execution,  -Os 
FAIL: gcc.c-torture/execute/980526-1.c execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -g 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -Os 
FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 
FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 -g 
FAIL: gcc.c-torture/execute/loop-2g.c execution,  -Os 
FAIL: gcc.dg/980626-1.c (test for excess errors)

		=== gcc Summary ===

# of expected passes		7481
# of unexpected failures	17
# of expected failures		7
# of unsupported tests		18
/data/video/matthias/egcs-19980824/gcc/xgcc version egcs-2.91.55 19980824 (gcc2 ss-980609 experimental)

		=== g++ tests ===


Running target unix
XPASS: g++.pt/explicit69.C not a template instantiation (test for errors, line 2)
XPASS: g++.robertl/eb132.C (test for excess errors)
FAIL: g++.robertl/eb91.C (test for excess errors)

		=== g++ Summary ===

# of expected passes		4221
# of unexpected failures	1
# of unexpected successes	2
# of expected failures		84
# of untested testcases		6
/data/video/matthias/egcs-19980824/gcc/testsuite/../xgcc version egcs-2.91.55 19980824 (gcc2 ss-980609 experimental)

		=== g77 tests ===


Running target unix

		=== g77 Summary ===

# of expected passes		415
		=== libio tests ===


Running target unix

		=== libio Summary ===

# of expected passes		40
		=== libstdc++ tests ===


Running target unix

		=== libstdc++ Summary ===

# of expected passes		30

configure flags: --with-gcc-version-trigger=/data/video/matthias/egcs-19980824/gcc/version.c --host=sparc-sun-solaris2.5.1 --prefix=/local/egcs-19980824 --norecursion
There are 0 warnings in stage3 of this bootstrap.

Number of warnings per file:

Number of warning types:

loop-2{f,g} failures

[Robert Lipe]

I have been adding another x86 target (essentially a SVR5-based target)
and trying to analyze two new failures that I haven't been seeing on
other similar x86 targets.  Linux doesn't fail.  OpenServer doesn't fail.
Unixware 2 doesn't fail.

The tests in question were loop-2f and loop-2g.  Now I see these exact
tests failing on Sparc/Solaris tests.  I think this means I can pretty
much quit staring at my new target-specific files. :-)

Can anyone briefly comment on these failures?  Are these known to be
fragile? In all the mmap voodoo in those test cases, have we perhaps
introduced a dependence on library/mmap/vm behaviour?


Thanx,
RJL


Matthias Mueller wrote:
> Native configuration is sparc-sun-solaris2.5.1
> 
> 		=== gcc tests ===
> 
> 
> Running target unix
> FAIL: gcc.c-torture/execute/980506-2.c execution,  -O2 
> FAIL: gcc.c-torture/execute/980506-2.c execution,  -O2 -g 
> FAIL: gcc.c-torture/execute/980506-2.c execution,  -Os 
> FAIL: gcc.c-torture/execute/980526-1.c execution,  -O2 -fomit-frame-pointer -finline-functions 
> FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 
> FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions 
> FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
> FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
> FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -g 
> FAIL: gcc.c-torture/execute/loop-2f.c execution,  -Os 
> FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 
> FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 -fomit-frame-pointer -finline-functions 
> FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
> FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
> FAIL: gcc.c-torture/execute/loop-2g.c execution,  -O2 -g 
> FAIL: gcc.c-torture/execute/loop-2g.c execution,  -Os 
> FAIL: gcc.dg/980626-1.c (test for excess errors)

Re: loop-2{f,g} failures

[Robert Lipe]

>   > I have been adding another x86 target (essentially a SVR5-based target)
>   > and trying to analyze two new failures that I haven't been seeing on
>   > other similar x86 targets.  Linux doesn't fail.  OpenServer doesn't fail.
>   > Unixware 2 doesn't fail.
>   > 
>   > The tests in question were loop-2f and loop-2g.  Now I see these exact
>
> They're designed to tickle very obscure bugs in the loop optimizer.
> It's unlikely they're bugs in your backend.


They must be really bizarre if they show up on Sparc/Solaris and UDK
targets on OpenServer but not any of the other x86 targets, including
OpenServer native.   

I'll move my focus back to someplace where I can make a productive
contribution.

Thanx for the info.  

RJL

Re: loop-2{f,g} failures

[Jeffrey A Law]

  In message < 19980826102017.C29439@dgii.com >you write:
  > I have been adding another x86 target (essentially a SVR5-based target)
  > and trying to analyze two new failures that I haven't been seeing on
  > other similar x86 targets.  Linux doesn't fail.  OpenServer doesn't fail.
  > Unixware 2 doesn't fail.
  > 
  > The tests in question were loop-2f and loop-2g.  Now I see these exact
  > tests failing on Sparc/Solaris tests.  I think this means I can pretty
  > much quit staring at my new target-specific files. :-)
  > 
  > Can anyone briefly comment on these failures?  Are these known to be
  > fragile? In all the mmap voodoo in those test cases, have we perhaps
  > introduced a dependence on library/mmap/vm behaviour?
They're designed to tickle very obscure bugs in the loop optimizer.
It's unlikely they're bugs in your backend.

jeff

Re: loop-2{f,g} failures

[Mark Mitchell]

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

    Robert> I have been adding another x86 target (essentially a
    Robert> SVR5-based target) and trying to analyze two new failures
    Robert> that I haven't been seeing on other similar x86 targets.
    Robert> Linux doesn't fail.  OpenServer doesn't fail.  Unixware 2
    Robert> doesn't fail.

    Robert> The tests in question were loop-2f and loop-2g.  Now I see
    Robert> these exact tests failing on Sparc/Solaris tests.  I think
    Robert> this means I can pretty much quit staring at my new
    Robert> target-specific files. :-)

    Robert> Can anyone briefly comment on these failures?  Are these
    Robert> known to be fragile? In all the mmap voodoo in those test
    Robert> cases, have we perhaps introduced a dependence on
    Robert> library/mmap/vm behaviour?

Those two tests both tickle a known bug in loop optimization whereby
induction variable signedness is not taken into account when doing
comparisons.  They fail for me on x86-linux-gnu.

I'm on the hook to fix them, by the way, and I haven't forgotten.
But, with 1.1 the big priority, and with other things to do, I've been
putting this off.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: loop-2{f,g} failures

[David S. Miller]

These tests fail on systems where the high bit of the address where
the process stack pointer resides is set.  Loop.c turns a signed
comparison into an unsigned one, but doesn't adjust all the
assosciated RTL along the way.  Loop requires quite a bit of surgery
to fix this, the bug is well understood though.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: loop-2{f,g} failures

[Joern Rennecke]

> Can anyone briefly comment on these failures?  Are these known to be
> fragile? In all the mmap voodoo in those test cases, have we perhaps
> introduced a dependence on library/mmap/vm behaviour?

The bug can only be shown if it is possible to obtain a piece of
memory where the sign of the address changes from positive to negative.

These tests only try the mmap approach; it is also possible to get such
memory in automatic arrays on the stack, but that needs root privileges to
raise the stack limit considerably.

Re: loop-2{f,g} failures

[David S. Miller]

   Date: Wed, 26 Aug 1998 20:53:48 -0600
   From: Jeffrey A Law <law@cygnus.com>

     In message < 19980826102017.C29439@dgii.com >you write:
     > Can anyone briefly comment on these failures?  Are these known to be
     > fragile? In all the mmap voodoo in those test cases, have we perhaps
     > introduced a dependence on library/mmap/vm behaviour?

   They're designed to tickle very obscure bugs in the loop optimizer.
   It's unlikely they're bugs in your backend.

Actually, as I state in another email, the bug hits all platforms,
what matters is that the pointers which become invariants in loop have
the high bit set or not.  Loop blindly turns signed comparisons into
unsigned ones when IV'ing integer comparisons into pointer based ones
used as loop test conditions, the signedness of the compare/branch in
the RTL is not changed to reflect this fact.  This is all over loop.c
and it's a mess.

In these tests, a pointer reference to the stack frame gets IV'd, so
depending upon whether the stack pointer has the most significant bit
set or not, you'll see the bug or you won't.

Later,
David S. Miller
davem@dm.cobaltmicro.com