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 26BCA3857C56 for ; Fri, 21 May 2021 20:51:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 26BCA3857C56 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@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 14LKopPn032762; Fri, 21 May 2021 15:50:51 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 14LKoorc032759; Fri, 21 May 2021 15:50:50 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 21 May 2021 15:50:50 -0500 From: Segher Boessenkool To: Bill Schmidt Cc: gcc-patches@gcc.gnu.org, jakub@redhat.com, jlaw@tachyum.com, dje.gcc@gmail.com Subject: Re: [PATCH 07/57] rs6000: Add functions for matching types, part 1 of 3 Message-ID: <20210521205050.GC10366@gate.crashing.org> References: <7d8e91f0bb4a8677dad1570e1adbcfe6e469e2bf.1619537141.git.wschmidt@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d8e91f0bb4a8677dad1570e1adbcfe6e469e2bf.1619537141.git.wschmidt@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_NUMSUBJECT, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no 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: Fri, 21 May 2021 20:51:54 -0000 Hi! On Tue, Apr 27, 2021 at 10:32:42AM -0500, Bill Schmidt via Gcc-patches wrote: > +enum void_status { The { goes on a new line, in our coding style. > +struct typeinfo { The same is true in structs (but that is violated in some places). > + char isvoid; bool? I'm not asking you to change it, but, is there a reason to use an integer type? > + int val1; > + int val2; Lol :-) Oh the suspense! > +/* Match one of the allowable base types. Consumes one token unless the > + token is "long", which must be paired with a second "long". Optionally > + consumes a following '*' token for pointers. Return 1 for success, > + 0 for failure. */ > +static int > +match_basetype (typeinfo *typedata) > +{ > + return 1; > +} This will be implemented later? > +/* A const int argument may be restricted to certain values. This is > + indicated by one of the following occurring after the "int' token: > + > + restricts the constant to x bits, interpreted as unsigned > + restricts the constant to the inclusive range [x,y] > + [x,y] restricts the constant to the inclusive range [x,y], > + but only applies if the argument is constant. > + {x,y} restricts the constant to one of two values, x or y. > + > + Here x and y are integer tokens. Note that the "const" token is a > + lie when the restriction is [x,y], but this simplifies the parsing > + significantly and is hopefully forgivable. > + > + Return 1 for success, else 0. */ > +static int > +match_const_restriction (typeinfo *typedata) > +{ > + return 1; > +} And this. Okay for trunk with the trivialities fixed. Thanks! Segher