Last call for bikeshedding on attribute sym/exalias/reverse_alias

Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Alexandre Oliva]

Since 2020 I've been trying to introduce an attribute that operates a
bit like alias, but instead of defining a declaration as an alias to
another defined declaration, it merely exposes the present declaration
with an alternate mnemonic symbol name, so that it can be further
aliased, imported or referenced elsewhere with an invariant name, rather
than with a mangled name.  E.g.:

// C++
namespace foo {
  int __attribute__ ((__???__ ("FOOVAR")))
  var = 42; // FOOVAR is an asm alias to the mangled name for foo::var
}

--  Ada
package Foo is
  Var : Integer;
  pragma Import (CPP, FooVar, "FOOVAR");
  --  use the mnemonic alias rather than the mangled name.


The implementation also handles C++ cdtors, modifying the mnemonic alias
of each clone so that they don't clash, and typeinfo objects generated
for classes when the attribute is associated with a class.


There don't seem to be objections to the feature per se, but discussions
about it have invariably got stuck in debating the attribute name.

https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551614.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624560.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624977.html


The customer report that motivated this development didn't require its
full generality, and asm("symbol") satisfies it.  But I've implemented
the feature, I find it useful, others seem to have liked it, and so I'd
like it to find its way into GCC.  However, I'm advised to not spend
much more time on it.

So, instead of updating the patch for every suggested attribute name, my
last-attempt plan is to try to reach consensus on the attribute name,
and then adjust the patch and submit it one more time.  If that doesn't
succeed, I'll leave it for anyone else to take it from there.

Attribute sym, named after symver, is the one in the latest version of
the patch.  mnemonic_alias, convenience_alias and asm_alias are other
possibilities that comes to mind.  The 2020-August thread has many more.

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Dave Blanchard]

On Fri, 08 Sep 2023 02:25:38 -0300
Alexandre Oliva via Gcc <gcc@gcc.gnu.org> wrote:

> Attribute sym, named after symver, is the one in the latest version of
> the patch.  mnemonic_alias, convenience_alias and asm_alias are other
> possibilities that comes to mind.  The 2020-August thread has many more.

Sounds like a useful feature. Since it specifically deals with C++ name mangling, how about 'demangle'?

C++ is an abomination and name mangling is a perfect example of the brain damage surrounding this abortion of a language, but I digress...

Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Fri, 8 Sept 2023, 06:58 Dave Blanchard, <dave@killthe.net> wrote:

> On Fri, 08 Sep 2023 02:25:38 -0300
> Alexandre Oliva via Gcc <gcc@gcc.gnu.org> wrote:
>
> > Attribute sym, named after symver, is the one in the latest version of
> > the patch.  mnemonic_alias, convenience_alias and asm_alias are other
> > possibilities that comes to mind.  The 2020-August thread has many more.
>
> Sounds like a useful feature. Since it specifically deals with C++ name
> mangling, how about 'demangle'?
>

It doesn't demangle though, it provides an alternative mangled name.



> C++ is an abomination and name mangling is a perfect example of the brain
> damage surrounding this abortion of a language, but I digress...
>

Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 2979 bytes --]

On Fri, 8 Sept 2023, 06:26 Alexandre Oliva via Gcc, <gcc@gcc.gnu.org> wrote:

> Since 2020 I've been trying to introduce an attribute that operates a
> bit like alias, but instead of defining a declaration as an alias to
> another defined declaration, it merely exposes the present declaration
> with an alternate mnemonic symbol name, so that it can be further
> aliased, imported or referenced elsewhere with an invariant name, rather
> than with a mangled name.  E.g.:
>
> // C++
> namespace foo {
>   int __attribute__ ((__???__ ("FOOVAR")))
>   var = 42; // FOOVAR is an asm alias to the mangled name for foo::var
> }
>
> --  Ada
> package Foo is
>   Var : Integer;
>   pragma Import (CPP, FooVar, "FOOVAR");
>   --  use the mnemonic alias rather than the mangled name.
>
>
> The implementation also handles C++ cdtors, modifying the mnemonic alias
> of each clone so that they don't clash, and typeinfo objects generated
> for classes when the attribute is associated with a class.
>

Very cool, we have immediate uses for this in libstdc++.

Personally I think calling it some form of "alias" focuses on the
implementation details of how its done behind the scenes, not what its
practical effects are. On the other hand, it would relate it to the
existing alias attribute which is related.

I think "symname" or "symalias" would be better than just "sym".

Have you contacted anybody in the llvm community to see if they would
implement it, or maybe already have something similar by another name?




>
> There don't seem to be objections to the feature per se, but discussions
> about it have invariably got stuck in debating the attribute name.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551614.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624560.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624977.html
>
>
> The customer report that motivated this development didn't require its
> full generality, and asm("symbol") satisfies it.  But I've implemented
> the feature, I find it useful, others seem to have liked it, and so I'd
> like it to find its way into GCC.  However, I'm advised to not spend
> much more time on it.
>
> So, instead of updating the patch for every suggested attribute name, my
> last-attempt plan is to try to reach consensus on the attribute name,
> and then adjust the patch and submit it one more time.  If that doesn't
> succeed, I'll leave it for anyone else to take it from there.
>
> Attribute sym, named after symver, is the one in the latest version of
> the patch.  mnemonic_alias, convenience_alias and asm_alias are other
> possibilities that comes to mind.  The 2020-August thread has many more.
>
> --
> Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
>    Free Software Activist                   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
>

Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Roy Jacobson]

[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]

There's a related [[preferred_name]] attribute in Clang but it's not a
success story. If you come up with something more usable I think we'll be
happy to implement it as well :)

https://clang.llvm.org/docs/AttributeReference.html#preferred-name


On Fri, 8 Sept 2023, 11:34 Jonathan Wakely via Gcc, <gcc@gcc.gnu.org> wrote:

> On Fri, 8 Sept 2023, 06:26 Alexandre Oliva via Gcc, <gcc@gcc.gnu.org>
> wrote:
>
> > Since 2020 I've been trying to introduce an attribute that operates a
> > bit like alias, but instead of defining a declaration as an alias to
> > another defined declaration, it merely exposes the present declaration
> > with an alternate mnemonic symbol name, so that it can be further
> > aliased, imported or referenced elsewhere with an invariant name, rather
> > than with a mangled name.  E.g.:
> >
> > // C++
> > namespace foo {
> >   int __attribute__ ((__???__ ("FOOVAR")))
> >   var = 42; // FOOVAR is an asm alias to the mangled name for foo::var
> > }
> >
> > --  Ada
> > package Foo is
> >   Var : Integer;
> >   pragma Import (CPP, FooVar, "FOOVAR");
> >   --  use the mnemonic alias rather than the mangled name.
> >
> >
> > The implementation also handles C++ cdtors, modifying the mnemonic alias
> > of each clone so that they don't clash, and typeinfo objects generated
> > for classes when the attribute is associated with a class.
> >
>
> Very cool, we have immediate uses for this in libstdc++.
>
> Personally I think calling it some form of "alias" focuses on the
> implementation details of how its done behind the scenes, not what its
> practical effects are. On the other hand, it would relate it to the
> existing alias attribute which is related.
>
> I think "symname" or "symalias" would be better than just "sym".
>
> Have you contacted anybody in the llvm community to see if they would
> implement it, or maybe already have something similar by another name?
>
>
>
>
> >
> > There don't seem to be objections to the feature per se, but discussions
> > about it have invariably got stuck in debating the attribute name.
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551614.html
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624560.html
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624977.html
> >
> >
> > The customer report that motivated this development didn't require its
> > full generality, and asm("symbol") satisfies it.  But I've implemented
> > the feature, I find it useful, others seem to have liked it, and so I'd
> > like it to find its way into GCC.  However, I'm advised to not spend
> > much more time on it.
> >
> > So, instead of updating the patch for every suggested attribute name, my
> > last-attempt plan is to try to reach consensus on the attribute name,
> > and then adjust the patch and submit it one more time.  If that doesn't
> > succeed, I'll leave it for anyone else to take it from there.
> >
> > Attribute sym, named after symver, is the one in the latest version of
> > the patch.  mnemonic_alias, convenience_alias and asm_alias are other
> > possibilities that comes to mind.  The 2020-August thread has many more.
> >
> > --
> > Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
> >    Free Software Activist                   GNU Toolchain Engineer
> > More tolerance and less prejudice are key for inclusion and diversity
> > Excluding neuro-others for not behaving ""normal"" is *not* inclusive
> >
>

Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias

[Alexandre Oliva]

On Sep  8, 2023, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> I think "symname" or "symalias" would be better than just "sym".

Thanks, I like symalias.

Does any object to it?

> Have you contacted anybody in the llvm community to see if they would
> implement it, or maybe already have something similar by another name?

I haven't, but there's nothing like it there.

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive