egcs-20000131 c++ inline code generation broken

[Martin Buchholz]

>>>>> "ZW" == Zack Weinberg <zack@wolery.cumb.org> writes:

ZW> On Wed, Feb 02, 2000 at 09:04:53PM -0800, Martin Buchholz wrote:
>> Because I'm insane, I compile XEmacs with C++ compilers.  I get a
>> crash when building with egcs-20000131 c++.

ZW> I cannot reproduce this crash with gcc-20000129 c++ on ix86-linux.  I
ZW> will try again with top of trunk, but you may be interested in the
ZW> details.

ZW> I configured with CC=gcc-2000129, then edited config.status to make
ZW> CC, XEMACS_CC, etc. equal to g++-2000129, reran config.status, and
ZW> built.  (Due to bugs in Autoconf, configure bombs out if you make CC
ZW> a C++ compiler.)

Wow!  I didn't expect you to do this!

Compiling with a C++ compiler is `unsupported'.  I do it primarily as
a useful quality exercise.  The more compilers your code has seen, the
more likely it is to work on some stranger's system.  This is also why
I randomly build with -fsigned-chars, for example.

The way I do it (simplified) is

CC=gcc-2000129 XEMACS_CC=g++-20000129 configure ...
make

ZW> A lot of the code in the lib-src directory needed to be worked over
ZW> before it would compile.  I can send the patch if anyone cares.

Because autoconf is not C++ clean, you need to configure with a C
compiler, then `make' with a C++ compiler.  I only do this for the
xemacs binary itself.  The problem with lib-src is that much of the
code is imported from other maintainers.  For example, etags.

ZW> The makefile attempts to link temacs by hand and gets it horribly
ZW> wrong, causing the built temacs to crash inside libc startup code.

ZW> You're doing something like gcc -nostdlib pre-crt0.o /usr/lib/crt1.o
ZW> /usr/lib/crti.o <objects> <X libraries> -ldl -lgcc /usr/lib/crtn.o

All of this will go away near term, once we switch to the `Portable Dumper'.

ZW> First off, -nostdlib doesn't turn off automatic linking with crt1 in
ZW> all versions of gcc.  You need -nostartfiles too.  Second, you
ZW> forgot /usr/lib/gcc-lib/TARGET/VERSION/crtbegin.o and .../crtend.o,
ZW> which means global constructors won't be run.  (I think this is why
ZW> it crashes; libc has global constructors.)  Third, you forgot libc!
ZW> It gets dragged in by dependencies of the other libraries, but not
ZW> properly.

ZW> None of this nonsense is actually necessary; the only point that I
ZW> can see is to define 'data_start', and crt1.o does that for you on
ZW> this platform.

ZW> Once I fixed that, the build then completed successfully.  I
ZW> dumped xemacs from within gdb, as you did, with no errors.

ZW> make check gets some errors, but these appear to be unrelated.

These are OK.

ZW> $ make check
ZW> cd ./src && make check
ZW> make[1]: Entering directory `/work/build/xemacs/src'
ZW> ./xemacs -batch -l \
ZW>   /work/src/xemacs-21.2/src/../tests/automated/test-harness.el -f \
ZW>   batch-test-emacs /work/src/xemacs-21.2/src/../tests/automated 
ZW> Testing /work/src/xemacs-21.2/tests/automated/base64-tests.el...
ZW> base64-tests.el: 1232 of 1232 (100%) tests successful.  
ZW> Testing /work/src/xemacs-21.2/tests/automated/byte-compiler-tests.el...
ZW> Unexpected error (void-function defadvice) while executing interpreted code.  
ZW> Test suite execution aborted.
ZW> Unexpected error (void-variable message) while executing byte-compiled code.
ZW> Test suite execution aborted.
ZW> byte-compiler-tests.el: No tests run
ZW> Test suite execution failed unexpectedly.
ZW> Testing /work/src/xemacs-21.2/tests/automated/database-tests.el...
ZW> database-tests.el: No tests run
ZW> Testing /work/src/xemacs-21.2/tests/automated/hash-table-tests.el...
ZW> hash-table-tests.el: 8570 of 8570 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/lisp-tests.el...
ZW> lisp-tests.el: 3262 of 3262 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/md5-tests.el...
ZW> md5-tests.el: 56 of 56 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/mule-tests.el...
ZW> mule-tests.el: 2 of 2 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/symbol-tests.el...
ZW> symbol-tests.el: 226 of 226 (100%) tests successful.
ZW> Testing /work/src/xemacs-21.2/tests/automated/syntax-tests.el...
ZW> syntax-tests.el: 56 of 56 (100%) tests successful.
ZW> Done

ZW> I conclude: either the problem you hit was introduced after the
ZW> 20000129 snapshot, or it was caused by old object files or C/C++
ZW> incompatibilities.

Also, the development work is on a branch, not the trunk.  (We're
planning to fix that someday).  http://cvs.xemacs.org/

I offer a login to my machine, so that you can see the crash in
person.  Happens reliably.  Send me your ssh public key.  

Bug happens in both egcs-20000124 and egcs-20000131.

I think the difference in the stack traces for the functions was only
the absence/presence of -g and -O3 flags.  After all, this is an
optimizer bug, but debugging is helped by _not_ optimizing.

Here is a stack trace containing exclusively 
make CFLAGS='-g -O3'
object files.

(gdb) where 10
#0  0x40293111 in __kill ()
#1  0x40292d66 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x40294447 in abort () at ../sysdeps/generic/abort.c:88
#3  0x8085891 in assert_failed () at /xemacs/ws/dev/src/emacs.c:2818
#4  0x8052ff2 in make_uninit_string__Fl (length=-1) at /xemacs/ws/dev/src/alloc.c:1858
#5  0x80575b8 in make_string__FPCUcl (contents=0x8395a80 "Loading /xemacs/build/moS+/lisp/keydefs.elc...", length=-1) at /xemacs/ws/dev/src/alloc.c:2112
#6  0x812178e in echo_area_message__FP5framePCUcllll (f=0x82d1af8, nonreloc=0x0, reloc=137720740, offset=0, length=-1, label=136699748) at /xemacs/ws/dev/src/minibuf.c:740
#7  0x8121a38 in message__FPCce (fmt=0x81be828 "Loading %s...") at /xemacs/ws/dev/src/minibuf.c:810
#8  0x8118164 in Fload_internal__Fllllll (file=137710860, no_error=136581276, nomessage=136581276, nosuffix=136581276, codesys=136581276, used_codesys=136581276) at /xemacs/ws/dev/src/lread.c:674
#9  0x8089ac1 in Feval__Fl (form=137207320) at /xemacs/ws/dev/src/eval.c:2974
(More stack frames follow...)