From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <morin-mikael@orange.fr>
Received: from smtp.smtpout.orange.fr (smtp-13.smtpout.orange.fr
 [80.12.242.13])
 by sourceware.org (Postfix) with ESMTPS id 502713857352
 for <fortran@gcc.gnu.org>; Fri, 29 Jul 2022 20:36:40 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 502713857352
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 HWimoROO4QUcTHWiro8Q2u; Fri, 29 Jul 2022 22:36:37 +0200
X-ME-Helo: [192.168.1.17]
X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM=
X-ME-Date: Fri, 29 Jul 2022 22:36:37 +0200
X-ME-IP: 86.215.161.154
Message-ID: <46cc765d-469e-d6e8-23c5-dc470028d881@orange.fr>
Date: Fri, 29 Jul 2022 22:36:31 +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, v2] Fortran: detect blanks within literal constants in
 free-form mode [PR92805]
Content-Language: en-US
To: Harald Anlauf <anlauf@gmx.de>, fortran@gcc.gnu.org
Cc: gcc-patches@gcc.gnu.org
References: <trinity-182352dd-523c-42bc-a3d1-17d9b69c0432-1659039117168@3c-app-gmx-bap60>
 <fbc69384-d5db-6a37-9ee0-477e61cf3933@orange.fr>
 <adec596c-edb1-462a-1f2b-a8d1ff7071f5@gmx.de>
From: Mikael Morin <morin-mikael@orange.fr>
In-Reply-To: <adec596c-edb1-462a-1f2b-a8d1ff7071f5@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM,
 JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=no 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 <fortran.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/fortran/>
List-Help: <mailto:fortran-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2022 20:36:42 -0000

Le 29/07/2022 à 21:59, Harald Anlauf via Fortran a écrit :
> 
> Am 29.07.22 um 13:11 schrieb Mikael Morin:
> 
>  > and use gfc_next_char instead of gfc_match_char
>> in get_kind.
> 
> There is one important functionality in gfc_match_char(): it manages
> the locus.  We would need then to add this explicitly to get_kind,
> which does not look to me like a big improvement over the present
> solution.  Otherwise I get test regressions.
> 
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.