From owner-freebsd-hackers  Thu Apr 24 21:33:16 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id VAA22849
          for hackers-outgoing; Thu, 24 Apr 1997 21:33:16 -0700 (PDT)
Received: from siesta.cs.wustl.edu (nw1@siesta.cs.wustl.edu [128.252.165.3])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA22844
          for <hackers@freebsd.org>; Thu, 24 Apr 1997 21:33:13 -0700 (PDT)
Received: from localhost by siesta.cs.wustl.edu (SMI-8.6/ECL-J1.00)
	id XAA11988; Thu, 24 Apr 1997 23:32:58 -0500
Message-Id: <199704250432.XAA11988@siesta.cs.wustl.edu>
To: Warner Losh <imp@village.org>
cc: hackers@freebsd.org
Subject: Re: Any compiler guru? (Was: 2 questions about C++ support in 2.2) 
In-reply-to: Your message of "Wed, 23 Apr 1997 21:19:54 MDT."
             <E0wKF4c-0001kZ-00@rover.village.org> 
Date: Thu, 24 Apr 1997 23:32:56 -0500
From: Nanbor Wang <nw1@cs.wustl.edu>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> In message <199704231911.OAA17121@siesta.cs.wustl.edu> Nanbor Wang writes:
> : /var/tmp/cc022478.s:16783: Warning: GOT relocation burb: `__vt$15ACE_Local_Mutex
> 
> These are "normal" and "OK".  They are warning about a condition that
> is harmless.  Generally, an inlined virtual function that is trying to
> be local...  A bad practice because many compilers don't handle this
> legal C++ construct.  Yes, this is a bug and should be fixed, but
> people who can fix it haven't found the time yet to do so.

Yes, although I haven't tested the shared library extensively, it
appeared to be ok on several test programs. 

> 
> : ACE.  After spitting out a lot of GOT warnings, the compiler finally
> : spited out "Compiler internal error" and went dead.  
> 
> Hmmm, that's bad.  I don't think that is related to the above
> messages.

Any recommendation where to look first?  I am totally clueless.  All
g++ said was internal error.  ;(

> 
> : I have no idea at all as this problem is caused by incorrect g++
> : behavior or by lame assembler (binutil?)   Is there a quick fix for
> : this?  Has any one solved this problem before?  Will switching to gcc
> : 2.7.2.2 help?  Or, we should get a better binutil?  
> 
> The internal compiler error won't be helped by getting new binutil.
> And 2.7.2.2 won't help either, since it just add support for
> Linux-alpha related stuff.  g++ also isn't the worlds best C++
> compiler.  Every time I've gone to write something moderately
> complicated, I've fired off a bug report to the appropriate people
> :-(.

That's for sure, but we don't seem to have any other choice.  

Thanks,

nw