From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) by sourceware.org (Postfix) with ESMTPS id B96553858031 for ; Sat, 30 Jul 2022 08:28:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B96553858031 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.17] ([86.215.161.154]) by smtp.orange.fr with ESMTPA id HhpcoQ5ukBDYDHhphonVL5; Sat, 30 Jul 2022 10:28:26 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM= X-ME-Date: Sat, 30 Jul 2022 10:28:26 +0200 X-ME-IP: 86.215.161.154 Message-ID: Date: Sat, 30 Jul 2022 10:28:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH, v3] Fortran: detect blanks within literal constants in free-form mode [PR92805] Content-Language: en-US To: Harald Anlauf , fortran@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org References: <46cc765d-469e-d6e8-23c5-dc470028d881@orange.fr> From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2022 08:28:30 -0000 Le 29/07/2022 à 23:09, Harald Anlauf via Fortran a écrit : > Hi Mikael, > > Am 29.07.22 um 22:36 schrieb Mikael Morin: >> Indeed, I overlooked that, but my opinion remains that we shouldn’t >> play with fixed vs free form considerations here. >> So the options I can see are: >>   - handle the locus in get_kind; we do it a lot already in matching >> functions, so it wouldn’t be different here. >>   - implement a variant of gfc_match_char without space gobbling. >>   - use gfc_match(...), which is a bit heavy weight to match a single >> char string, but otherwise would keep things concise. >> >> My preference goes to the third option, but I’m fine with either of >> them if you have a different one. >> > > how about the attached? > > This introduces the helper function gfc_match_next_char, which is > your second option. > > diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc > index 3f01f67cd49..9fa6779200f 100644 > --- a/gcc/fortran/primary.cc > +++ b/gcc/fortran/primary.cc > @@ -92,14 +92,17 @@ get_kind (int *is_iso_c) > { > int kind; > match m; > + char c; > > *is_iso_c = 0; > > - if (gfc_match_char ('_') != MATCH_YES) > + if (gfc_match_next_char ('_') != MATCH_YES) > return -2; > > - m = match_kind_param (&kind, is_iso_c); > - if (m == MATCH_NO) > + m = MATCH_NO; > + c = gfc_peek_ascii_char (); > + if ((gfc_current_form == FORM_FREE && gfc_is_whitespace (c)) > + || (m = match_kind_param (&kind, is_iso_c)) == MATCH_NO) > gfc_error ("Missing kind-parameter at %C"); > Meh! We killed one check for gfc_current_form but the other one is still there. OK, match_kind_param calls two functions that also gobble space, so there is work remaining here. So please make match_small_literal_constant and gfc_match_name space-gobbling wrappers around space-non-gobbling inner functions and call those inner functions instead in match_kind_param.