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
