Re: Patch to define __NO_STRING_INLINES in system.h

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Zack Weinberg <zack@codesourcery.com>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > > As reported here
 > > http://gcc.gnu.org/ml/gcc-patches/2003-01/msg01104.html
 > >
 > > the string inlines from glibc systems cause warnings when
 > > bootstrapping gcc.  I've prepared a patch to define
 > > __NO_STRING_INLINES in system.h to avoid this.  This is probably
 > > necessary on all glibc systems, not just x86-linux-gnu.
 > >
 > > Besides zapping the warnings, I think this is good for two extra
 > > reasons.  First, the change helps our technology because it helps
 > > ensure much wider use of and therefore wider testing of our compiler
 > > string builtins during bootstrap.  Second, it's good policy because it
 > > projects our confidence in our own mechanism for these optimizations.
 > 
 > While I am entirely in favor of this patch, I do have to point out
 > that making just this change causes a slight, consistent increase in
 > the text size of all the compiler binaries.  (i686-linux native build)
 > 
 >                     before    after   delta
 > cc1                3775717  3777259    1542
 > 
 > Appended to this message is a diff of the dissassembly of alias.o.
 > It looks like difficulty optimizing memset, but I could be wrong.
 > zw

Thanks very much for the analysis.  Chalk one up for glibc I
guess. :-/

I conclude two things, first there doesn't appear to be enough of a
difference to warrant rejecting the patch.  (Do you agree?)

Second, this should be fuel for someone to look at why we don't do
quite as well as glibc.  I think Jan's done some work in that area,
perhaps he could take a look?  (I'm certainly not qualified.)

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu