This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Top-level profiledbootstrap bugfixes
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>,Nathanael Nerode <neroden at twcny dot rr dot com>
- Date: Wed, 22 Jun 2005 20:19:50 +0200
- Subject: Re: [PATCH] Top-level profiledbootstrap bugfixes
- References: <42B963FA.email@example.com>
> When adding support for profiled toplevel bootstrap, I had the wrong
> impression that the training is done while building the runtime
> libraries, and I coded the toplevel bootstrap support accordingly.
> Instead, it is done only on building GCC itself!
It was originally done by building the runtime libraries (otherwise you
won't get coverage for non-C frontends). It was changed for some
reason, but I would pretty much welcome getting this back.
> I don't know the exact reason for this in the "old-style" bootstrap
> rules. In the case of toplevel bootstrap, however, training on
> the host and target modules is breaking Java profiledbootstraps:
> stageprofile-fastjar is compiled without -fprofile-generate and tries to
> link to a profile-enabled zlib. It is already an improvement
> to train the compiler on libcpp and libiberty (on a combined tree,
> gas/ld/binutils too), anyway.
Ideally we should get libcpp being trained as well, but not build
profile enabled runtime libraries as we can't train them well anyway...
But anyway your patch seems good (at least better than what we have