[Bug c/8108] Problem in the code generator for C and the linker is extremelly slow
manuel dot serrano at sophia dot inria dot fr
gcc-bugzilla@gcc.gnu.org
Tue Mar 30 13:41:00 GMT 2004
------- Additional Comments From manuel dot serrano at sophia dot inria dot fr 2004-03-30 13:41 -------
Subject: Re: Problem in the code generator for C and the linker is extremelly slow
> No, when we start building large systems with lots of automatically
> generated code, we run into this problem quite relyably, not only for
> one system. Sticking with an old gcc is currecntly also the only option
> for us :-(.
I see, we are having the very same troubles and very same solutions :-(
> >The gcc3.2's option "-fno-merge-constants" gets rid of the problem.
> >Unfortunately it has no effect with gcc3.3 (well, I have not tested recent
> >versions, may be this has improved now).
> >
> >
> Unfortunately, this is not really the case for us. We do not have that
> many string constants in our code, so setting this option does not
> change our linking times at all. What seems to be the killer for me is
> the debug information. Currently there is no option to treat debug info
> as non-mergable. I have already seen a gcc patch floating around that
> achieves this, but I don't think that it is considered for inclusion
> into the main gcc development, or even has been submitted.
Same things for me. The real pain is when I try to compile in C debug mode...
> There is a version of the binutils in the making (2.15) which will solve
> the problem from the point of view of ld. They have a much improved
> string merging algorithm that reduces link times for me from ~3000s to
> ~40s. This is still worse than the original ~7s (for gcc-2.95.x
> generated objects) but it is 2 orders of magnitudes down.
I would by, at once, a 2x slowdown ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8108
More information about the Gcc-bugs
mailing list