Re: GCC 4.8 and -ftree-loop-distribute-patterns.

[Roland McGrath <roland at hack dot frob dot com>]

> We're already seeing the optimization breaking Fedora rawhide builds.

Please cite all the particular places where it generated calls that are
problematic.

> I'm thinking we could unconditionally disable this optimization for
> elf/ and string/ subdirs?

Why elf?  The rtld-*.os builds are driven by the subdirectory makefiles,
so settings in string/Makefile are sufficient for rtld-mem* et al.

> Where else are we going to need to disable this optimization?

I think the ideal would be that we disable this only in the cases where it
causes recursion (e.g. generic memset.c compiled to call memset).  In
general, it's a perfectly fine thing to be doing.  It would be a shame 
to suppress any optimization that might be beneficial.

Perhaps all of our string code is sufficiently carefully-tuned that nothing
in string/ would benefit.  But I'd be much happier if we keep it closely
isolated.

> Do we need to detect GCC 4.8 and then add -fno-tree-loop-distribute-patterns?

It would be a configure check to detect a compiler that groks
-fno-tree-loop-distribute-patterns, not a version check.  Perhaps that's
what you meant.

I think what we actually want is to confine this only to the individual
functions where it's of potential concern.  That is, mark those with
__attribute__ ((optimize ("no-tree-loop-distribute-patterns"))).  (We
should then use a configure check that tries this rather than the
command-line option.  There are no GCC versions that have this optimization
option but not the "optimize" attribute.)  Off hand I think that the C
implementations of string functions (e.g. string/memset.c and any sysdeps
implementations that are in C) and the simple_* functions in string/test-*.c
are the only places we need it.


Thanks,
Roland