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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 06 Apr 2013 10:01:44 -0400
- 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> <20130405223023 dot 0DEB62C096 at topped-with-meat dot com> <51601F98 dot 5000606 at linux dot vnet dot ibm dot com>
On 04/06/2013 09:14 AM, Adhemerval Zanella wrote:
> On 04/05/2013 07:30 PM, Roland McGrath wrote:
>>> I have noted this option also creating memmove calls when building some mpn
>>> objects and memset call on wcsmbs files when building for PowerPC.
>> Why are these a problem? If the compiler decided it was optimal to use
>> those calls, we should let it. There's only a problem when it's using a
>> function to define itself.
>>
>>
>> Thanks,
>> Roland
>>
> It is a problem now because since some mpn and wcsmbs implementation
> does not contain the string definition the compiler will create a reference
> to memset/memmove instead of __GI_memset/__GI_memmove, ending in a PLT call
> for these symbols in libc.so.
Interesting.
I hadn't even considered this case, or that it might be a problem.
> But I believe a simpler solution instead of add '-fno-tree-loop-distribute-patterns'
> on Makefile or function attribute is to just add an '#include <string.h>'
> on such sources.
Right, so adding #include <string.h> will add the hidden prototypes
for the string and memory routines, which fixes your localplt issue.
> The following patch fixed the localplt issue I was observing on PowerPC64:
The patch, like my Fedora patch, is incomplete. We need to detect
the compiler feature, set a feature macro, and then conditionally
carry out whatever is required to allow glibc to compile with the
feature enabled.
In your case it would be to include string.h.
I'm up to my ears in other work, so I would be more than happy to
give up the glory that goes along with fixing this :-)
Cheers,
Carlos.