Hi Andre,
+ if (gfc_option.allow_std & GFC_STD_F2003)
+ gfc_error ("%qs argument of %qs intrinsic at %L must be INTEGER "
+ "or REAL or CHARACTER",
I had expected UNSIGNED in this enumeration, too.
+ gfc_current_intrinsic_arg[n]->name
Hi all,
this rather old PR reported a parsing bug, when a coarray'ed character substring
ref is to be parsed, aka CHARACTER(:) :: str[:] ... str(2:5). In this case the
parser confused the substring ref with an array-ref, because an array_spec was
present. This patch fixes this by requesting only c
Hi Tomáš,
one small nit: I would prefer to use i = -1 as the initializer for component of
the derived type, because 0 is a default generated one and that way one can
distinguish them. With that, ok for mainline and thanks for the patch.
- Andre
On Wed, 25 Sep 2024 17:20:12 +0200
Tomáš Trnka wro
Hi Thomas,
one small nit:
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index dd79a49a0c9..afab66a901f 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -637,6 +637,38 @@ int_or_real_or_char_check_f2003 (gfc_expr *e, int n)
return true;
}
+/* Check that an expression
Hi Andre,
Am 01.10.24 um 09:43 schrieb Andre Vehreschild:
Hi all,
this rather old PR reported a parsing bug, when a coarray'ed character substring
ref is to be parsed, aka CHARACTER(:) :: str[:] ... str(2:5). In this case the
parser confused the substring ref with an array-ref, because an array