This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 6/6] Compile sched_getaffinity.c with -fno-builtin-memset
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 14 Aug 2015 09:06:13 -0700
- Subject: Re: [PATCH 6/6] Compile sched_getaffinity.c with -fno-builtin-memset
- Authentication-results: sourceware.org; auth=none
- References: <20150814121907 dot GF28610 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1508141519370 dot 16651 at digraph dot polyomino dot org dot uk> <CAMe9rOrzffv07T31oDX9oVcTpxJ=_kiFNgqcKdgoYbCzvRnEuw at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1508141534210 dot 16651 at digraph dot polyomino dot org dot uk> <CAMe9rOo_qfVjN3Wfj9FpPTD_p+EQ-iFDeVA6hJiBYzex93ijOg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1508141558330 dot 16651 at digraph dot polyomino dot org dot uk>
On Fri, Aug 14, 2015 at 9:02 AM, Joseph Myers <email@example.com> wrote:
> On Fri, 14 Aug 2015, H.J. Lu wrote:
>> > point to the GOT as it would for a call through the PLT. I don't know
>> > whether this gets optimized for built-in function calls using
>> > libc_hidden_builtin_proto, but if it doesn't, that seems like a missed
>> > optimization that should be addressed in the compiler not in glibc.
>> It is hard to say it is a GCC issue when we are kind of doing this behind
>> the back of GCC unless there is a way to tell GCC that the libcall of
>> a builtin function is hidden.
> We're declaring (essentially, though a load of macros):
> extern __typeof (memset) memset __asm__ ("__GI_memset") __attribute__ ((visibility ("hidden")));
> GCC is using the __asm__ information to compile calls to __builtin_memset
> to use the assembler name __GI_memset - that is, in that regard our
> declaration is being taken as applying to the libcall. If it's not also
> using the visibility information to know that those are calls within the
> library and don't need to set up %ebx, that's a clear inconsistency; all
> pieces of information from an explicit declaration of a built-in function
> should be treated the same unless there is a clear reason not to do so.
Should I open a GCC bug?