[again as plain text, sorry, with edits] I know gccgo is actually C++. But why was no-rtti specified? Maybe that is for the other code, the C code?
But I see: > and using -fno-rtti saves some space in the generated compiler. Is it worth it? I guess you could configure with and without -fno-rtti + #include <unordered_hashmap> and use the combination that works? Kind of you said that, but alternatively, use unordered_hashmap either way, but only -fno-rtti if it works? I do realize though there is another factor, it might be interesting to use just map, for older compilers/libraries, since unordered is "new". Thank you, sorry, I'm in a rush right now, - Jay > From: i...@google.com > To: jay.kr...@cornell.edu > CC: g...@integrable-solutions.net; jwakely....@gmail.com; gcc@gcc.gnu.org > Subject: Re: -fno-rtti in configure.ac breaks building go? (older g++, > -disable-bootstrap) > Date: Mon, 21 May 2012 06:48:08 -0700 > > Jay K <jay.kr...@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.kr...@cornell.edu, I'm getting a bounce > from cashub03.exchange.cornell.edu saying > > ----- The following addresses had permanent fatal errors ----- > jay.kr...@gmail.com > (reason: 550 5.7.1 Unauthenticated email is not accepted from this domain. > r15si1037948qct.2) > (expanded from: <j...@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
