[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a

[roger at eyesopen dot com]

------- Comment #9 from roger at eyesopen dot com  2007-11-02 17:12 -------
Doh!  DJ's patch gets us a little further, but it things are still broken. 
However, it's an excellent debugging tool which shows that its the invocation
with libgcc-objects-15 that's broken.  Applying the same trick as above shows
that $libgcc-objects-15 alone is 19962 bytes, which combined with the "ar"
etc.. at the beginning of the command line exceeds the limits.

So it's the "fixed-conv-funcs" that are to blame.  Perhaps "gen-fixed.sh" has
gone insane with the large number of integer-like machine modes on MIPS.  The
correct fix might actually be in the optabs handling of the middle-end, so we
don't need quite so many conversion functions in MIPS' libgcc.a.  Or perhaps
mips.md need improved support (patterns) for this functionality.

I've no idea what _satfractunsUTIUHA is, it's a recent addition and I've not
been following gcc-patches lately.  Splitting "_fract*" from "_sat*" with a
patch similar to DJ's should work.

I hope this is enlightening.  Is there a --disable-option to avoid building
fixed point conversion support?  Looks like our command line usage is O(n^2)
in the number of backend integer machine modes?

Thanks again for everyone's help on this.  I'll owe you beers at the next
GCC summit.

Roger
--


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781