Re: gcc-2.8.0-971225 build failure due to asserts in GCC

[Paul Eggert <eggert at twinsun dot com>]

   From: Ken Raeburn <raeburn@cygnus.com>
   Date: 29 Dec 1997 14:55:12 -0500

   eggert@twinsun.com (Paul Eggert) writes:

   > The problem is that some assert calls have crept into the GCC code
   > over the past few weeks.

   Why is the old compiler seeing any of gcc's header files?

Because the old compiler is used as follows:

	gcc -c  -DIN_GCC   -g   -DHAVE_CONFIG_H    -I. -I. -I./config except.c

and the "-I." causes GCC's assert.h to be included.  (In this case the
old compiler is an old version of gcc, and it requires an old,
incompatible assert.h.)

GCC's assert.h has an `#ifndef __GNUC__' that prevents this problem
from occurring if the old compiler is not GCC; but in BSD/OS 3.0 the
old compiler is GCC, so the `#ifndef __GNUC__' doesn't work.


   > The simplest way to work around this problem is to not include
   > assert.h in GCC proper.

   I'd suggest doing that only if you have problems with "native" assert
   implementations.

My problems were with combining of "native" assert implementations
with GCC's assert.h, as exemplified above.  There are more details
about this in my original bug report; please ask me if I'm still not
being clear enough here.


Another way to fix the problem is to arrange things so that GCC's
assert.h is not in the include path when compiling with the old
compiler.  This might be a better solution in the long run, since it
will allow assert's in GCC, but I thought this too tricky to do just
before a release.

Also, I have the impression that `assert (E);' is frowned upon inside
GCC, and that using `if (! (E)) abort ();' is the preferred style as
it's more efficient and is just as easy to debug; so perhaps we should
just continue to discourage `assert (E);'.

While we're on the subject, I think assert.h's `#ifndef __GNUC__' can
be removed after my patch is installed, as assert.h should never be
included by a non-gcc compiler; but this can wait until after 2.8
comes out.