Re: [PATCH v3] Introduce attribute reverse_alias

2023-07-18 Thread Richard Biener via Gcc-patches
On Tue, Jul 18, 2023 at 6:29 AM Alexandre Oliva via Gcc-patches
 wrote:
>
> Hello, Nathan,
>
> On Jul 15, 2023, Nathan Sidwell  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 ( == ); // ok
>
> with:
>
> int __attribute__ ((reverse_alias ("bar"))) foo();
>
> static_assert ( == ); // error, bar is not a C++ symbol
>
> int __attribute__ ((alias ("bar"))) baz(); // ok
>
> static_assert ( == ); // 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 hackerhttps://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 


Re: [PATCH v3] Introduce attribute reverse_alias

2023-07-17 Thread Alexandre Oliva via Gcc-patches
Hello, Nathan,

On Jul 15, 2023, Nathan Sidwell  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 ( == ); // ok

with:

int __attribute__ ((reverse_alias ("bar"))) foo();

static_assert ( == ); // error, bar is not a C++ symbol

int __attribute__ ((alias ("bar"))) baz(); // ok

static_assert ( == ); // 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.

> 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 hackerhttps://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 


Re: [PATCH v3] Introduce attribute reverse_alias

2023-07-15 Thread Nathan Sidwell via Gcc-patches
Not commenting on the semantics, but the name seems unfortunate (hello 
bikeshed).  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 doesn;t seem to mention how reverse alias differs 
from 'alias'.  Why would 'alias' not DTRT?


Is is emitting a an additiona symbol -- ie, something like 'altname'.  Or is it 
something else? Is that symbol known in the current TU, or other TUs?


nathan



On 7/14/23 21:08, Alexandre Oliva wrote:


This patch introduces an attribute to add extra aliases to a symbol
when its definition is output.  The main goal is to ease interfacing
C++ with Ada, as C++ mangled names have to be named, and in some cases
(e.g. when using stdint.h typedefs in function arguments) the symbol
names may vary across platforms.

The attribute is usable in C and C++, presumably in all C-family
languages.  It can be attached to global variables and functions.  In
C++, it can also be attached to namespace-scoped variables and
functions, static data members, member functions, explicit
instantiations and specializations of template functions, members and
classes.

When applied to constructors or destructor, additional reverse_aliases
with _Base and _Del suffixes are defined for variants other than
complete-object ones.  This changes the assumption that clones always
carry the same attributes as their abstract declarations, so there is
now a function to adjust them.

C++ also had a bug in which attributes from local extern declarations
failed to be propagated to a preexisting corresponding
namespace-scoped decl.  I've fixed that, and adjusted acc tests that
distinguished between C and C++ in this regard.

Applying the attribute to class types is only valid in C++, and the
effect is to attach the alias to the RTTI object associated with the
class type.

Regstrapped on x86_64-linux-gnu.  Ok to install?

This is refreshed and renamed from earlier versions that named the
attribute 'exalias', and that AFAICT got stuck in name bikeshedding.
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551614.html


for  gcc/ChangeLog

* attribs.cc: Include cgraph.h.
(decl_attributes): Allow late introduction of reverse_alias in
types.
(create_reverse_alias_decl, create_reverse_alias_decls): New.
* attribs.h: Declare them.
(FOR_EACH_REVERSE_ALIAS): New macro.
* cgraph.cc (cgraph_node::create): Create reverse_alias decls.
* varpool.cc (varpool_node::get_create): Create reverse_alias
decls.
* cgraph.h (symtab_node::remap_reverse_alias_target): New.
* symtab.cc (symtab_node::remap_reverse_alias_target):
Define.
* cgraphunit.cc (cgraph_node::analyze): Create alias_target
node if needed.
(analyze_functions): Fixup visibility of implicit alias only
after its node is analyzed.
* doc/extend.texi (reverse_alias): Document for variables,
functions and types.

for  gcc/ada/ChangeLog

* doc/gnat_rm/interfacing_to_other_languages.rst: Mention
attribute reverse_alias to give RTTI symbols mnemonic names.
* doc/gnat_ugn/the_gnat_compilation_model.rst: Mention
attribute reverse_alias.  Fix incorrect ref to C1 ctor variant.

for  gcc/c-family/ChangeLog

* c-ada-spec.cc (pp_asm_name): Use first reverse_alias if
available.
* c-attribs.cc (handle_reverse_alias_attribute): New.
(c_common_attribute_table): Add reverse_alias.
(handle_copy_attribute): Do not copy reverse_alias.

for  gcc/c/ChangeLog

* c-decl.cc (duplicate_decls): Remap reverse_alias target.

for  gcc/cp/ChangeLog

* class.cc (adjust_clone_attributes): New.
(copy_fndecl_with_name, build_clone): Call it.
* cp-tree.h (adjust_clone_attributes): Declare.
(update_reverse_alias_interface): Declare.
(update_tinfo_reverse_alias): Declare.
* decl.cc (duplicate_decls): Remap reverse_alias target.
Adjust clone attributes.
(grokfndecl): Tentatively create reverse_alias decls after
adding attributes in e.g. a template member function explicit
instantiation.
* decl2.cc (cplus_decl_attributes): Update tinfo
reverse_alias.
(copy_interface, update_reverse_alias_interface): New.
(determine_visibility): Update reverse_alias interface.
(tentative_decl_linkage, import_export_decl): Likewise.
* name-lookup.cc: Include target.h and cgraph.h.
(push_local_extern_decl_alias): Merge attributes with
namespace-scoped decl, and drop duplicate reverse_alias.
* optimize.cc (maybe_clone_body): Re-adjust attributes after
cloning them.  Update reverse_alias interface.
* rtti.cc: Include attribs.h and cgraph.h.
(get_tinfo_decl): Copy reverse_alias attributes from type to
tinfo decl.  Create