From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id E1AE63857806 for ; Tue, 18 Jul 2023 11:38:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E1AE63857806 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-lj1-x233.google.com with SMTP id 38308e7fff4ca-2b9338e4695so44598181fa.2 for ; Tue, 18 Jul 2023 04:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689680283; x=1692272283; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UTgOqk9rFHMA0E9vPqhbUbzpmpaDLHfG26CtSMGwQDU=; b=Us+76gBhli7PZVoIp3fabFT0j+q2Czyzf9b0fhixQ6fVIkw2AlrVVe6sI7TwAHFW6A +Iq2GlPrDU1dUyX1V2BIFvimqKdX+Ks36vacl0zYeH4Teb6q8A7RTrDZ/e5M0+3KRFgD 4Vk6mESl5RtZrwPQ+GXbSIbe0en62wRRV4wzjMysgvkC0CG7e8hKHGf8W9qtxB9O0p2y H9Q2JMaPuZNkyXr0ODA4a2ucbLauFgfjazL7ZfW0Wz8d8g8aumcM8xWhbO+POBFfcfNU AUKbp3EC7bsZjQ/42X8EX0I9s+Hn6TLE7EQjP7Fn70hkMCbQHF3AvAWlmc4iY0jwSoE/ 9pnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689680283; x=1692272283; h=content-transfer-encoding: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=UTgOqk9rFHMA0E9vPqhbUbzpmpaDLHfG26CtSMGwQDU=; b=kJCQZobS4aMA2DXQ203FPffrhgna9wfUJ4j56tB866Cdxqn0acndx8dOHy2M9EjD5O /Vnz/OYr79OpAVtFtbVB/Ovb/LgzMHUxvrnwV8xFAxyZCgW5Mw/ejYRL095Lt6qkXVfk mZ459FLPS1oOkS9CQRBV5MNrsUH5P3sl5dVNzk7o2TnYsWgTjHGuXtXQo9MAipFm8D9d LVN1nZ8+t4uFfZBIfHOTJiIeAeR1ZsJXydO37W+afrXGKb0ejgg5Ji/JDCoAdmY7yA+Y UpDZL6UKmDtMrcrc2KaPK4m0NAeyKwvRjVPX3tH24O6ITQjI4esIw/GMWltdvgjhq0iu KM7w== X-Gm-Message-State: ABy/qLYPgk+kSdEmBvSze2iRZCtjkXMTATi2Xq15rYHwH6305h3pEErA z3ZXNciXGproTjEs8Xj9IkTSgrivfxU+LXkLqIY= X-Google-Smtp-Source: APBJJlHbTwpaOzIT/ES/FEXUZuvbw1FMHMOKI2uab+PoWh+UzsIi3biqNSEyuNZ3rAdCUEZXwH4JtTDxjx16thsW/Ew= X-Received: by 2002:a2e:b70a:0:b0:2b6:eb5a:6504 with SMTP id j10-20020a2eb70a000000b002b6eb5a6504mr11209841ljo.18.1689680283212; Tue, 18 Jul 2023 04:38:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Tue, 18 Jul 2023 13:37:51 +0200 Message-ID: Subject: Re: [PATCH v3] Introduce attribute reverse_alias To: Alexandre Oliva , Jan Hubicka Cc: Nathan Sidwell , gcc-patches@gcc.gnu.org, jason@redhat.com, joseph@codesourcery.com, hainque@adacore.com, ebotcazou@adacore.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Tue, Jul 18, 2023 at 6:29=E2=80=AFAM 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 (&foo =3D=3D &bar); // ok > > with: > > int __attribute__ ((reverse_alias ("bar"))) foo(); > > static_assert (&foo =3D=3D &bar); // error, bar is not a C++ symbol > > int __attribute__ ((alias ("bar"))) baz(); // ok > > static_assert (&foo =3D=3D &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