This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
Jay K <jay.krell@cornell.edu> writes:
>> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by
>> the way.)
>
> I don't know why.
> I'm getting them, at least via the list.
For every e-mail I send to jay.krell@cornell.edu, I'm getting a bounce
from cashub03.exchange.cornell.edu saying
----- The following addresses had permanent fatal errors -----
jay.krell@gmail.com
(reason: 550 5.7.1 Unauthenticated email is not accepted from this domain. r15si1037948qct.2)
(expanded from: <jmk3@mail.cornell.edu>)
I would send you more details off-list but you probably wouldn't get
them.
> So I guess there is nothing to see here..move along..but..why the use of -fno-rtti?
> It seems like a guess of "more work for less good"?
GCC does not use RTTI information, and using -fno-rtti saves some space
in the generated compiler.
> I can see maybe the opposite though.
> Maybe the point is to avoid poor rtti implementations in old gcc bootstrap??
> Or maybe the point was to compile C, really C code, with g++, and turn off "gratituitous"
> C++ features that the code "doesn't even come near" (i.e. the bulk of gcc really is C
> that is compatible with gcc, vs. the go frontend that is currently a rare case of "actual C++".
> Â If that's the rationale, again, maybe the lines should just be removed. I understand this is
> Â much to do about very little.
No, that's not it. The Go frontend is actual C++, but it doesn't use
RTTI either. What you are running into is a bug in the GCC 4.0
implementation of -fno-rtti.
> I don't want to change a header and have make go through and build the compiler multiple times.
> I have enough problems with incrementality building way too much..that I should look into..
The correct fix is the one I alluded to earlier: change the mainline
gcc/configure.ac to test whether <tr1/unordered_map> works correctly
when using -fno-rtti. That would detect the buggy GCC 4.0
implementation, and avoid using <tr1/unordered_map> in that case.
Ian