Re: [PATCH, v3] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
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.
Re: [PATCH, v3] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
Hi Steve, On 11/22/23 19:03, Steve Kargl wrote: On Wed, Nov 22, 2023 at 10:36:00AM +0100, Mikael Morin wrote: OK with this fixed (and the previous comments as you wish), if Steve has no more comments. No further comments. Thanks for your patients, Harald. As side note, I found John Reid's "What's new" document where it is noted that there are no new obsolescent or delete features. https://wg5-fortran.org/N2201-N2250/N2212.pdf this is good to know. There is an older version (still referring to F202x) on the wiki: https://gcc.gnu.org/wiki/GFortranStandards It would be great if someone with editing permission could update the link and point to the above. Thanks, Harald
[PATCH, testsuite, fortran] fix invalid testcases (missing MOLD argument to NULL)
Dear all,
testcases assumed_rank_8.f90 and assumed_rank_10.f90 are invalid:
NULL() is passed without MOLD to an assumed-rank dummy argument.
This is detected by NAG, but not yet by gfortran (see pr104819).
gfortran even ignores the MOLD argument; the dump-tree is identical
if MOLD is there or not.
Now these testcases are { dg-do run }. Therefore I would like to
fix these testcases, independent of the work on fixing pr104819.
Comments?
Thanks,
Harald
From cbb0c61f9d6f06667666a33da6e6ce3213a92248 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 22 Nov 2023 21:45:46 +0100
Subject: [PATCH] testsuite: fortran: fix invalid testcases (missing MOLD
argument to NULL)
The Fortran standard requires that NULL() passed to an assumed-rank
dummy argument has a MOLD argument.
gcc/testsuite/ChangeLog:
PR fortran/104819
* gfortran.dg/assumed_rank_10.f90: Add MOLD argument to NULL().
* gfortran.dg/assumed_rank_8.f90: Likewise.
---
gcc/testsuite/gfortran.dg/assumed_rank_10.f90 | 6 +++---
gcc/testsuite/gfortran.dg/assumed_rank_8.f90 | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/assumed_rank_10.f90 b/gcc/testsuite/gfortran.dg/assumed_rank_10.f90
index 6a3cc94483e..f22d43ab955 100644
--- a/gcc/testsuite/gfortran.dg/assumed_rank_10.f90
+++ b/gcc/testsuite/gfortran.dg/assumed_rank_10.f90
@@ -50,9 +50,9 @@ program test
is_present = .false.
- call fpa(null(), null()) ! No copy back
- call fpi(null(), null()) ! No copy back
- call fno(null(), null()) ! No copy back
+ call fpa(null(iip), null(jjp)) ! No copy back
+ call fpi(null(iip), null(jjp)) ! No copy back
+ call fno(null(iip), null(jjp)) ! No copy back
call fno() ! No copy back
diff --git a/gcc/testsuite/gfortran.dg/assumed_rank_8.f90 b/gcc/testsuite/gfortran.dg/assumed_rank_8.f90
index 5873296a7a5..34ff42c0be2 100644
--- a/gcc/testsuite/gfortran.dg/assumed_rank_8.f90
+++ b/gcc/testsuite/gfortran.dg/assumed_rank_8.f90
@@ -22,13 +22,13 @@ program main
call f (ii)
call f (489)
call f ()
- call f (null())
+ call f (null(kk))
call f (kk)
if (j /= 2) STOP 1
j = 0
nullify (ll)
- call g (null())
+ call g (null(ll))
call g (ll)
call g (ii)
if (j /= 1) STOP 2
--
2.35.3
Re: [PATCH, v3] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
On Wed, Nov 22, 2023 at 10:36:00AM +0100, Mikael Morin wrote: > > OK with this fixed (and the previous comments as you wish), if Steve has no > more comments. > No further comments. Thanks for your patients, Harald. As side note, I found John Reid's "What's new" document where it is noted that there are no new obsolescent or delete features. https://wg5-fortran.org/N2201-N2250/N2212.pdf -- Steve
[PATCH, v4] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
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
From 56386f4f332cf8970a424ba67678335fa6186e4c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 22 Nov 2023 20:57:59 +0100
Subject: [PATCH] Fortran: restrictions on integer arguments to SYSTEM_CLOCK
[PR112609]
Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK to
have a decimal exponent range at least as large as a default integer,
and that all integer arguments have the same kind type parameter.
gcc/fortran/ChangeLog:
PR fortran/112609
* check.cc (gfc_check_system_clock): Add checks on integer arguments
to SYSTEM_CLOCK specific to F2023.
* error.cc (notify_std_msg): Adjust to handle new features added
in F2023.
* gfortran.texi (_gfortran_set_options): Document GFC_STD_F2023_DEL,
remove obsolete option GFC_STD_F2008_TS and fix enumeration values.
* libgfortran.h (GFC_STD_F2023_DEL): Add and use in GFC_STD_OPT_F23.
* options.cc (set_default_std_flags): Add GFC_STD_F2023_DEL.
gcc/testsuite/ChangeLog:
PR fortran/112609
* gfortran.dg/system_clock_1.f90: Add option -std=f2003.
* gfortran.dg/system_clock_3.f08: Add option -std=f2008.
* gfortran.dg/system_clock_4.f90: New test.
---
gcc/fortran/check.cc | 50
gcc/fortran/error.cc | 6 ++-
gcc/fortran/gfortran.texi| 10 ++--
gcc/fortran/libgfortran.h| 7 ++-
gcc/fortran/options.cc | 6 ++-
gcc/testsuite/gfortran.dg/system_clock_1.f90 | 1 +
gcc/testsuite/gfortran.dg/system_clock_3.f08 | 1 +
gcc/testsuite/gfortran.dg/system_clock_4.f90 | 24 ++
8 files changed, 95 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/system_clock_4.
