This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]