public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mikael Morin <morin-mikael@orange.fr>
To: Harald Anlauf <anlauf@gmx.de>, sgk@troutmask.apl.washington.edu
Cc: fortran <fortran@gcc.gnu.org>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, v4] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
Date: Thu, 23 Nov 2023 10:07:10 +0100	[thread overview]
Message-ID: <0396c862-7a97-4ef0-b133-4849d035add1@orange.fr> (raw)
In-Reply-To: <956bd0e6-d53d-4df9-b952-f441b7e3fac4@gmx.de>

Le 22/11/2023 à 21:36, Harald Anlauf a écrit :
> 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.
> 
Ah, yes.  I confused the GFC_STD_OPT* values with the GFC_STD_* ones.

>> 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
> 
Thanks again.


      reply	other threads:[~2023-11-23  9:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-18 22:12 [PATCH] " Harald Anlauf
2023-11-19  0:04 ` Steve Kargl
2023-11-19 20:46   ` [PATCH, v2] " Harald Anlauf
2023-11-20 19:02     ` Steve Kargl
2023-11-21 11:33       ` Mikael Morin
2023-11-21 21:54         ` [PATCH, v3] " Harald Anlauf
2023-11-21 22:09           ` Harald Anlauf
2023-11-22  9:36             ` Mikael Morin
2023-11-22 18:03               ` Steve Kargl
2023-11-22 20:40                 ` Harald Anlauf
2023-11-22 20:40                   ` Harald Anlauf
2023-11-22 20:36               ` [PATCH, v4] " Harald Anlauf
2023-11-23  9:07                 ` Mikael Morin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0396c862-7a97-4ef0-b133-4849d035add1@orange.fr \
    --to=morin-mikael@orange.fr \
    --cc=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=sgk@troutmask.apl.washington.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).