This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Results for haifa-enabled egcs-2.91.42 19980621 (gcc2 ss-980502 experimental) testsuite on sparc-sun-solaris2.5.1


Joe Buck <jbuck@synopsys.com> writes:
> Horst von Brand and I both tested 19980621 on sparc-sun-solaris2.5.1
> but got different results for the g++ tests.
> 
> Horst gets
> 
> > Running target unix
> > FAIL: g++.law/code-gen5.C (test for excess errors)
> > FAIL: g++.robertl/eb101.C (test for excess errors)
> > FAIL: g++.robertl/eb129.C (test for excess errors)
> > FAIL: g++.robertl/eb130.C (test for excess errors)
> > FAIL: g++.robertl/eb131.C (test for excess errors)
> > FAIL: g++.robertl/eb56.C (test for excess errors)
> > FAIL: g++.robertl/eb91.C (test for excess errors)
> > 
> > 		=== g++ Summary ===
> > 
> > # of expected passes		4165
> > # of unexpected failures	7
> > # of expected failures		86
> > # of untested testcases		6

I get something similar.

> I get
> 
> FAIL: g++.robertl/eb101.C (test for excess errors)
> FAIL: g++.robertl/eb129.C (test for excess errors)
> FAIL: g++.robertl/eb130.C (test for excess errors)
> FAIL: g++.robertl/eb131.C (test for excess errors)
> FAIL: g++.robertl/eb56.C (test for excess errors)
> FAIL: g++.robertl/eb91.C (test for excess errors)
> 
> 		=== g++ Summary ===
> 
> # of expected passes		4167
> # of unexpected failures	6
> # of expected failures		85
> # of untested testcases		6
> 
> I have one fewer failure.  But I don't know why I have two more passes.
> 
> Horst, what output do you get when you run g++.law/code-gen5.C ?

I'm not Horst, but I get the following output for g++.law/code-gen5.C:

  compiler exited with status 1
  output is:
  In file included from ...egcs/build/sol2/gcc/testsuite/../include/math.h:5,
		   from ...egcs/build/sol2/gcc/testsuite/../include/math.h:5,
		   from ...egcs/gcc/testsuite/g++.old-deja/g++.law/code-gen5.C:13:
  /usr/include/math.h:19: `__P' redefined
  /usr/local/include/sys/cdefs.h:58: this is the location of the
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  previous definition
  FAIL: g++.law/code-gen5.C (test for excess errors)
[snip]
  XFAIL: g++.law/code-gen5.C  Execution test

And, here's what libio/ChangeLog has to say:

      * libio.h:  If _G_HAVE_SYS_CDEFS, get __P from <sys/cdefs.h>.
                                                     ^^^^^^^^^^^^^^
Here's the defn. of __P from sys/cdefs.h:

  #define __P(protos)     protos          /* full-blown ANSI C */

Here's the defn of __P in math.h:

  #ifdef __STDC__
  #define __P(p)  p
  #else
  #define __P(p)  ()
  #endif

And libio.h:

  #ifndef __P
  # if _G_HAVE_SYS_CDEFS
  #  include <sys/cdefs.h>
  # else
  #  ifdef __STDC__
  #   define __P(p) p
  #  else
  #   define __P(p) ()
  #  endif
  # endif
  #endif /*!__P*/

Without sys/cdefs.h, libio.h and math.h define __P with the same tokens.
With sys/cdefs.h, libio.h and math.h define __P with different tokens.
Thats why the redefn. probably didn't affect you, while it did me.

Maybe, libio.h should #undef __P once it is done.

BTW, /usr/local/include/sys/cdefs.h was probably installed on our m/cs
as part of the db package.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]