This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: Add ifunc attribute
On Fri, Jun 26, 2009 at 1:56 PM, Richard
> On Fri, Jun 26, 2009 at 10:21 PM, H.J. Lu<firstname.lastname@example.org> wrote:
>> On Fri, Jun 26, 2009 at 12:13 PM, Roland McGrath<email@example.com> wrote:
>>>> > Why wouldn't Roland's proposal work with C++?
>>>> I am not sure it will work for C++, especially for member functions.
>>> That isn't actually an answer to the question, you know.
>>> Why wouldn't it?
>>> I had not thought about name mangling before, but I don't see a special
>>> problem if you treat it in what seems to me the obvious way. ?With:
>>> __typeof (foo) *foo_finder (void) __attribute__ ((ifunc ("foo")));
>>> The mangling of "foo" goes with the type of "foo". ?Either you could say
>>> that a foo prototype must be in scope, and it literally uses the type of
>>> "foo", but that is probably a confusing definition given overloading.
>>> With C++ overloading you can't actually use __typeof (foo), of course.
>>> void foo (int);
>>> void foo (float);
>>> void (*foo_int_finder (void)) (int) __attribute__ ((ifunc ("foo")));
>>> void (*foo_float_finder (void)) (float) __attribute__ ((ifunc ("foo")));
>>> So what you say is that the function type to which *_finder's return type
>>> is a pointer, is the type of "foo" for name-mangling purposes. ?Same with
>>> s/foo/someclass::foo/ for a member function.
>> I have some C/C++ examples with valid and invalid cases:
>> How will you get the same functionality with other
> I use a proper asm("...") with a mangled name. ?I don't see what should
> be special with C++ about ifunc if you do not want to play games
> with inheriting the attribute for overloads.
You can try to write a C++ program to see how easy/hard to do.