Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
Le 28/01/2023 à 03:47, Jerry D a écrit : It is not apparent to me that the testsuite/ChangeLog was updated. Maybe there is a time delay on that? Yes, it's done daily as part of the "daily bump" commit. You can see it in the git log: $ git log -- gcc/testsuite/ChangeLog commit f457a62e63a86d5e5342eda16538a26355199856 Author: GCC Administrator Date: Tue Jan 17 00:18:06 2023 + Daily bump. commit 5013c3bb3ead9c27adb90152115ca1d606cbf2dc Author: GCC Administrator Date: Sun Jan 15 00:17:49 2023 + Daily bump. commit ecd637e9761485437498f311ddf09af5286d6d0f Author: GCC Administrator Date: Fri Jan 13 00:17:18 2023 + Daily bump.
[PATCH] Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]
Dear all,
a USE associated symbol shall not appear in a COMMON block
(F2018:C8121) and needs to be diagnosed. The patch is
fairly obvious.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As the PR is marked as a 10/11/12/13 regression,
I plan to backport as appropriate.
Thanks,
Harald
From 3f0e4b23038ade2cd14d93b0705af93848ee45c2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 28 Jan 2023 17:59:23 +0100
Subject: [PATCH] Fortran: diagnose USE associated symbols in COMMON blocks
[PR108453]
gcc/fortran/ChangeLog:
PR fortran/108453
* match.cc (gfc_match_common): A USE associated name shall not appear
in a COMMON block (F2018:C8121).
gcc/testsuite/ChangeLog:
PR fortran/108453
* gfortran.dg/common_27.f90: New test.
---
gcc/fortran/match.cc| 10 ++
gcc/testsuite/gfortran.dg/common_27.f90 | 14 ++
2 files changed, 24 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/common_27.f90
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 5e933c12931..5eb6d0e1c1d 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5345,6 +5345,16 @@ gfc_match_common (void)
goto cleanup;
}
+ /* F2018:R874: common-block-object is variable-name [ (array-spec) ]
+ F2018:C8121: A variable-name shall not be a name made accessible
+ by use association. */
+ if (sym->attr.use_assoc)
+ {
+ gfc_error ("Symbol %qs at %C is USE associated from module %qs "
+ "and cannot occur in COMMON", sym->name, sym->module);
+ goto cleanup;
+ }
+
/* Deal with an optional array specification after the
symbol name. */
m = gfc_match_array_spec (&as, true, true);
diff --git a/gcc/testsuite/gfortran.dg/common_27.f90 b/gcc/testsuite/gfortran.dg/common_27.f90
new file mode 100644
index 000..dcde5de2bd2
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/common_27.f90
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! PR fortran/108453 - a use associated variable cannot occur in COMMON
+! Contributed by G.Steinmetz
+
+module m
+ type t
+ end type
+ real :: r
+end
+program p
+ use m, only: t, r
+ common t ! { dg-error "USE associated from module" }
+ common /cm/ r ! { dg-error "USE associated from module" }
+end
--
2.35.3
*PING* [PATCH] Fortran: fix ICE in compare_bound_int [PR108527]
Early gentle ping. Am 24.01.23 um 22:48 schrieb Harald Anlauf via Gcc-patches: Dear all, when checking expressions for array sections, we need to ensure that these use only type INTEGER. However, it does not make sense to generate an internal error when encountering wrong types, but rather take the ordinary route of error recovery. The initial fix was provided by Steve. While working on the same PR, I found that the comments related to the logic needed a minor adjustment, and the logic could be cleaned up to actually match the intended comment. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
Re: [PATCH] Fortran: fix ICE in compare_bound_int [PR108527]
On 1/24/23 1:48 PM, Harald Anlauf via Fortran wrote: Dear all, when checking expressions for array sections, we need to ensure that these use only type INTEGER. However, it does not make sense to generate an internal error when encountering wrong types, but rather take the ordinary route of error recovery. The initial fix was provided by Steve. While working on the same PR, I found that the comments related to the logic needed a minor adjustment, and the logic could be cleaned up to actually match the intended comment. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Harald, this looks OK to me. Good for Mainline.
Re: [PATCH] Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]
On Sat, Jan 28, 2023 at 06:07:50PM +0100, Harald Anlauf via Fortran wrote: > > a USE associated symbol shall not appear in a COMMON block > (F2018:C8121) and needs to be diagnosed. The patch is > fairly obvious. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > As the PR is marked as a 10/11/12/13 regression, > I plan to backport as appropriate. > Yes. Backports are fine with a clean regression test. Thanks for the patch and your continued attack on bugzilla issues. -- Steve
Re: [PATCH] Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]
On 1/28/23 9:07 AM, Harald Anlauf via Fortran wrote: Dear all, a USE associated symbol shall not appear in a COMMON block (F2018:C8121) and needs to be diagnosed. The patch is fairly obvious. Regtested on x86_64-pc-linux-gnu. OK for mainline? As the PR is marked as a 10/11/12/13 regression, I plan to backport as appropriate. Thanks, Harald Yes, this is OK for all. Thanks Jerry
[patch, fortran] PR103506 [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c
Attached patch fixes this problem by allowing the namespace pointer to
be set correctly regardless of error condition.
Regression tested on x86_64_linux_gnu.
OK for trunk and backports?
Regards,
Jerry
Author: Jerry DeLisle
Date: Sat Jan 28 20:00:34 2023 -0800
ICE in gfc_free_namespace. ice-on-invalid.
PR fortran/103506
gcc/fortran/ChangeLog:
* parse.cc (parse_module): Remove use of a bool error value
that prevented proper setting of the namespace pointer.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr103506_1.f90: New test.diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 0fb19cc9f0f..039e7e7da53 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -6502,7 +6502,6 @@ parse_module (void)
{
gfc_statement st;
gfc_gsymbol *s;
- bool error;
s = gfc_get_gsymbol (gfc_new_block->name, false);
if (s->defined || (s->type != GSYM_UNKNOWN && s->type != GSYM_MODULE))
@@ -6525,7 +6524,6 @@ parse_module (void)
st = parse_spec (ST_NONE);
- error = false;
loop:
switch (st)
{
@@ -6544,16 +6542,11 @@ loop:
default:
gfc_error ("Unexpected %s statement in MODULE at %C",
gfc_ascii_statement (st));
-
- error = true;
reject_statement ();
st = next_statement ();
goto loop;
}
-
- /* Make sure not to free the namespace twice on error. */
- if (!error)
-s->ns = gfc_current_ns;
+ s->ns = gfc_current_ns;
}
diff --git a/gcc/testsuite/gfortran.dg/pr103506_1.f90 b/gcc/testsuite/gfortran.dg/pr103506_1.f90
new file mode 100644
index 000..3f57809e099
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103506_1.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR103506 ICE in gfc_free_namespace. ice-on-invalid
+! Test case from the PR.
+module m ! { dg-error "is already being used as a MODULE" }
+stop ! { dg-error "Unexpected STOP statement in MODULE" }
+end
+program p
+call m ! { dg-error "is already being used as a MODULE" }
+end
