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 > > >
