+++ This bug was initially created as a clone of Bug #38776 +++
Request For Enhancement
I woukd like the created Makefile to build gcc using a different strategy
(compilation course) for "coverage" versus the strategy it uses for
"profiling". Both build strategies seems to follow the same course of
multi-stage compilation with only small changes in the gcc options depending
on whether "coverage", "profiling" or both (really slow) is desired.
I'm building gcc 4.4.0 20090109 on i386-pc-solaris2.11 (OpenSolaris 2008.11)
using gcc version 4.4.0 20090104. I have configured using
"--enable-coverage=noopt"
and started the build using "gmake". I have also configured without the
"--enable-coverage=" option and started the make using "gmake
profiledbootstrap".
>From what I can tell by observing the output from Make and examining the
scripts and Makefiles is that by trying to build for "coverage" and/or
"profiling" it seems to follow a similar course of:
1. building the option into the compiler early and then
2. using the altered-compiler for the remaining stages.
My point:
For "Profiling" (no additional ./configure options and initiate the 'make'
by typing "gmake profiledbootstrap") it makes (at least some) sense to
build-in "Profiling" early and then profile _all_ parts of the compiler
to find the speed of _all_ parts. It is a slow process to check _everything_
but without looking _everywhere_ you can't get the answer you need.
For "Coverage" (use the additional ./configure option of
"--enable-coverage=noopt" and initiate the 'make' by typing "gmake") it makes
_VERY_ little sense to build-in "Coverage" early and then check the
coverage of _all_ parts of the compiler to find if we use all of _all_
parts. We most likely do not. Will that day ever come? No.
If we did not use some portion of the toolchain in the build would we
then remove the code ? I think not. We do not care about the coverage
_during_ the build, it is likely most useful either for use compiling
our own Testsuite (to ensure we test _ALL_ the parts of the Toolchain)
or by the end user to test their own code.
We need a fast "C" compiler (and C++ compiler) to compile for coverage
the _other_ Tools but we do NOT need the "C" compiler to check it's own
coverage while it builds coverage into everything else that is TOO SLOW.
What I propose it that we have a new Makefile Target, we could call it
by typing "make coveragebootstrap".
The NEW course of compilation for building "coverage" would be to:
1. Build the "C" and "C++" compiler _without_ coverage to create xgcc.
2. Build the remaining Languages _with_ coverage (using the non-coverage-
altered-xgcc or xg++ compilers, which will be _much_ faster).
3. Build the Libraries _with_ coverage (using the non-coverage-altered-xgcc
or xg++ compiler).
4. Go back and rebuild the "C++" compiler _with_ coverage (using the
non-coverage-altered-xgcc compiler).
5. Go back and rebuild the "C" compiler _with_ coverage (using the non-
coverage-altered-xgcc compiler).
6. Now all Tools and Libraries will be built _with_ coverage by a compiler
_without_ coverage (and the associated constant updating of the statistics
files).
7. You can install now by typing "make install" and get a Toolchain that
when executed will save it's statistics files with it's executables (with
the source code remaining where it is)
8. You can execute the Testsuite by typing "make -i check" and check the
coverage of the Testsuite. This is probably the 'most-intended' feature
of "coverage", best to get it operating fast than letting it build slow.
The only downside it that in exchange for being able to compile the Toolchain
much quicker is that you won't be able to determine if every portion of the
"C" compiler was used to compile the "C" compiler. Chances are good that we
do not use _all_ of the "C" compiler to compile gcc and that we won't be
ripping out all the code we don't use. Loss of this feature means loss of
nothing since we can always use the Makefile the old-way if we would wish to.
Questions?
Thanks for reading this,
Rob
--
Summary: RFE - Need Makefile to build using different strategy
for "coverage" vs. "profiling"
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: *-*-*-*
GCC host triplet: *-*-*-*
GCC target triplet: *-*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38792
