Re: [PATCH, v2] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

[Mikael Morin <morin-mikael@orange.fr>]

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