PATCH: Add ifunc attribute

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

H.J. Lu-30
On Fri, Jun 26, 2009 at 9:12 AM, Richard
Guenther<[hidden email]> wrote:

> On Fri, Jun 26, 2009 at 6:03 PM, H.J. Lu<[hidden email]> wrote:
>> On Fri, Jun 26, 2009 at 8:47 AM, Paolo Bonzini<[hidden email]> wrote:
>>>> How do you propose to support C++?
>>>
>>> Why wouldn't Roland's proposal work with C++?
>>>
>>
>> I am not sure it will work for C++, especially for
>> member functions.
>
> asm() with a properly mangled name should work.
>
> Richard.

Here is a C++ example.  Option 3 works nicely.

---
class ifunc
{
private:
  int foo1 (int);
  int foo2 (float);

public:
  int foo (int);
  int foo (float);
  int bar (int);
  int bar (float);
};

int
__attribute__ ((ifunc))
ifunc::foo (int)
{
  return &ifunc::foo1;
}

int
__attribute__ ((ifunc))
ifunc::foo (float)
{
  return &ifunc::foo2;
}

int
ifunc::bar (int x)
{
  return foo (x);
}

int
ifunc::bar (float x)
{
  return foo (x);
}
---

How do you make it to work with other options?

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

Richard Biener
On Fri, Jun 26, 2009 at 6:16 PM, H.J. Lu<[hidden email]> wrote:

> On Fri, Jun 26, 2009 at 9:12 AM, Richard
> Guenther<[hidden email]> wrote:
>> On Fri, Jun 26, 2009 at 6:03 PM, H.J. Lu<[hidden email]> wrote:
>>> On Fri, Jun 26, 2009 at 8:47 AM, Paolo Bonzini<[hidden email]> wrote:
>>>>> How do you propose to support C++?
>>>>
>>>> Why wouldn't Roland's proposal work with C++?
>>>>
>>>
>>> I am not sure it will work for C++, especially for
>>> member functions.
>>
>> asm() with a properly mangled name should work.
>>
>> Richard.
>
> Here is a C++ example.  Option 3 works nicely.

Does it work with virtual functions?

> ---
> class ifunc
> {
> private:
>  int foo1 (int);
>  int foo2 (float);
>
> public:
>  int foo (int);
>  int foo (float);
>  int bar (int);
>  int bar (float);
> };
>
> int
> __attribute__ ((ifunc))
> ifunc::foo (int)
> {
>  return &ifunc::foo1;
> }
>
> int
> __attribute__ ((ifunc))
> ifunc::foo (float)
> {
>  return &ifunc::foo2;
> }
>
> int
> ifunc::bar (int x)
> {
>  return foo (x);
> }
>
> int
> ifunc::bar (float x)
> {
>  return foo (x);
> }
> ---
>
> How do you make it to work with other options?
>
> --
> H.J.
>
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

H.J. Lu-30
On Fri, Jun 26, 2009 at 9:26 AM, Richard
Guenther<[hidden email]> wrote:

> On Fri, Jun 26, 2009 at 6:16 PM, H.J. Lu<[hidden email]> wrote:
>> On Fri, Jun 26, 2009 at 9:12 AM, Richard
>> Guenther<[hidden email]> wrote:
>>> On Fri, Jun 26, 2009 at 6:03 PM, H.J. Lu<[hidden email]> wrote:
>>>> On Fri, Jun 26, 2009 at 8:47 AM, Paolo Bonzini<[hidden email]> wrote:
>>>>>> How do you propose to support C++?
>>>>>
>>>>> Why wouldn't Roland's proposal work with C++?
>>>>>
>>>>
>>>> I am not sure it will work for C++, especially for
>>>> member functions.
>>>
>>> asm() with a properly mangled name should work.
>>>
>>> Richard.
>>
>> Here is a C++ example.  Option 3 works nicely.
>
> Does it work with virtual functions?

The ifunc attribute should only affect the function
definition. The ifunc attribute shouldn't be inherited.


H.J.
---

>> ---
>> class ifunc
>> {
>> private:
>>  int foo1 (int);
>>  int foo2 (float);
>>
>> public:
>>  int foo (int);
>>  int foo (float);
>>  int bar (int);
>>  int bar (float);
>> };
>>
>> int
>> __attribute__ ((ifunc))
>> ifunc::foo (int)
>> {
>>  return &ifunc::foo1;
>> }
>>
>> int
>> __attribute__ ((ifunc))
>> ifunc::foo (float)
>> {
>>  return &ifunc::foo2;
>> }
>>
>> int
>> ifunc::bar (int x)
>> {
>>  return foo (x);
>> }
>>
>> int
>> ifunc::bar (float x)
>> {
>>  return foo (x);
>> }
>> ---
>>
>> How do you make it to work with other options?
>>
>> --
>> H.J.
>>
>



--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

Roland McGrath
In reply to this post by H.J. Lu-30
> > 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.  


Thanks,
Roland

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

H.J. Lu-30
On Fri, Jun 26, 2009 at 12:13 PM, Roland McGrath<[hidden email]> 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:

http://gcc.gnu.org/bugzilla/attachment.cgi?id=18076

How will you get the same functionality with other
options?

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

H.J. Lu-30
On Fri, Jun 26, 2009 at 1:21 PM, H.J. Lu<[hidden email]> wrote:

> On Fri, Jun 26, 2009 at 12:13 PM, Roland McGrath<[hidden email]> 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:
>
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=18076
>
> How will you get the same functionality with other
> options?
>

I upload a C++ program with ifunc attribute to:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528

along with its static Linux/ia32 binary. How do you
write a similar prog.C in C++ with your ifunc attribute
proposal?

Thanks.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

Richard Biener
In reply to this post by H.J. Lu-30
On Fri, Jun 26, 2009 at 10:21 PM, H.J. Lu<[hidden email]> wrote:

> On Fri, Jun 26, 2009 at 12:13 PM, Roland McGrath<[hidden email]> 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:
>
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=18076
>
> How will you get the same functionality with other
> options?

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.

Richard.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

H.J. Lu-30
On Fri, Jun 26, 2009 at 1:56 PM, Richard
Guenther<[hidden email]> wrote:

> On Fri, Jun 26, 2009 at 10:21 PM, H.J. Lu<[hidden email]> wrote:
>> On Fri, Jun 26, 2009 at 12:13 PM, Roland McGrath<[hidden email]> 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:
>>
>> http://gcc.gnu.org/bugzilla/attachment.cgi?id=18076
>>
>> How will you get the same functionality with other
>> options?
>
> 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.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

Roland McGrath
In reply to this post by H.J. Lu-30
> along with its static Linux/ia32 binary. How do you
> write a similar prog.C in C++ with your ifunc attribute
> proposal?

The only difference is using (Class::*) vs (*) in the return type of the
foo_finder functions.  Did I missing something obvious?


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

H.J. Lu-30
On Fri, Jun 26, 2009 at 3:10 PM, Roland McGrath<[hidden email]> wrote:
>> along with its static Linux/ia32 binary. How do you
>> write a similar prog.C in C++ with your ifunc attribute
>> proposal?
>
> The only difference is using (Class::*) vs (*) in the return type of the
> foo_finder functions.  Did I missing something obvious?
>
>

The one problem with using asm () for C++ name mangling is
it isn't easy to figure out what the assembly symbol one is.
If you change the function prototype, you have to figure
out the assembly name again.

with

class Foo
{
private:
  virtual void foo1 ()
    {
      printf ("I am %s\n", __PRETTY_FUNCTION__);
    }
public:
  virtual void  __attribute__ ((ifunc)) foo ()
    {
      return &Foo::foo1;
    }
};

there is no such problem.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

Roland McGrath
> On Fri, Jun 26, 2009 at 3:10 PM, Roland McGrath<[hidden email]> wrote:
> >> along with its static Linux/ia32 binary. How do you
> >> write a similar prog.C in C++ with your ifunc attribute
> >> proposal?
> >
> > The only difference is using (Class::*) vs (*) in the return type of the
> > foo_finder functions.  Did I missing something obvious?
>
> The one problem with using asm () for C++ name mangling is
> it isn't easy to figure out what the assembly symbol one is.
> If you change the function prototype, you have to figure
> out the assembly name again.

My suggestion did not involve asm.  I do not think it would be wise to have
a feature where manual name-mangling is the only method available for C++.

> class Foo
> {
> private:
>   virtual void foo1 ()
>     {
>       printf ("I am %s\n", __PRETTY_FUNCTION__);
>     }
> public:
>   virtual void  __attribute__ ((ifunc)) foo ()
>     {
>       return &Foo::foo1;
>     }
> };
>
> there is no such problem.

In what I suggested this would be:

    class Foo
    {
    private:
      virtual void foo1 ()
      {
        printf ("I am %s\n", __PRETTY_FUNCTION__);
      }
    public:
      virtual void foo ();
    };
    static void __attribute__ ((ifunc ("Foo::foo")))
    (Foo::*foo_finder ()) ()
    {
      return &Foo::foo1;
    }

Note that foo_finder is static, so "foo_finder" would be a local symbol (or
could in theory be renamed arbitrarily by the compiler, etc.), but this has
no bearing on the "Foo::foo" mangled symbol (which is the STT_IFUNC).  Its
visibility, binding, etc. are determined by the void Foo::foo ()
declaration in scope.

It could also be written:

    class Foo
    {
    private:
      virtual void foo1 ()
      {
        printf ("I am %s\n", __PRETTY_FUNCTION__);
      }
      static void __attribute__ ((ifunc ("foo")))
      (Foo::*foo_finder ()) ()
      {
        return &Foo::foo1;
      }
    public:
      virtual void foo ();
    };

(Though perhaps declaration order could require that "virtual void foo ();"
be declared before the use of __attribute__ ((ifunc "foo")).  I don't know
about that wrinkle of what makes most sense for C++.  In a C context, I
would expect __attribute__ ((ifunc ("foo"))) to require that a prototype for
foo already be in scope.)

Note this use lets unadorned "foo" make sense in the attribute, for
the actual STT_IFUNC symbol being mangled "void Foo::foo ()".
OTOH, (without using visibility features et al) Foo::foo_finder is
produced as a global symbol when that is not really required or desired.


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

H.J. Lu-30
On Sat, Jun 27, 2009 at 7:06 PM, Roland McGrath<[hidden email]> wrote:

>> On Fri, Jun 26, 2009 at 3:10 PM, Roland McGrath<[hidden email]> wrote:
>> >> along with its static Linux/ia32 binary. How do you
>> >> write a similar prog.C in C++ with your ifunc attribute
>> >> proposal?
>> >
>> > The only difference is using (Class::*) vs (*) in the return type of the
>> > foo_finder functions.  Did I missing something obvious?
>>
>> The one problem with using asm () for C++ name mangling is
>> it isn't easy to figure out what the assembly symbol one is.
>> If you change the function prototype, you have to figure
>> out the assembly name again.
>
> My suggestion did not involve asm.  I do not think it would be wise to have
> a feature where manual name-mangling is the only method available for C++.
>
>> class Foo
>> {
>> private:
>>   virtual void foo1 ()
>>     {
>>       printf ("I am %s\n", __PRETTY_FUNCTION__);
>>     }
>> public:
>>   virtual void  __attribute__ ((ifunc)) foo ()
>>     {
>>       return &Foo::foo1;
>>     }
>> };
>>
>> there is no such problem.
>
> In what I suggested this would be:
>
>    class Foo
>    {
>    private:
>      virtual void foo1 ()
>      {
>        printf ("I am %s\n", __PRETTY_FUNCTION__);
>      }
>    public:
>      virtual void foo ();
>    };
>    static void __attribute__ ((ifunc ("Foo::foo")))
>    (Foo::*foo_finder ()) ()
>    {
>      return &Foo::foo1;
>    }
>
> Note that foo_finder is static, so "foo_finder" would be a local symbol (or
> could in theory be renamed arbitrarily by the compiler, etc.), but this has

Static member function in C++ has global binding.

> no bearing on the "Foo::foo" mangled symbol (which is the STT_IFUNC).  Its
> visibility, binding, etc. are determined by the void Foo::foo ()
> declaration in scope.

What symbol name should compiler generate for "foo_finder"?
You may have many member functions named "foo" with different
prototypes.

> It could also be written:
>
>    class Foo
>    {
>    private:
>      virtual void foo1 ()
>      {
>        printf ("I am %s\n", __PRETTY_FUNCTION__);
>      }
>      static void __attribute__ ((ifunc ("foo")))
>      (Foo::*foo_finder ()) ()
>      {
>        return &Foo::foo1;
>      }
>    public:
>      virtual void foo ();
>    };
>
> (Though perhaps declaration order could require that "virtual void foo ();"
> be declared before the use of __attribute__ ((ifunc "foo")).  I don't know
> about that wrinkle of what makes most sense for C++.  In a C context, I
> would expect __attribute__ ((ifunc ("foo"))) to require that a prototype for
> foo already be in scope.)

How do you handle

class ifunc
{
private:
  int foo1 (int);
  int foo2 (float);

public:
  int foo (int);
  int foo (float);
  int bar (int);
  int bar (float);
};

int
__attribute__ ((ifunc))
ifunc::foo (int)
{
  return &ifunc::foo1;
}

int
__attribute__ ((ifunc))
ifunc::foo (float)
{
  return &ifunc::foo2;
}

int
ifunc::bar (int x)
{
  return foo (x);
}

int
ifunc::bar (float x)
{
  return foo (x);
}

> Note this use lets unadorned "foo" make sense in the attribute, for
> the actual STT_IFUNC symbol being mangled "void Foo::foo ()".
> OTOH, (without using visibility features et al) Foo::foo_finder is
> produced as a global symbol when that is not really required or desired.
>

I think the 3rd option is the most sensible for C++. I will create
an ifunc branch so that we can compare different approaches.

Thanks.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

Roland McGrath
> > Note that foo_finder is static, so "foo_finder" would be a local symbol (or
> > could in theory be renamed arbitrarily by the compiler, etc.), but this has
>
> Static member function in C++ has global binding.

That was exactly my point about the difference in the second example.  The
first example uses a plain static function for "foo_finder", not any kind
of member function.

> What symbol name should compiler generate for "foo_finder"?

It's irrelevant here.  It can generate whatever symbol name it normally
would as defined without the __attribute__ ((ifunc ("foo"))).

> You may have many member functions named "foo" with different prototypes.

Sure.  So?  Each __attribute__ ((ifunc ("foo"))) definition is separate and
applies to the appropriate mangling of "foo" for the type affected by that
individual definition.  It is immaterial what you might choose to call the
"finder" functions.  I think C++ won't allow you to call several of them
"foo_finder" and rely on overloading, because they'd differ only in return
type.

> How do you handle
>
> class ifunc
> {
> private:
>   int foo1 (int);
>   int foo2 (float);
>
> public:
>   int foo (int);
>   int foo (float);
>   int bar (int);
>   int bar (float);
> };
>
> int
> __attribute__ ((ifunc))
> ifunc::foo (int)
> {
>   return &ifunc::foo1;
> }
>
> int
> __attribute__ ((ifunc))
> ifunc::foo (float)
> {
>   return &ifunc::foo2;
> }
>
> int
> ifunc::bar (int x)
> {
>   return foo (x);
> }
>
> int
> ifunc::bar (float x)
> {
>   return foo (x);
> }

Nothing new here.

    static int (ifunc::*foo1_finder ()) (int) __attribute__ ((ifunc ("foo")))
    {
      return &ifunc::foo1;
    }
    static int (Foo::*foo2_finder ()) (float) __attribute__ ((ifunc ("foo")))
    {
      return &ifunc::foo2;
    }

if inside the class (corresponds to my second example).  Or, corresponding
to my first example, the same outside the class but s/"foo"/"ifunc::foo"/
and then you'd have to address the privateness of foo[12] with a friend
function decl or something (but that is just a normal wrinkle of defining
any normal function could return that pointer).  Simply put, the only
departure from just defining some function you could otherwise define that
returns such pointers, is adding __attribute__ ((ifunc ("foo"))).


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

Richard Biener
On Sun, Jun 28, 2009 at 10:59 PM, Roland McGrath<[hidden email]> wrote:

>> > Note that foo_finder is static, so "foo_finder" would be a local symbol (or
>> > could in theory be renamed arbitrarily by the compiler, etc.), but this has
>>
>> Static member function in C++ has global binding.
>
> That was exactly my point about the difference in the second example.  The
> first example uses a plain static function for "foo_finder", not any kind
> of member function.
>
>> What symbol name should compiler generate for "foo_finder"?
>
> It's irrelevant here.  It can generate whatever symbol name it normally
> would as defined without the __attribute__ ((ifunc ("foo"))).
>
>> You may have many member functions named "foo" with different prototypes.
>
> Sure.  So?  Each __attribute__ ((ifunc ("foo"))) definition is separate and
> applies to the appropriate mangling of "foo" for the type affected by that
> individual definition.  It is immaterial what you might choose to call the
> "finder" functions.  I think C++ won't allow you to call several of them
> "foo_finder" and rely on overloading, because they'd differ only in return
> type.
>
>> How do you handle
>>
>> class ifunc
>> {
>> private:
>>   int foo1 (int);
>>   int foo2 (float);
>>
>> public:
>>   int foo (int);
>>   int foo (float);
>>   int bar (int);
>>   int bar (float);
>> };
>>
>> int
>> __attribute__ ((ifunc))
>> ifunc::foo (int)
>> {
>>   return &ifunc::foo1;
>> }
>>
>> int
>> __attribute__ ((ifunc))
>> ifunc::foo (float)
>> {
>>   return &ifunc::foo2;
>> }
>>
>> int
>> ifunc::bar (int x)
>> {
>>   return foo (x);
>> }
>>
>> int
>> ifunc::bar (float x)
>> {
>>   return foo (x);
>> }
>
> Nothing new here.
>
>    static int (ifunc::*foo1_finder ()) (int) __attribute__ ((ifunc ("foo")))
>    {
>      return &ifunc::foo1;
>    }
>    static int (Foo::*foo2_finder ()) (float) __attribute__ ((ifunc ("foo")))
>    {
>      return &ifunc::foo2;
>    }
>
> if inside the class (corresponds to my second example).  Or, corresponding
> to my first example, the same outside the class but s/"foo"/"ifunc::foo"/
> and then you'd have to address the privateness of foo[12] with a friend
> function decl or something (but that is just a normal wrinkle of defining
> any normal function could return that pointer).  Simply put, the only
> departure from just defining some function you could otherwise define that
> returns such pointers, is adding __attribute__ ((ifunc ("foo"))).

Your proposal requires determining the mangling from the return type
and the ifunc attribute argument.  That's even more weird than HJs
proposal.

If you go down that far, why not do a proper C++ extension like

__ifunc ifunc::foo (int)
{
  return &ifunc::foo1;
}

__ifunc ifunc::foo (float)
{
  return &ifunc::foo2;
}

?

No, I'm not serious.  Keep it simple please, build on existing features.

Thanks,
Richard.
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

Roland McGrath
> Your proposal requires determining the mangling from the return type
> and the ifunc attribute argument.  

That's true.  You could alternatively allow/require a protoyped-name inside
the "" to resolve overloading.

> That's even more weird than HJs proposal.

I have to disagree thoroughly.

> No, I'm not serious.  

Your example is macroably identical to HJ's proposal.
I'm glad to see that you agree it's a laughably insane syntax. ;-)

> Keep it simple please, build on existing features.

What I have proposed for C is the most like existing features such as
alias.  HJ's proposal is the severe departure IMHO.  The natural extension
of the C syntax I proposed to C++ is indeed more bizarre, because, well,
it's C++, so what do you expect?


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: Add ifunc attribute

Richard Biener
On Mon, Jun 29, 2009 at 12:00 AM, Roland McGrath<[hidden email]> wrote:

>> Your proposal requires determining the mangling from the return type
>> and the ifunc attribute argument.
>
> That's true.  You could alternatively allow/require a protoyped-name inside
> the "" to resolve overloading.
>
>> That's even more weird than HJs proposal.
>
> I have to disagree thoroughly.
>
>> No, I'm not serious.
>
> Your example is macroably identical to HJ's proposal.
> I'm glad to see that you agree it's a laughably insane syntax. ;-)
>
>> Keep it simple please, build on existing features.
>
> What I have proposed for C is the most like existing features such as
> alias.  HJ's proposal is the severe departure IMHO.  The natural extension
> of the C syntax I proposed to C++ is indeed more bizarre, because, well,
> it's C++, so what do you expect?

Well, for something that doesn't resort to asm("") for the symbol
name I expect something like your proposal.  I just do not see
the need for this and expect us to put the burden of correct
mangling to the user.  Mangling errors will result in linker errors
for them, which is IMHO good enough for such a low-level feature.

Thanks,
Richard.

>
> Thanks,
> Roland
>
123