[PATCH, committed] Fortran: error recovery in frontend optimization [PR103715]
Dear all,
I've committed the attached simple & obvious patch for an ICE due to
an invalid read in frontend optimization after regtesting and an OK
by Jerry in the PR.
Pushed: https://gcc.gnu.org/g:3be2b8f475f22c531d6cef1b041c0573b3ea5133
As this PR is marked as a regression, I plan to backport to open
branches.
Thanks,
Harald
From 3be2b8f475f22c531d6cef1b041c0573b3ea5133 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 18 Mar 2024 19:36:59 +0100
Subject: [PATCH] Fortran: error recovery in frontend optimization [PR103715]
gcc/fortran/ChangeLog:
PR fortran/103715
* frontend-passes.cc (check_externals_expr): Prevent invalid read
in case of mismatch of external subroutine with function.
gcc/testsuite/ChangeLog:
PR fortran/103715
* gfortran.dg/pr103715.f90: New test.
---
gcc/fortran/frontend-passes.cc | 3 +++
gcc/testsuite/gfortran.dg/pr103715.f90 | 12
2 files changed, 15 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr103715.f90
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 06dfa1a3232..3c06018fdbb 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-passes.cc
@@ -5807,6 +5807,9 @@ check_externals_expr (gfc_expr **ep, int *walk_subtrees ATTRIBUTE_UNUSED,
if (e->expr_type != EXPR_FUNCTION)
return 0;
+ if (e->symtree && e->symtree->n.sym->attr.subroutine)
+return 0;
+
sym = e->value.function.esym;
if (sym == NULL)
return 0;
diff --git a/gcc/testsuite/gfortran.dg/pr103715.f90 b/gcc/testsuite/gfortran.dg/pr103715.f90
new file mode 100644
index 000..72c5a31fb21
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103715.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/103715 - ICE in gfc_find_gsymbol
+!
+! valgrind did report an invalid read in check_externals_procedure
+
+program p
+ select type (y => g()) ! { dg-error "Selector shall be polymorphic" }
+ end select
+ call g()
+end
+
+! { dg-prune-output "already being used as a FUNCTION" }
--
2.35.3
Re: [PATCH, v2] Fortran: fix for absent array argument passed to optional dummy [PR101135]
Le 17/03/2024 à 23:10, Harald Anlauf a écrit : Hi Mikael, On 3/17/24 22:04, Mikael Morin wrote: diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index 3673fa40720..a7717a8107e 100644 --- a/gcc/fortran/trans-array.cc +++ b/gcc/fortran/trans-array.cc @@ -7526,6 +7526,17 @@ gfc_get_dataptr_offset (stmtblock_t *block, tree parm, tree desc, tree offset, /* Set the target data pointer. */ offset = gfc_build_addr_expr (gfc_array_dataptr_type (desc), tmp); + + /* Check for optional dummy argument being present. Arguments of BIND(C) + procedures are excepted here since they are handled differently. */ + if (expr->expr_type == EXPR_VARIABLE + && expr->symtree->n.sym->attr.dummy + && expr->symtree->n.sym->attr.optional + && !is_CFI_desc (NULL, expr)) I think the condition could additionally check the lack of subreferences. But it's maybe not worth the trouble, and the patch is conservatively correct as is, so OK. I have thought about the conditions here for some time and did not find better ones. They need to be broad enough to catch the case in gfortran.dg/missing_optional_dummy_6a.f90 that (according to the tree-dump) was not properly handled previously and would have triggered ubsan at some point in the future when someone tried to change that testcase from currently dg-do compile to dg-do run... No problem, as said it is conservatively correct. (After the patch it would pass, but I didn't dare to change the dg-do). Did it include cases not covered by the new testcase (which was quite complete already)? I have pushed the patch as-is, but feel free to post testcases not covered (or improperly covered) to narrow this down further... The case I had in mind would only be a missed optimization, and probably not that important, so let's move on.
Re: [PATCH, OpenACC 2.7] struct/array reductions for Fortran
Hi Chung-Lin!
Thanks for your work here, which I'm beginning to look into (prerequisite
"[PATCH, OpenACC 2.7] Implement reductions for arrays and structs",
first, of course); it'll take me some time.
In non-offloading testing, I noticed for x86_64-pc-linux-gnu '-m32':
+PASS: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O0 (test for excess errors)
+PASS: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O0 execution test
+PASS: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O1 (test for excess errors)
+FAIL: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O1 execution test
+PASS: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors)
+FAIL: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O2 execution test
+PASS: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (test for excess errors)
+FAIL: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
+PASS: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O3 -g (test for excess errors)
+FAIL: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -O3 -g execution test
+PASS: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -Os (test for excess errors)
+FAIL: libgomp.oacc-fortran/reduction-13.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable -Os execution test
With optimizations enabled, it runs into 'STOP 4'.
Per '-Wextra':
[...]/libgomp.oacc-fortran/reduction-13.f90:40:6: Warning: Inequality
comparison for REAL(4) at (1) [-Wcompare-reals]
[...]/libgomp.oacc-fortran/reduction-13.f90:63:6: Warning: Inequality
comparison for REAL(4) at (1) [-Wcompare-reals]
[...]/libgomp.oacc-fortran/reduction-13.f90:64:6: Warning: Inequality
comparison for REAL(8) at (1) [-Wcompare-reals]
Do we need to allow for some epsilon (generally in such test cases), or
is there another problem?
For reference:
On 2024-02-08T22:47:13+0800, Chung-Lin Tang wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/reduction-13.f90
> @@ -0,0 +1,66 @@
> +! { dg-do run }
> +
> +! record type reductions
> +
> +program reduction_13
> + implicit none
> +
> + type t1
> + integer :: i
> + real :: r
> + end type t1
> +
> + type t2
> + real :: r
> + integer :: i
> + double precision :: d
> + end type t2
> +
> + integer, parameter :: n = 10, ng = 8, nw = 4, vl = 32
> + integer :: i
> + type(t1) :: v1, a1
> + type (t2) :: v2, a2
> +
> + v1%i = 0
> + v1%r = 0
> + !$acc parallel num_gangs(ng) num_workers(nw) vector_length(vl) copy(v1)
> + !$acc loop reduction (+:v1)
> + do i = 1, n
> + v1%i = v1%i + 1
> + v1%r = v1%r + 2
> + end do
> + !$acc end parallel
> + a1%i = 0
> + a1%r = 0
> + do i = 1, n
> + a1%i = a1%i + 1
> + a1%r = a1%r + 2
> + end do
> + if (v1%i .ne. a1%i) STOP 1
> + if (v1%r .ne. a1%r) STOP 2
> +
> + v2%i = 1
> + v2%r = 1
> + v2%d = 1
> + !$acc parallel num_gangs(ng) num_workers(nw) vector_length(vl) copy(v2)
> + !$acc loop reduction (*:v2)
> + do i = 1, n
> + v2%i = v2%i * 2
> + v2%r = v2%r * 1.1
> + v2%d = v2%d * 1.3
> + end do
> + !$acc end parallel
> + a2%i = 1
> + a2%r = 1
> + a2%d = 1
> + do i = 1, n
> + a2%i = a2%i * 2
> + a2%r = a2%r * 1.1
> + a2%d = a2%d * 1.3
> + end do
> +
> + if (v2%i .ne. a2%i) STOP 3
> + if (v2%r .ne. a2%r) STOP 4
> + if (v2%d .ne. a2%d) STOP 5
> +
> +end program reduction_13
Grüße
Thomas
