From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-19.smtpout.orange.fr [80.12.242.19]) by sourceware.org (Postfix) with ESMTPS id E83C93858D35 for ; Tue, 21 Nov 2023 11:33:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E83C93858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E83C93858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=80.12.242.19 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700566439; cv=none; b=wlXJ+EKXovTttES60EcQJIW+987bkMFKxe3GGeIJrLtzjr38FLNCEUYEJcpyBV+7rlmuOQq2uVLcsscpTO4KN38rtfYO+R/ooz9mQJbp7mX03Xyah470fNiY4ua7BqfgFbXpSg6bQqflA1aGEPCXoNlTIU6pNXcQZWwEB1JU9Aw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700566439; c=relaxed/simple; bh=ReN1aWu2mg3x9hXjqGmteUZ9KcUwdXuP9EOb8tysil4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=PZbozRTL7Kf3hunAAlY0S/sFd1wb1bkHd+pYUCwNFnARjL9sBtOu0lAL5Kx5JPvdib+m+zKxVTPJzWIWomDhyAstHsNjOdWhORwQyz0CnnMp7BMZ5b6vDuHqXhQOpn7oBBJZHuNuvDbU4Z9VggMXlvs/cCSTQdV8gmRFlZRxTi8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.1.13] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id 5P0nrreXxFU7r5P0trgz0u; Tue, 21 Nov 2023 12:33:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1700566436; bh=Mlz2keJDyHHjfvHpR9e8Vdv/vzQpYoQL5B9qGEVGKxs=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=mtsazMcj0SYQtjieazGkO9uBo5g17/h5VBeT+7ud91HbCKzIyeelGMiOJykLb2lqo jwfPMT2LjJiMOWYmE/j2wIK/MZ7mQ+p2ZfRFoMP82LC95qWJU1JXiSLBGHbIOlNjq9 42RgH9ZeTEnFRo+9vZNOopgrXB5sSbQKwkBf0/MRlAMHRPY6yg99b4r8fZVMod+tCY 2Jw5tQPuh9ZrBUwRl4pffyKUApo4pnm4BqNGj0/DBu9EmL/8bNfaZPUhHT5BCIbfFi kyX5eUMBly2ADRUUDatt3TvJjKKYhLhaKIDpL1wV05P7yfSQ5Gs835gsdTK8H0hcRX LRorMsgqwXaYw== X-ME-Helo: [192.168.1.13] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Tue, 21 Nov 2023 12:33:56 +0100 X-ME-IP: 86.215.161.51 Message-ID: <84f48fee-a5b8-4bef-aa9b-f176d3cfbfa6@orange.fr> Date: Tue, 21 Nov 2023 12:33:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH, v2] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609] Content-Language: en-US To: sgk@troutmask.apl.washington.edu, Harald Anlauf Cc: fortran , gcc-patches References: <2898e351-eee8-45dd-a05d-0280378ba872@gmx.de> From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,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: Hello, Le 20/11/2023 à 20:02, Steve Kargl a écrit : > 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. > Harald, you mentioned the lack of GFC_STD_F2023_DEL feature group in your first message, but I don't quite understand why you didn't add one. It seems to me the most natural way to do this. >> 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? > I suggest we emit a warning by default, error with -std=f2023 (I agree with Steve that we should push towards strict f2023 conformance), and no diagnostic with -std=gnu or -std=f2018 or lower. > 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. Agreed, these seem to explicitly test mismatching kinds, so add an option to prevent error. Mikael