Hi Mikael!

On 11/22/23 10:36, Mikael Morin wrote:
> (...)
> 
>> diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc
>> index 2ac51e95e4d..be715b50469 100644
>> --- a/gcc/fortran/error.cc
>> +++ b/gcc/fortran/error.cc
>> @@ -980,7 +980,11 @@ char const*
>>  notify_std_msg(int std)
>>  {
>>
>> -  if (std & GFC_STD_F2018_DEL)
>> +  if (std & GFC_STD_F2023_DEL)
>> +    return _("Fortran 2023 deleted feature:");
> 
> As there are officially no deleted feature in f2023, maybe use a 
> slightly different wording?  Say "Not allowed in fortran 2023" or 
> "forbidden in Fortran 2023" or similar?
> 
>> +  else if (std & GFC_STD_F2023)
>> +    return _("Fortran 2023:");
>> +  else if (std & GFC_STD_F2018_DEL)
>>      return _("Fortran 2018 deleted feature:");
>>    else if (std & GFC_STD_F2018_OBS)
>>      return _("Fortran 2018 obsolescent feature:");

I skimmed over existing error messages, and since "forbidden" did
not show up and since "Not allowed" exists but not at the beginning
of a message, I found that

"Prohibited in Fortran 2023"

appeared to be a good alternative.

Not being a native speaker, I hope that someone speaks up if this
is not appropriate.  And since I do not explicitly verify that part
in the testcase, it can be changed.

>> diff --git a/gcc/fortran/libgfortran.h b/gcc/fortran/libgfortran.h
>> index bdddb317ab0..af7a170c2b1 100644
>> --- a/gcc/fortran/libgfortran.h
>> +++ b/gcc/fortran/libgfortran.h
>> @@ -19,9 +19,10 @@ along with GCC; see the file COPYING3.  If not see
>>
>>
>>  /* Flags to specify which standard/extension contains a feature.
>> -   Note that no features were obsoleted nor deleted in F2003 nor in 
>> F2023.
>> +   Note that no features were obsoleted nor deleted in F2003.
> 
> I think we can add a comment that F2023 has no deleted feature, but some 
> more stringent restrictions in f2023 forbid some previously valid code.
> 
>>     Please remember to keep those definitions in sync with
>>     gfortran.texi.  */
>> +#define GFC_STD_F2023_DEL    (1<<13)    /* Deleted in F2023.  */
>>  #define GFC_STD_F2023        (1<<12)    /* New in F2023.  */
>>  #define GFC_STD_F2018_DEL    (1<<11)    /* Deleted in F2018.  */
>>  #define GFC_STD_F2018_OBS    (1<<10)    /* Obsolescent in F2018.  */
>> @@ -41,12 +42,13 @@ along with GCC; see the file COPYING3.  If not see
>>   * are allowed with a certain -std option.  */
>>  #define GFC_STD_OPT_F95        (GFC_STD_F77 | GFC_STD_F95 | 
>> GFC_STD_F95_OBS  \
>>                  | GFC_STD_F2008_OBS | GFC_STD_F2018_OBS \
>> -                | GFC_STD_F2018_DEL)
>> +                | GFC_STD_F2018_DEL | GFC_STD_F2023_DEL)
>>  #define GFC_STD_OPT_F03        (GFC_STD_OPT_F95 | GFC_STD_F2003)
>>  #define GFC_STD_OPT_F08        (GFC_STD_OPT_F03 | GFC_STD_F2008)
>>  #define GFC_STD_OPT_F18        ((GFC_STD_OPT_F08 | GFC_STD_F2018) \
>>                  & (~GFC_STD_F2018_DEL))
> F03, F08 and F18 should have GFC_STD_F2023_DEL (and also F03 and F08 
> should have GFC_STD_F2018_DEL).

Well, these macros do an incremental bitwise-or, so the bit representing
GFC_STD_F2023_DEL is included everywhere.  I also ran the testcases with
different -std= options to check.

> OK with this fixed (and the previous comments as you wish), if Steve has 
> no more comments.
> 
> Thanks for the patch.
> 
> 

If there are no further comments, I will commit once I am able to
fully build again with --disable-bootstrap and -march=native ...

Thanks,
Harald