From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by sourceware.org (Postfix) with ESMTPS id 508983858D3C; Sun, 7 May 2023 18:33:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 508983858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1683484426; i=anlauf@gmx.de; bh=LyHaerYI0/AmsSMiTAtRVaooWgupfkh67FVk2U9Udjs=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=fdVTOeq1R7l1lNNWDuBsBG64jLnNIPXCWjN/vR2eKADD/cLZs8c79neOrI8LBJGl0 cYtPP9xXbCaQV91nCj3R7uO1xb5UC9g8HZWJu7nJ755EERBMNcpHpCYVa6hKjdx5Pq on1ym3p7coTXbJeSzKPlgUucIZfegg2pdz20SjeAzbb9z79sLXCs8sS88nwvBZeVC9 Oyk2wr+Dy1NxWmxjvKtMsqdAvWw0VS2On9EWO201JIcnpziVakzJphH+Rbb1eAnlDn VfvdX6MeL/vOIXSWOHnmQEvrxRXB+QvmJ5e1blo3tp62tnLd+GdkpqDxRefyXXfnqx JcbU7slKsnvLw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([79.232.155.241]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MHXFr-1pzpoe3Hvt-00Db4Z; Sun, 07 May 2023 20:33:45 +0200 Content-Type: multipart/mixed; boundary="------------Ps92bZmDeT3J2Syhj22PfLI3" Message-ID: <658d646d-d699-0d7c-06ce-396af393008f@gmx.de> Date: Sun, 7 May 2023 20:33:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: [patch, fortran] PR109662 Namelist input with comma after name accepted To: Jerry D , sgk@troutmask.apl.washington.edu, gfortran Cc: gcc-patches Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: <508ee742-97fa-9f61-ab65-98d3fa8e7dca@gmx.de> Content-Language: en-US From: Harald Anlauf In-Reply-To: X-Provags-ID: V03:K1:tMXgES3m6n7I9PNact+XrIM06F3SogSHgo5T0LJuqiNzbz/U9WR iTBxvAQA9zsgHSTUhE0NLGOOiEtlfFht6mUIdZyYNsPbdJnafIc2oTNECyCoWQme1/iVjGl w7HOw7JUa3uxXwfsgaVxEiBF8Z3hJcXZHkTsDzeVIH9vkkPirNyeaZSA65Ql/vnmgpuGCkZ tU64Sazk68vidI1qoGDQw== UI-OutboundReport: notjunk:1;M01:P0:thgW/wfgNqk=;VQ/HKv4X8opQn3ZcrpusoyCIYth Lqi0lR0Kj1CnzaVk4aQjs1NgHY7y8PMXWsjR3D7W1yDbNPC2oL6gHb91eZbGikfjHBjdAojGh Nf1HldmeYDoc7xuAXkQqyVai0ve9fBwxWhyho5PAymZ5jaAG+B1kIThaDbuqwZT1qozSEbzdi 6kqI2CxIGViIDCtaBv0IlmQ4A7N1Cd82eLHkCMeGZ2keQYAfESbWNFgMQEkleh4CR0fAHgWT/ k47VBAM2rV5IfRPpw6FQOfHTX4QbqBpS103p5h5SaQ4RyR3wurDtsbmGOrTy1OhXszFiRzImG qMrASg6RD2fHmMNaBYvN2ZxhVEtBq/gsOntWu1cdfmdJv5qFsmLK7Zg9u3ZQiNkbqwAgKJ6dZ x9sD/p+sp8hcdLVTTbDNTiK32QahdK8KDbYP2kREfP8S9FIej/0raJzLc26Z0U1pwQicd1EHG MeRq/8txBGg2XK0pvu5MPncNFExXFi/m/p0nvsNU/lawXnFaKE1N+Qu0VleSKiylpsR0oxh5q JmxSkKynRdfDJ4l5M1MLPj72IQqo5hRTa0Ro4HuS98x5E1jIca49Ya53IrUbujOnZ5YuAHeld 9BgdjsJ90Kpc1RxIZM2vmKTx4+scuohFY0PoawyWjDVVhnolWpu2pWlrHXHoiE3FNDi5AlFcF LJDo9cx2NDkKqZamc5rzjAhiZrXhex20U+qVjlD8G8CGxksNtjVsIeBevIZEBrfsEPSRyWUYV O2cSXuILFeTtLSaz0gceCC+x9eCu4x18z+0p5HKQUeelUblaaoS4S1wA542rtlhlwVM/I6Syy hAkLKWREFQb41vpLhpAlzwOB7Hb9kUnEWoFoX1CLN5GXJ2z8p2WTm/3jqUUtJDU32lyPNhiXA pAg+4S4H5lPgnGjTVqaeNxBugF/QILmCmqTor5q3/3FPHM9OqZ7Oit1JyG6BtGv3Lt8UnX8X3 pyZOAg== X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------Ps92bZmDeT3J2Syhj22PfLI3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jerry, I've made a small compiler survey how they behave on namelist read from an internal unit when: 1.) there is a single input line of the type "&stuff" // testchar // " n =3D 666/" 2.) the input spans 2 lines split after the testchar 3.) same as 2.) but first line right-adjusted See attached source code. Competitors: Intel, NAG, NVidia, gfortran at r14-547 with -std=3Df2018. My findings were (last column is iostat, next-to-last is n read or -1): NAG: Compiler version =3D NAG Fortran Compiler Release 7.1(Hanzomon) Build 71= 01 1-line: > < 666 0 2-line/left: > < 666 0 2-line/right: > < 666 0 1-line: >!< -1 187 2-line/left: >!< -1 187 2-line/right: >!< -1 187 1-line: >/< -1 187 2-line/left: >/< -1 187 2-line/right: >/< -1 187 1-line: >,< -1 187 2-line/left: >,< -1 187 2-line/right: >,< -1 187 1-line: >;< -1 187 2-line/left: >;< -1 187 2-line/right: >;< -1 187 1-line: tab 666 0 2-line/left: tab 666 0 2-line/right: tab 666 0 1-line: lf -1 187 2-line/left: lf -1 187 2-line/right: lf -1 187 1-line: ret -1 187 2-line/left: ret -1 187 2-line/right: ret -1 187 My interpretation of this is that NAG treats tab as (white)space, everything else gives an error. This is the strictest compiler. Intel: Compiler version =3D Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.9.0 Build 20230302_00000= 0 1-line: > < 666 0 2-line/left: > < 666 0 2-line/right: > < 666 0 1-line: >!< -1 -1 2-line/left: >!< 666 0 2-line/right: >!< 666 0 1-line: >/< -1 0 2-line/left: >/< -1 0 2-line/right: >/< -1 0 1-line: >,< -1 17 2-line/left: >,< -1 17 2-line/right: >,< -1 17 1-line: >;< -1 17 2-line/left: >;< -1 17 2-line/right: >;< -1 17 1-line: tab 666 0 2-line/left: tab 666 0 2-line/right: tab 666 0 1-line: lf 666 0 2-line/left: lf 666 0 2-line/right: lf 666 0 1-line: ret -1 17 2-line/left: ret -1 17 2-line/right: ret -1 17 Nvidia: Compiler version =3D nvfortran 23.3-0 1-line: > < 666 0 2-line/left: > < 666 0 2-line/right: > < 666 0 1-line: >!< -1 -1 2-line/left: >!< -1 -1 2-line/right: >!< -1 -1 1-line: >/< -1 -1 2-line/left: >/< -1 -1 2-line/right: >/< -1 -1 1-line: >,< -1 -1 2-line/left: >,< -1 -1 2-line/right: >,< -1 -1 1-line: >;< -1 -1 2-line/left: >;< -1 -1 2-line/right: >;< -1 -1 1-line: tab 666 0 2-line/left: tab 666 0 2-line/right: tab 666 0 1-line: lf -1 -1 2-line/left: lf 666 0 2-line/right: lf 666 0 1-line: ret 666 0 2-line/left: ret 666 0 2-line/right: ret 666 0 gfortran (see above): Compiler version =3D GCC version 14.0.0 20230506 (experimental) 1-line: > < 666 0 2-line/left: > < 666 0 2-line/right: > < 666 0 1-line: >!< -1 -1 2-line/left: >!< -1 0 2-line/right: >!< 666 0 1-line: >/< -1 0 2-line/left: >/< -1 0 2-line/right: >/< -1 0 1-line: >,< 666 5010 2-line/left: >,< 666 5010 2-line/right: >,< 666 5010 1-line: >;< 666 0 2-line/left: >;< 666 0 2-line/right: >;< 666 0 1-line: tab 666 0 2-line/left: tab 666 0 2-line/right: tab 666 0 1-line: lf 666 0 2-line/left: lf 666 0 2-line/right: lf 666 0 1-line: ret 666 0 2-line/left: ret 666 0 2-line/right: ret 666 0 So there seems to be a consensus that "," and ";" must be rejected, and tab is accepted (makes real sense), but already the termination character "/" and comment character "!" are treated differently. And how do we want to treat lf and ret in internal files with -std=3Df20xx? Cheers, Harald On 5/7/23 19:33, Jerry D via Gcc-patches wrote: > On 5/6/23 11:15 AM, Harald Anlauf via Fortran wrote: >> Hi Jerry, Steve, >> >> I think I have to pour a little water into the wine. >> >> The patch fixes the reported issue only for a comma after >> the namelist name, but we still accept a few other illegal >> characters, e.g. ';', because: >> >> #define is_separator(c) (c =3D=3D '/' ||=C2=A0 c =3D=3D ',' || c =3D=3D= '\n' || c =3D=3D ' ' \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 || c =3D=3D '\t' || c =3D=3D '\r' || c =3D=3D ';' || \ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (dtp->u.p.namelist_mode && c =3D=3D '!')) >> >> We don't want that in standard conformance mode, or do we? >> >> Cheers, >> Harald >> >> On 5/6/23 06:02, Steve Kargl via Gcc-patches wrote: >>> On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote: >>>> The attached patch adds a check for the invalid comma and emits a >>>> runtime >>>> error if -std=3Df95,f2003,f2018 are specified at compile time. >>>> >>>> Attached patch includes a new test case. >>>> >>>> Regression tested on x86_64-linux-gnu. >>>> >>>> OK for mainline? >>>> >>> >>> Yes.=C2=A0 Thanks for the fix.=C2=A0 It's been a long time since >>> I looked at libgfortran code and couldn't quite determine >>> where to start to fix this. >>> >> > > As I think back, I don't recall ever seeing a semi-colon used after a > NAMELIST name, so I think we should reject it always.=C2=A0 The other "s= oft" > blanks we should allow. > > I will make a another patch on trunk to reject the semi-colon and if no > one objects here I will test and push it. > > Regards, > > Jerry > > --------------Ps92bZmDeT3J2Syhj22PfLI3 Content-Type: text/x-fortran; charset=UTF-8; name="pr109662-xx.f90" Content-Disposition: attachment; filename="pr109662-xx.f90" Content-Transfer-Encoding: base64 cHJvZ3JhbSB0ZXN0bm1scmVhZAogIHVzZSBpc29fZm9ydHJhbl9lbnYsIG9ubHk6IGNvbXBp bGVyX3ZlcnNpb24KICBpbXBsaWNpdCBub25lCiAgcHJpbnQgKiwnQ29tcGlsZXIgdmVyc2lv biA9ICcsdHJpbShjb21waWxlcl92ZXJzaW9uKCkpCiAgY2FsbCB0ZXN0ICgiICIpCiAgY2Fs bCB0ZXN0ICgiISIpCiAgY2FsbCB0ZXN0ICgiLyIpCiAgY2FsbCB0ZXN0ICgiLCIpCiAgY2Fs bCB0ZXN0ICgiOyIpCiAgY2FsbCB0ZXN0IChhY2hhcig5KSwgICJ0YWIiKQogIGNhbGwgdGVz dCAoYWNoYXIoMTApLCAibGYiKQogIGNhbGwgdGVzdCAoYWNoYXIoMTMpLCAicmV0IikKY29u dGFpbnMKICBzdWJyb3V0aW5lIHRlc3QgKGMsIGRlc2MpCiAgICBjaGFyYWN0ZXIsICAgIGlu dGVudChpbikgICAgICAgICAgIDo6IGMKICAgIGNoYXJhY3RlcigqKSwgaW50ZW50KGluKSwg b3B0aW9uYWwgOjogZGVzYwogICAgY2hhcmFjdGVyKDgpICA6OiBkCiAgICBjaGFyYWN0ZXIo MTYpIDo6IGxpbmUsIGxpbmVzKDIpCiAgICBpbnRlZ2VyICAgICAgIDo6IGlvcwogICAgaW50 ZWdlciAgICAgICA6OiBuCiAgICBuYW1lbGlzdC9zdHVmZi9uCiAgICBjaGFyYWN0ZXIoKiks IHBhcmFtZXRlciA6OiBzMSA9ICImc3R1ZmYiLCBzMiA9ICIgbiA9IDY2Ni8iCgogICAgZCA9 ICAiPiIgLy8gYyAvLyAiPCI7IGlmIChwcmVzZW50IChkZXNjKSkgZCA9IGRlc2MKICAgICEg UHJlcGFyZSBpbnB1dDoKICAgIGxpbmUgICAgID0gczEgLy8gYyAvLyBzMgogICAgbGluZXMo MSkgPSBzMSAvLyBjICAgICAgICAgICAgICAhIExlZnQtYWRqdXN0ZWQKICAgIGxpbmVzKDIp ID0gczIKICAgICEgU2luZ2xlIGxpbmUgaW5wdXQKICAgIG4gPSAtMQogICAgcmVhZChsaW5l LG5tbD1zdHVmZixpb3N0YXQ9aW9zKQogICAgd3JpdGUoKiwqKSAiMS1saW5lOiAgICAgICAi LCB0cmltIChkKSwgbiwgaW9zCiAgICAhIE11bHRpLWxpbmUgaW5wdXQKICAgIG4gPSAtMQog ICAgcmVhZChsaW5lcyxubWw9c3R1ZmYsIGlvc3RhdD1pb3MpCiAgICB3cml0ZSgqLCopICIy LWxpbmUvbGVmdDogICIsIHRyaW0gKGQpLCBuLCBpb3MKICAgIGxpbmVzKDEpID0gYWRqdXN0 ciAobGluZXMoMSkpICAgISBSaWdodC1hZGp1c3QgZmlyc3QgbGluZQogICAgbiA9IC0xCiAg ICByZWFkKGxpbmVzLG5tbD1zdHVmZiwgaW9zdGF0PWlvcykKICAgIHdyaXRlKCosKikgIjIt bGluZS9yaWdodDogIiwgdHJpbSAoZCksIG4sIGlvcwogIGVuZCBzdWJyb3V0aW5lIHRlc3QK ZW5kIHByb2dyYW0gdGVzdG5tbHJlYWQK --------------Ps92bZmDeT3J2Syhj22PfLI3--