Re: [PATCH v3] Introduce attribute reverse_alias

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Jul 18, 2023 at 6:29 AM Alexandre Oliva via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Hello, Nathan,
>
> On Jul 15, 2023, Nathan Sidwell <nathan@acm.org> wrote:
>
> > Not commenting on the semantics, but the name seems unfortunate (hello
> > bikeshed).
>
> Yeah, it's a bit challenging to express the concept, when the notion of
> "alias" is kind of symmetric between decl and target, but the
> previously-implemented extension attaches it to decl rather than to
> target.  I tried "extra alias" before, but that didn't fly either.
>
> Maybe I should give up and just recommend the use of asm ("name")
> instead of allowing alternative names (AKA aliases, in the dictionary
> sense; oh, the irony) to be introduced for a decl?  Maybe that would be
> simpler and enough to sidestep the problem of varying mangled names when
> trying to import into Ada (or defining C++ aliases for) C++ symbols that
> use standard types in signatures that are not fundamental types, such as
> size_t.  That they mangle differently depending on what size_t is
> typedef'ed to makes for some undesirable inconvenience, which this
> attribute attempts to alleviate.
>
> > The documentation starts with 'attribute causes @var{name}
> > to be emitted as an alias to the definition'.  So not emitting a
> > 'reverse alias', whatever that might be.
>
> It's reverse in that it doesn't alias another declaration, as in the
> preexisting meaning of the alias attribute, it adds an alias for the
> present declaration.
>
> > It doesn;t seem to mention how reverse alias differs from 'alias'.
> > Why would 'alias' not DTRT?
>
> contrast:
>
> int foo();
> int __attribute__ ((alias ("foo"))) bar();
>
> static_assert (&foo == &bar); // ok
>
> with:
>
> int __attribute__ ((reverse_alias ("bar"))) foo();
>
> static_assert (&foo == &bar); // error, bar is not a C++ symbol
>
> int __attribute__ ((alias ("bar"))) baz(); // ok
>
> static_assert (&foo == &baz); // ok
>
> asm (".quad bar"); // ok, even in other TUs
> asm (".quad foo"); // not necessarily ok, foo's symbol may be mangled
> asm (".quad baz"); // not necessarily ok, baz's symbol may be mangled
>
> > Is is emitting a an additiona symbol -- ie, something like 'altname'.
>
> Yup.  Is there precedent for this attribute name elsewhere?  I think it
> could work.

I think the __symver__ attribute does something similar already so
maybe use __attribute__((__sym__("foo")))?

Richard.

> > Is that symbol known in the current TU, or other TUs?
>
> Only in the assembly/linker name space, not in any C++ namespace.
>
> --
> Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
>    Free Software Activist                       GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about <https://stallmansupport.org>