On Mon, 19 Nov 2012, Lawrence Crowl wrote: > On 11/17/12, Hans-Peter Nilsson <h...@bitrange.com> wrote: > > On Thu, 15 Nov 2012, Diego Novillo wrote: > > > === Approach: Move GTY to cc1plus. > > > > > > Instead of a separate weak parser, we would make cc1plus > > > understand GTY attributes. The compiler would emit IL in the > > > object files instead of generating source. > > > > > > This solution would require a first boot stage that did not > > > support PCH, because we cannot rely on the seed compiler > > > supporting GTY. We would probably need to use the Boehm > > > collector during the first stage as well. > > > > > > Because the first stage would be fundamentally different from the > > > second stage, we may need to add an additional pass for correct > > > object file comparisons. > > > > It sounds like this would, for cross-compilers, require a native > > GTY-savvy g++? Please no. > > We cannot require a GTY savy seed compiler. In part, at least, > because we do not have one now. :-) > > So, the GTY annotations would need to be invisible to the seed > compiler. The implication is that the first built compiler does > not have GGC and PCH. The first built compiler would, however, > recognize GTY, and the second (and subsequent) built compiler would > have these features.
JFTR: above, I'm very explicitly referring to cross-compilers. For your comments above to be relevant to them, you seem to imply a different workflow for building cross-compilers than the current, in which one and the same host compiler builds a cross-compiler in a single stage. Currently there's no "second (and subsequent) built compiler" for the cross-compiler-build scenario; if you're referring to the just-built cross-compiler it doesn't matter whether it's GTY-savvy. Just mentioned in case this becomes relevant again; with Boehm GC or reference-counting pointers (I hope) it doesn't matter. It's similar to the native-compiler scenario only as far as requirements for the host compiler (compiling the first stage); you can "fix" both scenarios by requiring the host-compiler to be GTY-savvy. But for that to IMHO be tolerable, a few versions of GTY-savvy GCC have to be released before making any such a requirement. Not to mention that the first such release would likely contain bugs serious enough to be unusable for later versions. But you already agree that's not what should happen, so mentioned JFTR. > Because the first built compiler would not have GGC, we need some > other memory management, and the Boehm collector is the nearest > handy tool. I'd think the reference-counting-pointer scheme mentioned by others would be preferable as requiring less memory overhead but there you go. Trading one GC for another is simpler and better I guess, at least as a functional intermediate step. Maybe refcounting pointers can be better introduced later, if ever and measurably better. brgds, H-P
