From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id 039723858D35 for ; Tue, 25 Aug 2020 07:50:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 039723858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oliva@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id CD8D41173C4; Tue, 25 Aug 2020 03:50:49 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Jz9t1xiCn5iG; Tue, 25 Aug 2020 03:50:49 -0400 (EDT) Received: from free.home (tron.gnat.com [IPv6:2620:20:4000:0:46a8:42ff:fe0e:e294]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id 03E9E1173C3; Tue, 25 Aug 2020 03:50:48 -0400 (EDT) Received: from livre.home (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 07P7ofxW147857 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Aug 2020 04:50:42 -0300 From: Alexandre Oliva To: Nathan Sidwell Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, joseph@codesourcery.com Subject: Re: [PATCH] introduce attribute exalias Organization: Free thinker, does not speak for AdaCore References: <13ed4563-33bb-f9b5-4b63-0cf0eebf6034@acm.org> <4647d37b-13af-e485-c782-c222360b12b9@acm.org> Errors-To: aoliva@lxoliva.fsfla.org Date: Tue, 25 Aug 2020 04:50:41 -0300 In-Reply-To: <4647d37b-13af-e485-c782-c222360b12b9@acm.org> (Nathan Sidwell's message of "Sat, 15 Aug 2020 17:11:03 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 07:50:51 -0000 On Aug 15, 2020, Nathan Sidwell wrote: > 'alias' is also now a confusing term, because of the concept of object-aliasing. True, but it's also an established attribute name. It seems thus desirable to bring the conceptual framework of the alias attribute to mind through the name of the attribute used in this new feature, but with a twist that distinguishes it from the original attribute in a meaningful way. > The existing alias attribute is defined as: >> The @code{alias} attribute causes the declaration to be emitted as an alias >> for another symbol, which must have been previously declared with the same >> type, and for variables, also the same size and alignment. Declaring an alias >> with a different type than the target is undefined and may be diagnosed. As >> an example, the following declarations: > I.e. it is creating a declaration that is aliased to some other symbol > (which has to also be emitted by the same TU due to the usual elf-like > object file semantics). Notice it says nothing about emitting a > *symbol*. It's an implied expectation that declarations of language entities get symbols associated with them, and that attribute alias causes the symbol name associated with one declaration to refer to the same entity denoted by the named symbol, instead of introducing a separate entity. > The new attribute is emitting a symbol that equates the declaration it > is attached to (i.e. the other way round). I.e., now we have a single declaration of a language entity, and we wish additional symbol names to be associated with it. > Its intent is to allow code written in another language to refer to > this definition. I imagine you'd commonly use the foreign language's > mangling for the string provided. What I have in mind are mnemonic, user-chosen names, rather than machine-mangled ones. > If we spell it 'X', consider: > [[gnu::X ("other")]] int i; > Most commonly, the assembly emitted would contain: > .globl other > .equiv other, i > so, perhaps we should spell it 'equiv'? That's using an existing term. Uhh, my turn to find the term meaningless. Not just because on my machines, aliases use .set rather than .equiv. It's missing about as much context as 'aka' and 'nickname' in the relationship to alias. The problem we face is that alias is a symmetric relationship, in that if X aliases Y, then Y aliases X, but attribute alias is not symmetric: its attribute must be placed in an undefined declaration, naming the already-defined entity. It would have made just as much sense to make it work backwards, namely, attaching the attribute to the defined entity, naming any other undefined declarations that ought to refer to the same entity. That's pretty much the attribute I propose. Thus clearly, though "alias" is symmetric, our use thereof isn't. Our implementation uses the phrase "alias target" to refer to the already-defined entity that a declaration holding an alias attribute should alias; the declaration holding the alias attribute is referred to as an alias. Since attribute alias is already taken, it would thus make sense to look for opposites of alias target to denote the new attribute. Alias source and alias origin are probably the most natural opposites of alias target, but they don't suggest to me what we're looking for. Alias lead might work. Alias bead might, too. OTOH, since the alias attribute is associated with the alias declaration, and it names an alias target; the opposite of that, with an attribute in the alias target declaration, would best have the attribute named alias_target (that's an attribute of the declaration, after all), and then the named symbol would be the alias. This would be surprisingly consistent with the current use of attribute alias: int attribute((alias_target("Y"))) X; // X is the alias target for Y int attribute((alias("Y"))) Z; // Z is an alias for Y Now, if we were to use "equiv", it would make sense to think of the current alias attribute as "equiv_to" / "alias_target". Another possibility that occurs to me is to reuse the existing attribute alias, but naming the equivalent symbol as a second parameter to attribute alias, suggesting a relation alias(X,Y), building on the existing alias(X) in which the Y is implied, and introducing a variant in which it is the X that is implied. Alas, an explicit placeholder is needed in this case. Hmm, maybe such a two-argument variant of alias could be made more readable by requiring the *second* argument to be number 2: int attribute((alias("Y", 2))) X; reading as imperative "alias Y to X", whereas existing uses: int attribute((alias("Y"))) Z; read as imperative "alias Y Z", nonsense, but taken as "alias Z to Y", perhaps by analogy with how "give Y Z" is taken as "give Z to Y". /me jokingly suggests inhalias and exhalias ;-) This is enough bikeshedding for me ;-) -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer