This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: GCC 4.8 and -ftree-loop-distribute-patterns.
- From: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Fri, 05 Apr 2013 19:16:12 -0300
- Subject: Re: GCC 4.8 and -ftree-loop-distribute-patterns.
- References: <511D4F82 dot 3080604 at redhat dot com> <515F4565 dot 6030301 at linux dot vnet dot ibm dot com> <20130405215301 dot GG20323 at brightrain dot aerifal dot cx>
On 04/05/2013 06:53 PM, Rich Felker wrote:
> On Fri, Apr 05, 2013 at 06:43:01PM -0300, Adhemerval Zanella wrote:
>> On 02/14/2013 06:56 PM, Carlos O'Donell wrote:
>>> Team,
>>>
>>> In GCC 4.8 we now have -ftree-loop-distribute-patterns enabled at -O3.
>>> This optimization is unsafe in glibc. The optimization detects code
>>> patterns that match specific runtime functions and converts the code
>>> into a function call e.g. Call to memset for a loop that iterates over
>>> memory setting a value.
>>>
>>> We're already seeing the optimization breaking Fedora rawhide builds.
>>>
>>> I'm thinking we could unconditionally disable this optimization for
>>> elf/ and string/ subdirs?
>>>
>>> Where else are we going to need to disable this optimization?
>>>
>>> Do we need to detect GCC 4.8 and then add -fno-tree-loop-distribute-patterns?
>>>
>>> Cheers,
>>> Carlos.
>>>
>> I have noted this option also creating memmove calls when building some mpn
>> objects and memset call on wcsmbs files when building for PowerPC. I'm using
>> this patch to avoid such calls:
> When building "part of the implementation" such a libc, -ffreestanding
> should be passed to the compiler to let it know it cannot assume the
> existence of an underlying hosted implementation. This should disable
> all such optimizations. If it doesn't, it's a bug in the compiler.
>
> Rich
At first though I don't think it is feasible: -ffreestanding implies on -fno-builtin
and GLIBC only disables it for specific objects. I agree thought that creating
memmove/memset calls with -ffreestanding is still an issue (which is the case).