From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40593 invoked by alias); 8 Jul 2019 21:42:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 39795 invoked by uid 89); 8 Jul 2019 21:42:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=Making X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Jul 2019 21:42:22 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x68LgGC2002141; Mon, 8 Jul 2019 16:42:16 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x68LgFXV002134; Mon, 8 Jul 2019 16:42:15 -0500 Date: Mon, 08 Jul 2019 21:44:00 -0000 From: Segher Boessenkool To: Jozef Lawrynowicz Cc: Richard Sandiford , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Perform case-insensitive comparison when decoding register names (PR target/70320) Message-ID: <20190708214215.GI30355@gate.crashing.org> References: <20190704133259.3a063d91@jozef-kubuntu> <20190704224416.GG18316@gate.crashing.org> <20190708222129.59562c2e@jozef-kubuntu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190708222129.59562c2e@jozef-kubuntu> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00620.txt.bz2 On Mon, Jul 08, 2019 at 10:21:29PM +0100, Jozef Lawrynowicz wrote: > On Mon, 08 Jul 2019 21:14:36 +0100 > Richard Sandiford wrote: > > > Segher Boessenkool writes: > > > It isn't obviously safe either. Are there any targets that have names > > > for different registers that differ only in case? You could say that > > > such a design deserves what is coming for it, but :-) > > Indeed, I did have a read through all the definitions of REGISTER_NAMES in the > gcc/config and could not spot any cases where different register nanes differed > only in their case. I didn't check it programmatically though, so it's > not impossible I missed something.. You also haven't checked future GCC versions, for future processors ;-) And, not all out-of-tree ports, either. Gratuitously breaking those isn't ideal. > > >> --- a/gcc/varasm.c > > >> +++ b/gcc/varasm.c > > >> @@ -947,7 +947,7 @@ decode_reg_name_and_count (const char *asmspec, int *pnregs) > > > > > > This is used for more than just clobber lists. Is this change safe, and > > > a good thing, in the other contexts where it changes things? > > It appears to be used for only two purposes (mostly via the > "decode_reg_name" wrapper): > - Decoding the register name in an asm spec and reporting any misuse > - Decoding parameters passed to command line options > Generic options using it are -fcall-used/saved-REG and -ffixed-REG > -fstack-limit-register. > Backends use it for target specific options such as -mfixed-range= for SPU. > Apart from that there appears to be a single other use of it in make_decl_rtl > to report when "register name given for non-register variable", although I > could not immediately reproduce this myself to understand this specific case it > is triggered for. It is used for register asm, yes. This is e.g. void f(int x) { int y asm("r10"); y = x; asm ("# %0" :: "r"(y)); } which complains warning: ignoring 'asm' specifier for non-static local variable 'y' (Making the declaration of y static does nothing, doesn't make it use r10 that is; adding "register" does though). > Ok, yes a DEFHOOKPOD or similar sounds like a good idea, I'll look into this > alternative. What is that, like target macros? But with some indirection? Making this target-specific sounds good, thanks Jozef. Segher