From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id 32A9E3858D20 for ; Tue, 18 Jul 2023 04:29:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 32A9E3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-6b9d68a7abaso1208744a34.3 for ; Mon, 17 Jul 2023 21:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1689654556; x=1692246556; h=mime-version:user-agent:message-id:in-reply-to:date:errors-to :references:organization:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=IVdS7jIXQof7qmMHUTSEBjPMNE1zJRMOP+pZ5QMqZ9o=; b=PrV3VckxvR6wNtgN6i/ot++JJaEdQZLqLnxgaU5auBi347IMieWEVShhswnoA7y38/ DItwSYHvKNEOkdqDPktEmsNxUTNxOPAhTj852OQDnNC7uu/Zq1ytarOoTotnqFNROlze kAQ35OJsqTiSPPRIfkXSzgXf48VkiXWtcJ3jcnn1QL337s9kmkyYsMm8NumZPvcPKp2U T6hPKZ1h3vrHwLgRCoBmGB+oelBHwaP1uWbtpayhYQO+839XXrXWQWYHOtq516om62wg s0WKjybhf09x4grSKTRpBf6JhcQGIATzgYsSuPRwgoNK2lx2/MxM2xXpWkVuxy7sGYDg Yldg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689654556; x=1692246556; h=mime-version:user-agent:message-id:in-reply-to:date:errors-to :references:organization:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=IVdS7jIXQof7qmMHUTSEBjPMNE1zJRMOP+pZ5QMqZ9o=; b=On5xQzaoXBggaNGQugcd1+nfWHsSbDE1PbC55keGxKaOAqxcgHzcsuY8Gsb/ptx7/O Asb538tO5d9MsMoRVIOS61wLq11F1TsoWKBKMyh8T2aRvdszFBzo/OWmKuX1upgGbXLk klmWIr+tMmGo/hvxNeoMn7uqDz8SW6HlifGTKlccnulnqSYQe6V4UxradjDtOUhr88tM GQAqYLGyEMKeKijlh0iuQ0PkvxoGZFYsnzq1qpkS3Pf76YYh/YP1GrxKTX2rctLzMClO OwLAkP2jps6+LBd96m/TUIy8SV9UwIv4abKolU5vTaOwcTdcDIG/LwypEAzTXitWGYSB mNlQ== X-Gm-Message-State: ABy/qLYKfUA+0vnijtWroAIvDTCfC9uNqbzObEonNmw8ONq6juLQU+/e TO4woQkeSI3og6qnmi7tDzeLdw== X-Google-Smtp-Source: APBJJlGgveJxxpE5wtxAFETTAjWoXHLwyawqtEXt4GK4qJhVUbhmPA4+hH3/nmbNNS2r3uO3bEljwQ== X-Received: by 2002:a05:6870:9694:b0:1b0:b13:c18 with SMTP id o20-20020a056870969400b001b00b130c18mr14592446oaq.3.1689654556501; Mon, 17 Jul 2023 21:29:16 -0700 (PDT) Received: from free.home ([2804:7f1:2080:963:14b5:c9cf:90b3:992d]) by smtp.gmail.com with ESMTPSA id y4-20020a056870388400b001b3538afd01sm597364oan.51.2023.07.17.21.29.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jul 2023 21:29:15 -0700 (PDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 36I4T1IO3703404 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 18 Jul 2023 01:29:02 -0300 From: Alexandre Oliva To: Nathan Sidwell Cc: gcc-patches@gcc.gnu.org, jason@redhat.com, joseph@codesourcery.com, hainque@adacore.com, ebotcazou@adacore.com Subject: Re: [PATCH v3] Introduce attribute reverse_alias Organization: Free thinker, does not speak for AdaCore References: Errors-To: aoliva@lxoliva.fsfla.org Date: Tue, 18 Jul 2023 01:29:01 -0300 In-Reply-To: (Nathan Sidwell's message of "Sat, 15 Jul 2023 17:55:56 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: 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 == &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. > 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