From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id A5BBC3858D35; Mon, 20 Nov 2023 19:02:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A5BBC3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A5BBC3858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=128.95.76.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700506932; cv=none; b=GRhMD5VVX9xDJ3ZRg0tF+N5HosmY1Or6R+cGQVuf9Uq5W1G+/NE8PblhEV2xA2D6qoTNAm90y9Js6j4Lb4sdWBWjFtD/lHHMkrC4vxJb9K7Au6Ry2LnPNLP2RhD19mZn2N8B8uweDgWPyAtJ1A1Ycffh9vH1dy7gCrrUq8DQJWw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700506932; c=relaxed/simple; bh=mMuIcGLQ0d0EclRLWDvtPJmIqfhAoihcZS9QAhj6z80=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=Sgpm9BIW1zgxvaOPEqOSXHACLhRTyf2RVC9Y97L/XpKGkojsJaLcQBXITQL1Dri+fAuVEECEjFH9VIrkLFBv9BePSD7HT+iFU4sYE7zf1YmZ3HISfJFDmclEm9I6HFwQfnkijcELYuuqgdrkEgcZn0NbKNWwf9zv9plziFxVJqo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 3AKJ29xR045974; Mon, 20 Nov 2023 11:02:09 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 3AKJ29hZ045973; Mon, 20 Nov 2023 11:02:09 -0800 (PST) (envelope-from sgk) Date: Mon, 20 Nov 2023 11:02:09 -0800 From: Steve Kargl To: Harald Anlauf Cc: fortran , gcc-patches Subject: Re: [PATCH, v2] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609] Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <2898e351-eee8-45dd-a05d-0280378ba872@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2898e351-eee8-45dd-a05d-0280378ba872@gmx.de> X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Harald, Sorry about delayed response. Got side-tracked by Family this weekend. On Sun, Nov 19, 2023 at 09:46:46PM +0100, Harald Anlauf wrote: > > On 11/19/23 01:04, Steve Kargl wrote: > > On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote: > > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > > > > > > Not in its current form. > > > > > { > > > + int first_int_kind = -1; > > > + bool f2023 = ((gfc_option.allow_std & GFC_STD_F2023) != 0 > > > + && (gfc_option.allow_std & GFC_STD_GNU) == 0); > > > + > > > > If you use the gfc_notify_std(), then you should not need the > > above check on GFC_STD_GNU as it should include GFC_STD_F2023. > > this is actually the question (and problem). For all new features, > -std=gnu shall include everything allowed by -std=f2023. Yes. > Here we have the problem that the testcase is valid F2018 and is > silently accepted by gfortran-13 for -std=gnu and -std=f2018. F2023 is the Fortran standard and supercedes previous Fortran standards. If there is a conflict between the standing standard and an old standard, then the standing standard should take precedence unless one specifically uses, for example, -std=f2018. After 20+ years of contributing to gfortran, I've come to believe that the default -std= should be the current standard, and -std=gnu should be deprecated. All GNU extensions should require an option to active. For example, write(*,*), 'hello' end gfortran12 -o z a.f90 a.f90:1:10: 1 | write(*,*), 'hello' | 1 Warning: Legacy Extension: Comma before i/o item list at (1) This should be an error unless the -fallow-write-stmt-comma is used. The option would simply degrade the error to a warning. Why, you ask? To encourage people to write standard conforming code. Unfortunately, that horse has left the barn. > I prefer to keep it that way also for gfortran-14, and apply the > new restrictions only for -std=f2023. Do we agree on this? If gfortran wants to maintain the status quo for 14, then it should probably remove the -std=f2023 patch and wait for the branch to 15. > Now that should happen for -std=gnu -pedantic (-w)? -pedantic is not a very effective option and should be ignored. > I have thought some more and came up with the revised attached > patch, which still has the above condition. It now marks the > diagnostics as GNU extensions beyond F2023 for -std=f2023. > > The mask f2023 in the above form suppresses new warnings even > for -pedantic; one would normally use -w to suppress them. > > Now if you remove the second part of the condition, we will > regress on testcases system_clock_1.f90 and system_clock_3.f90 > because they would emit GNU extension warnings because the > testsuite runs with -pedantic. It seems that the solution is to fix the code in the testsuite. With -std=f2023 or -std=gnu, the code should error. With -std=f2018 (or older?), the code should compile. It's been too long for my memory, doesn't the use of '{ dg-options "-std=f023" }' supercede the set of predefined options such as -pedantic? > The options I see: > > - use patch-V1 (although diagnostics are better in V2), > > - use patch-V2, > > - use patch-V2, but enable -pedantic warnings for previously > valid code, and adjust the failing testcases I suppose that this last one is the best option. > > - ??? > > > Elsewhere in the FE, gfortran uses gfc_notify_std() to enforce > > requirements of a Fortran standard. The above would be > > > > if (count->ts.kind < gfc_default_integer_kind > > && gfc_notify_std (GFC_STD_F2023, "COUNT argument to SYSTEM_CLOCK " > > "at %L must have kind of at least default integer", > > &count->where)) > > I tried this first, and it did not do the job. > > The logic in gfc_notify_std is: > > estd = std & ~gfc_option.allow_std; /* Standard to error about. */ > error = (estd != 0); > if (error) > msg = notify_std_msg (estd); > ... > > So for -std=f2023 we get estd=0, error=false, and *NO* error. > For -std=f2018 we get error=true and an error message. > This is the opposite of what is needed. > > Can you please try yourself? > I was afraid you were going to say this. :-) :-) The holidays draw near. I can probably find the time to poke at gfortran. > > Note, gfc_notify_std() should add the 'Fortran 2023: ' string, > > if not, that should be fixed. > > This I did fix. Thanks. > > Of course, I seldom provide patches if others don't have a comment > > then do as you like. > > Thanks for your feedback! No, thank you for continuing to peck away at gfortran issue. -- steve