This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: -fno-rtti in breaks building go? (older g++, -disable-bootstrap)

> --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.

> Since the OP is apparently seeing Go build in stage 1, I assume that the
> OP is configuring with --disable-bootstrap or with

Right. I thought I was clear on that.

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"?
i.e. remove those lines in configure and more fairly reasonable stuff works?

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.

Heck maybe rtti and exceptions are decent enough out there that stage1 could use them??

I "always" use -disable-bootstrap.
So much gain for acceptable pain.
I know I'm cutting corners, but I'm in active development of very small changes.

My bootstrap compiler isn't super wierd/bad, just a somewhat old gcc/g++.
? (I have relatively recently bootstrapped from K&R cc on HP-UX though gcc 3.x to get to gcc 4.x, and buggy
? compilers I think on Irix that slightly miscompile GNU make, forcing one to loop back with
? gcc and rebuild make and then rebuild gcc (maybe in-tree the first time, I forget..I should check my notes..)..
But anyway...

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..

I really just wanted to step through gccgo to understand its implementation to inform my own front end work.
(Yes, go is certainly an interesting hybrid -- native code + static compilation + static typing + C-like syntax + garbage collection + fast compilation
via a good module system instead of the C preprocessor toiling over the same million lines repeatedly... -- you don't see that often. :)

Thank you,
?- Jay

> From:
> To:
> CC:;;
> Subject: Re: -fno-rtti in breaks building go? (older g++, -disable-bootstrap)
> Date: Sun, 20 May 2012 22:41:08 -0700
> Gabriel Dos Reis <> writes:
> > On Mon, May 21, 2012 at 12:08 AM, Ian Lance Taylor <> wrote:
> >> Gabriel Dos Reis <> writes:
> >>
> >>> On Sun, May 20, 2012 at 10:30 PM, Ian Lance Taylor <> wrote:
> >>>
> >>>> To be clear, as far as I can see the Go frontend isn't doing anything
> >>>> wrong or dubious.  It just happens to #include <tr1/unordered_map> when
> >>>> it is available but <unordered_map> is not.  It looks like in gcc 4.0
> >>>> you can not #include <tr1/unordered_map> when using -fno-rtti.
> >>>>
> >>>> We could work around this by changing gcc/ to check whether
> >>>> that #include <tr1/unordered_map> works with -fno-rtti.  If that fails,
> >>>> the Go frontend will next try <ext/hash_map>.
> >>>
> >>> Is it unacceptable for the Go front-end to use the stage1 g++, especially
> >>> as we are moving toward switching to C++?
> >>
> >> The Go frontend does use the stage1 g++.
> >>
> >> I assume that this error can only occur when using --disable-bootstrap
> >> or when building Go in stage 1.  I don't see how this error could occur
> >> when building stages 2 or 3 of a bootstrap.
> >
> > OK. In that case, maybe make Go build only in stage2.
> By default, Go will only build in stages 2 and 3.
> Since the OP is apparently seeing Go build in stage 1, I assume that the
> OP is configuring with --disable-bootstrap or with
> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by
> the way.)
> That is, normally, everything should be fine. But if you use unusual
> configure options you can definitely get into unusual cases. Ideally
> those cases should be made to work if possible. It's not very
> important, though.
> Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]