From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 6482B385803D for ; Mon, 9 Aug 2021 23:46:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6482B385803D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 179NixcC001868; Mon, 9 Aug 2021 18:45:00 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 179NixoW001867; Mon, 9 Aug 2021 18:44:59 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 9 Aug 2021 18:44:59 -0500 From: Segher Boessenkool To: Bill Schmidt Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, willschm@linux.ibm.com Subject: Re: [PATCH 03/34] rs6000: Add the rest of the [altivec] stanza to the builtins file Message-ID: <20210809234458.GF1583@gate.crashing.org> References: <5394facbf34d21fab7944808ccb27dca74f6f51f.1627562851.git.wschmidt@linux.ibm.com> <20210807000158.GZ1583@gate.crashing.org> <9842d456-9003-8cbf-0e13-40821ae4217c@linux.ibm.com> <20210808202710.GC1583@gate.crashing.org> <3b2a741c-5e94-3689-833a-6bb2be366adf@linux.ibm.com> <0175e9b9-d0a7-f0c2-89b3-230251a1bf80@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0175e9b9-d0a7-f0c2-89b3-230251a1bf80@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 09 Aug 2021 23:46:04 -0000 On Mon, Aug 09, 2021 at 02:18:48PM -0500, Bill Schmidt wrote: > >>"const void" is meaningless, and maybe even invalid C. I think the code > >>is wrong, not (just) the documentation! This wants to be > >> void *const > >>but it is > >> const void * > >>as far as I can see? > >> > >>As I said, this isn't new code, but it seems very wrong! > > > I had to go back and remember where this fits in.  tl;dr:  This is fine. > :-)  More details... > > "const void *" is used as part of the overloading machinery.  It serves > to reduce the number of built-in functions that we need to register with > the front end.  Consider the built-in function that accesses the "lvebx" > instruction.  In rs6000-builtin-new.def, we define it this way: > >   pure vsc __builtin_altivec_lvebx (signed long, const void *); >     LVEBX altivec_lvebx {ldvec} > > Note that this is a "pure" function (no side effects), and we > contractually guarantee (through "const *") that we will not > modify the data pointed to by the second argument. "void" can never be an lvalue (it is an incomplete type), so "const" on it is meaningless (it is not invalid C though afaics). > However, we don't have that freedom with pointer types.  This is why the > built-in function is defined with a void * argument.  Both "const signed > char *" and "const unsigned char *" can be legitimately cast to a "const > void *". Why? "void" is not an object type at all. This is not a documented GCC extension either, and it might even conflict with the existing void * extension (allowing arithmetic on it, by defining sizeof(void)). In either case it is not currently defined. You can assign a pointer to qualified to a pointer to unqualified (and the other way around) just fine, fwiw. You can cast (explicitly or implicitly) exactly the same things to void * as you can to const void *. > This isn't strictly necessary, but without such a trick, we would have > to have two different __builtin_altivec_lvebx functions (with different > names) to handle the different pointer types.  Defining multiple > functions for each such situation is wasteful when defining functions > and when looking them up, and a naming scheme would be needed for > dealing with this. So apparently the GCC overload semantics do not have much to do with how C works otherwise? This sounds not ideal :-/ > This is the way the builtin structure has been working since the "dawn > of time," and I'm not proposing changes to that.  I'm hopeful with the > new system that it is a little clearer what is going on, though, since > you can easily see the const void * arguments in the definitions. Yeah, me too. But it all sounds just wrong. Segher