public inbox for gcc-patches@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, v3] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
Date: Wed, 22 Nov 2023 10:36:00 +0100	[thread overview]
Message-ID: <97809d56-b3dc-42c9-85e8-6eb8bc618428@orange.fr> (raw)
In-Reply-To: <d0ac14e3-09ba-46b6-a7e1-38ab6b078fa8@gmx.de>

Le 21/11/2023 à 23:09, Harald Anlauf a écrit :
> Uhh, it happened again.  Attached a wrong patch.
> Only looked at the -v3 ...  My bad.
> 
> Sorry!
> 
> Harald
> 
> 
> On 11/21/23 22:54, Harald Anlauf wrote:
>> Hi Mikael, Steve,
>>
>> On 11/21/23 12:33, Mikael Morin wrote:
>>> 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.
>>
>> thanks for insisting on this variant.
>>
>> In my first attack at this problem, I overlooked one place in
>> libgfortran.h, which I now was able to find and adjust.
>> Now everything falls into place.
>>
>>> 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.
>>
>> As the majority agrees on this, I accept it.  The attached patch
>> now does this and fixes the testcases accordingly.
>>
>>>> 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.
>>
>> Done.
>>
>> I also fixed a few issues in the documentation in gfortran.texi .
>>
>> As I currently cannot build a full compiler (see PR112643),
>> patch V3 is not properly regtested yet, but appears to give
>> results as discussed.
>>
>> Comments?
>>
>>> Mikael
>>
>> Thanks,
>> Harald
>>
>>
> 
(...)

> 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:");

> 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).

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

Thanks for the patch.


  parent reply	other threads:[~2023-11-22  9:36 UTC|newest]

Thread overview: 17+ 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-19 20:46     ` 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 21:54           ` Harald Anlauf
2023-11-21 22:09           ` Harald Anlauf
2023-11-21 22:09             ` Harald Anlauf
2023-11-22  9:36             ` Mikael Morin [this message]
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-22 20:36                 ` Harald Anlauf
2023-11-23  9:07                 ` Mikael Morin

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=97809d56-b3dc-42c9-85e8-6eb8bc618428@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).