Re: Workaround egcs-20000131 c++ compiler bug

[Zack Weinberg <zack at wolery dot cumb dot org>]

On Thu, Feb 03, 2000 at 01:52:16PM -0800, Martin Buchholz wrote:
> >>>>> "ZW" == Zack Weinberg <zack@wolery.cumb.org> writes:
> 
> >> +#if defined (__GNUC__) && defined (__cplusplus)
> >> +  alloca (4);
> >> +#endif
> 
> ZW> The effect of that is simply to shut off the RTL inliner for that
> ZW> function.  Is it marked 'inline', and if not, could you add that to
> ZW> the declaration and see if the problem comes back?  (The tree inliner,
> ZW> which only exists in C++, will inline functions that use alloca, but
> ZW> not functions that were not explicitly declared as inline.)
> 
> I may not have understood your question completely the first time.

The C++ compiler has two independent mechanisms for inlining
functions.  The older, RTL-based inliner cannot handle functions that
use alloca.  The newer, tree-based inliner can.  (I *think* the
eventual plan is to scrap the RTL inliner.)

At -O3 gcc attempts to inline every function, even the ones not marked
inline.  gcc permits inline exported functions; it will inline them in
the same file, and leave a normal copy for callers from elsewhere.
(So you probably didn't need to mess with the external dependencies.)
However, the automatic inlining at -O3 uses only the RTL inliner.  The
tree inliner is never used unless the function is marked inline.

My first hypothesis was that the problem was with the RTL inliner.  By
adding an alloca call and an inline marker, you switched to using the
tree inliner exclusively.  If that made the bug go away, then we could
have focused on RTL inlining.  It doesn't, so we can conclude the
problem is elsewhere, but provoked by inlining echo_area_append into
echo_area_message.

...
> And the stack trace shows that echo_area_append() was in fact inlined
> into its caller echo_area_message(), despite the warning that it could
> not be.  So this warning also needs to be fixed.  Don't lie to the user!

Agree.  Probably the C++ front end should not use the RTL inliner at
all.  Anyone from the C++ team know why it uses both?

> #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  0x8089141 in assert_failed () at /xemacs/ws/dev/src/doprnt.c:890
> #4  0x80532f2 in make_uninit_string () at /xemacs/ws/dev/src/abbrev.c:463
> #5  0x80578f8 in make_string () at /xemacs/ws/dev/src/abbrev.c:463
> #6  0x812dc5e in echo_area_message__FP5framePCUcllll (f=0x82e0258, nonreloc=0x0, reloc=137780028, offset=0, length=-1, label=136758932) at /xemacs/ws/dev/src/minibuf.c:740
> #7  0x812df08 in message__FPCce (fmt=0x81ccc08 "Loading %s...") at /xemacs/ws/dev/src/minibuf.c:864

This is interesting.  Frames 0-2 are in libc - that's fine.  Frames
3-5 are in code apparently compiled by the C compiler, and the file
and line info is totally bogus.  Maybe this is not a miscompilation,
but an ABI problem, or a stale object file problem.  I'll try to
reproduce this with my copy of the xemacs tree, but can you do a
rebuild from scratch and make sure that everything is compiled with
the C++ compiler?

zw