From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 96FED3857C5A for ; Fri, 8 Sep 2023 08:33:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 96FED3857C5A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-52a250aa012so2438665a12.3 for ; Fri, 08 Sep 2023 01:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694161981; x=1694766781; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rHjh/tvRUkTZlJLKQ6F4Ss7Ni3lFZQEz8GO6u5HE2EQ=; b=ejOnH0shhH6TVJ/KKp9Ot/CuEfdMMbuIsMIeNInRgpQoNyAQYYrrPlmE5zFxz195Wy f30wWtlgyf7G2ZEvDeB8p8eBAh/XZciT7n8VplbHcZQ8y/BM3qs9lLKoMml9fHdWYEti F7QyRCWfAVjuCXMdB71COdPpcMORF99GVGCuB8hQRdWKSQNYGwm3v+Cv/58J8YuCmFAB OhYiMH2xVL0Vsyqsu0VbQcGh3/2JmqybuKitQM48F2YGmEpZmiLcA5SjBqMKUwrT0miG 7hssMLOUJKgMGYcXzt4znFdlhv9wVqDWHl1/QzQIvbwHynbRD6dQiPtdmP4WR6ZPaDEA q5TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694161981; x=1694766781; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rHjh/tvRUkTZlJLKQ6F4Ss7Ni3lFZQEz8GO6u5HE2EQ=; b=FuWacCiY2lbJ2GJUc8NLCDR17UbVXho4LgBKiiHbX5D0wIaXHMF5KhtgCF/KGCNB0T SsiKudqh4cnLSK0MyLgQy+tcD61Io2UfHDR4KKjz9jK5lGoDps6Ac7DfFdHJTqSiMXzE qPY7A52JkZADOuKNvyrdvcIk1MG+RcWzm4T18xOt/Q8hoE9pgvgUsXUFtbqc6pGa5JVR pSNhGRkx1/XbpeRP5pipe1PZSelsE31JejTFOE1Tn3bS28CjBEULsFIbmK4YwPkKcJ0Q ab5E6mDbXgUD/U7vzviJapUZacWSsPpKAQBtWYRtmUwSjHy0K39uyFbMkXCcEN0A8Tdz Zqrw== X-Gm-Message-State: AOJu0YwZXGA0JfFQZLtVATB4QRvp2ZM+KPwU4McxtsiSkOfoAqQV6tQn ktC5UiE6FniIDggic0SDu9z+0oZATZwPE9mkb1A= X-Google-Smtp-Source: AGHT+IG5jV0+b9Il6Kq58bN9J1MlBIbzYsUv9LxlVbtIg18gsdomlVJ4p47olRlA6btfoGBeu8JzN6VFsCn7QfYgYWI= X-Received: by 2002:a17:906:3051:b0:9a2:26e4:a5e8 with SMTP id d17-20020a170906305100b009a226e4a5e8mr1322716ejd.3.1694161980924; Fri, 08 Sep 2023 01:33:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Fri, 8 Sep 2023 09:32:47 +0100 Message-ID: Subject: Re: Last call for bikeshedding on attribute sym/exalias/reverse_alias To: Alexandre Oliva Cc: "gcc@gcc.gnu.org" , Nathan Sidwell , Eric Botcazou , Jan Hubicka , "Joseph S. Myers" Content-Type: multipart/alternative; boundary="00000000000010a7f60604d4d326" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,WEIRD_QUOTING autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000010a7f60604d4d326 Content-Type: text/plain; charset="UTF-8" On Fri, 8 Sept 2023, 06:26 Alexandre Oliva via Gcc, 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 > --00000000000010a7f60604d4d326--