results of "make check"

results of "make check"

[Kate Hedstrom]

The freeBSD system gives:

gecko% gcc -v
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-freebsd2.1.6/egcs-2.90.02/specs
gcc version egcs-2.90.02 970825 (gcc2-970802 experimental)

                === gcc Summary ===

# of expected passes            4835
# of unexpected failures        42
# of expected failures          4
# of unsupported tests          7

                === g++ Summary ===

# of expected passes            3268
# of unexpected successes       2
# of expected failures          81
# of untested testcases         6

This doesn't strike me as alarmingly bad, whereas the RS6000 results do:

pequod% config.status
creating Makefile
creating config.h
config.h is unchanged
Merged rs6000/x-rs6000.
Merged rs6000/t-newas.
Created `cp/Makefile'.
Merged rs6000/x-rs6000.
Merged rs6000/t-newas.
Created `f/Makefile'.
Merged rs6000/x-rs6000.
Merged rs6000/t-newas.
Created `objc/Makefile'.

                === gcc Summary ===

# of expected passes            2094
# of unexpected failures        1483
# of expected failures          4
# of untested testcases         1302
# of unsupported tests          7

                === g++ Summary ===

# of expected passes            2258
# of unexpected failures        559
# of unexpected successes       2
# of expected failures          532
# of untested testcases         6

This is on a system with 128 MB of RAM, in which no one else was logged
in or running any jobs.  My limits are:

pequod% limit
cputime         unlimited
filesize        1048575 kbytes
datasize        131072 kbytes
stacksize       32768 kbytes
coredumpsize    1024 kbytes
memoryuse       102400 kbytes

A typical failure message is:

Executing on host: /d0/kate/gnu/egcs-970825/gcc/xgcc -B/d0/kate/gnu/egcs-970825/gcc/
/d0/kate/gnu/egcs-970825/gcc/testsuite/gcc.c-torture/compile/920413-1.c -w
  -O0   -c  -o /tmp/920413-1.o   
compiler exited with status 1
output is:
xgcc: Internal compiler error: program cc1 got fatal signal 6

FAIL: gcc.c-torture/compile/920413-1.c,  -O0  

Kate

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <199708272108.OAA10071@cygnus.com>you write:
  > The autoconf support guarantees that config.h will always define free
  > (ignoring for the moment the known minor problems with it).  Since every
  > file must already be including config.h, we can fix this problem simply
  > by deleting every declaration of free.
I'm not much of an autoconf person.  Are you suggesting something
like this be added to acconfig.in after the #undef NEED_DECLARATION_FREE?

#ifdef NEED_DECLARATION_FREE
extern void free ();
#endif

Then delete the various declarations of free found throughout the
sources?

Note you can't use PROTO here because we haven't sucked in gansidecl.h
yet.

Jeff

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <199708271943.PAA14251@caip.rutgers.edu>you write:
  > 	Presumably, this is what the autoconf test GCC_NEED_DECLARATION
  > is used for in configure.in. 
  > 
  > 	I.e. you could do something like this:
  > 
  >  > #include <various system headers>
  >  > 
  >  > #ifdef NEED_DECLARATION_FREE
  >  > void free PROTO ((void *));
  >  > #endif
Well, at least short term the problem with this is only the
c++ front end includes stdlib.h -- c, g77 and objc don't
include it, and thus if autoconf decided that a decl wasn't
needed because one existed in stdlib.h, then we end up losing.

What you're suggesting was basicly the first thing I tried.

I think we can work around this by putting the conditional
declaration of free in config.h (via acconfig.h -> config.in).

My only problem with that is I'm not familiar enough with autoconf
to know if something like that's considered "reasonable".

jeff

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <m0x3nnE-0004ecC@ocean.lucon.org>you write:
  > I thought gcc fixincludes took care of it.
fixincludes fixes stuff for the target, not the build machine, thus
fixincludes is worthless for this problem.

  > Can you add
  > 
  > extern void free ();
  > 
  > to confdefs.h to see if <stdlib.h> is really ok?
Kinda gross, but an interesting alternative.  Might be worth a
try if changing acconfig.h to conditionally declare free is
considered a poor solution.

jeff

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <199708271912.OAA28994@monolith.solon.com>you write:
  > Also, that will break on at least one system, StunOS, which (as I recall)
  > ends up having 'int free(char *)', and declares it in some header typically
  > included... So, you can't just take all the prototypes out, because gcc2
  > takes the address of free(), so it needs a declaration, but you can't just
  > declare it correctly, because some systems are wrong, and...
Which is _precisely_ why we need to handle more and more of this
stuff with autoconf!

Jeff

ps.  sunos is the host where I first ran into the problem after
the c++ folks added the stdlib.h includes.