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
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
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]
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
From 8fbffe1bd1faaff456abf6730ac2e2b3c370bc72 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 21 Nov 2023 22:29:19 +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| 8 ++--
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(+), 11 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/system_clock_4.f90
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 6c45e6542f0..3b1a0f9f4f4 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6774,6 +6774,8 @@ bool
gfc_check_system_clock (gfc_expr *count, gfc_expr *count_rate,
gfc_expr *count_max)
{
+ int first_int_kind = -1;
+
if (count != NULL)
{
if (!scalar_check (count, 0))
@@ -6788,8 +6790,17 @@ gfc_check_system_clock (gfc_expr *count, gfc_expr *count_rate,
&count->where))
return false;
+ if (count->ts.kind < gfc_default_integer_kind
+ && !gfc_notify_std (GFC_STD_F2023_DEL,
+ "COUNT argument to SYSTEM_CLOCK at %L "
+ "with kind smaller than default integer",
+ &count->where))
+ return false;
+
if (!variable_check (count, 0, false))
return false;
+
+ first_int_kind = count->ts.kind;
}
if (count_rate != NULL)
@@ -6816,6 +6827,16 @@ gfc_check_system_clock (gfc_expr *count, gfc_expr *count_rate,
"SYSTEM_CLOCK at %L has non-default kind",
&count_rate->where))
return false;
+
+ if (count_rate->ts.kind < gfc_default_integer_kind
+ && !gfc_notify_std (GFC_STD_F2023_DEL,
+ "COUNT_RATE argument to SYSTEM_CLOCK at %L "
+ "with kind smaller than default integer",
+ &count_rate->where))
+ return false;
+
+ if (first_int_kind < 0)
+ first_int_kind = count_rate->ts.kind;
}
}
@@ -6836,6 +6857,35 @@ gfc_check_system_clock (gfc_expr *count, gfc_expr *count_rate,
if (!variable_check (count_max, 2, false))
return false;
+
+ if (count_max->ts.kind < gfc_default_integer_kind
+ && !gfc_notify_std (GFC_STD_F2023_DEL,
+ "COUNT_MAX argument to SYSTEM_CLOCK at %L "
+ "with kind smaller than default integer",
+ &count_max->where))
+ return false;
+
+ if (first_int_kind < 0)
+ first_int_kind = count_max->ts.kind;
+}
+
+ if (first_int_kind > 0)
+{
+ if (count_rate
+ && count_rate->t
[PATCH, v3] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
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/check.cc b/gcc/fortran/check.cc
index 6c45e6542f0..e5cf6a495b5 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -4357,6 +4357,9 @@ gfc_check_null (gfc_expr *mold)
if (mold == NULL)
return true;
+ if (mold->expr_type == EXPR_NULL)
+return true;
+
if (!variable_check (mold, 0, true))
return false;
@@ -5189,7 +5192,7 @@ is_c_interoperable (gfc_expr *expr, const char **msg, bool c_loc, bool c_f_ptr)
{
*msg = NULL;
- if (expr->expr_type == EXPR_NULL)
+ if (expr->expr_type == EXPR_NULL && expr->ts.type == BT_UNKNOWN)
{
*msg = "NULL() is not interoperable";
return false;
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index fc4fe662eab..641edf9d059 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2387,6 +2387,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
gfc_component *ppc;
bool codimension = false;
gfc_array_spec *formal_as;
+ bool pointer_arg, allocatable_arg;
+ bool pre2018 = ((gfc_option.allow_std & GFC_STD_F2018) == 0);
/* If the formal arg has type BT_VOID, it's to one of the iso_c_binding
procs c_f_pointer or c_f_procpointer, and we need to accept most
@@ -2564,13 +2566,20 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
}
}
+ pointer_arg = gfc_expr_attr (actual).pointer;
+ allocatable_arg = gfc_expr_attr (actual).allocatable;
+
/* F08: 12.5.2.5 Allocatable and pointer dummy variables. However, this
is necessary also for F03, so retain error for both.
+ F2018:15.5.2.5 relaxes this constraint to same attributes.
NOTE: Other type/kind errors pre-empt this error. Since they are F03
compatible, no attempt has been made to channel to this one. */
if (UNLIMITED_POLY (formal) && !UNLIMITED_POLY (actual)
&& (CLASS_DATA (formal)->attr.allocatable
- ||CLASS_DATA (formal)->attr.class_pointer))
+ || CLASS_DATA (formal)->attr.class_pointer)
+ && (pre2018
+ || (allocatable_arg && CLASS_DATA (formal)->attr.allocatable)
+ || (pointer_arg && CLASS_DATA (formal)->attr.class_pointer)))
{
if (where)
gfc_error ("Actual argument to %qs at %L must be unlimited "
@@ -2710,7 +2719,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
rank_check = where != NULL && !is_elemental && formal_as
&& (formal_as->type == AS_ASSUMED_SHAPE
|| formal_as->type == AS_DEFERRED)
-&& actual->expr_type != EXPR_NULL;
+&& !(actual->expr_type == EXPR_NULL
+ && actual->ts.type == BT_UNKNOWN);
/* Skip rank checks for NO_ARG_CHECK. */
if (formal->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK))
@@ -3184,8 +3194,10 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
gfc_array_ref *actual_arr_ref;
gfc_array_spec *fas, *aas;
bool pointer_dummy, pointer_arg, allocatable_arg;
+ bool procptr_dummy, optional_dummy, allocatable_dummy;
bool ok = true;
+ bool pre2018 = ((gfc_option.allow_std & GFC_STD_F2018) == 0);
actual = *ap;
@@ -3296,15 +3308,66 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
&& a->expr->ts.type != BT_ASSUMED)
gfc_find_vtab (&a->expr->ts);
+ /* Checks for NULL() actual arguments without MOLD. */
+ if (a->expr->expr_type == EXPR_NULL && a->expr->ts.type == BT_UNKNOWN)
+ {
+ /* Interp J3/22-146:
+ "If the context of the reference to NULL is an
+ corresponding to an dummy argument, MOLD shall be
+ present." */
+ fas = (f->sym->ts.type == BT_CLASS && CLASS_DATA (f->sym)
+ ? CLASS_DATA (f->sym)->as
+ : f->sym->as);
+ if (fas && fas->type == AS_ASSUMED_RANK)
+ {
+ gfc_error ("Intrinsic % without % argument "
+ "at %L passed to assumed-rank dummy %qs",
+ &a->expr->
