Re: [Patch, fortran] PR99602 - [11 regression] runtime error: pointer actual argument not associated
Hi Paul,
I do not understand the !UNLIMITED_POLY(fsym) part of the patch.
In particular, your patch causes foo.f90 to fail by wrongly diagnosting:
Fortran runtime error: Pointer actual argument 'cptr' is not associated
I have only did some light tests – but it seems that just removing
'&& !UNLIMITED_POLY(fsym)' seems to be enough. (But I did not run
the testsuite.)
Hence:
- Please include the attached testcases or some variants of them.
- Check that removing !UNLIMITED_POLY does not cause any regressions
If that works: OK for mainline
Thanks for looking into this issue and working on the patches.
Tobias
On 26.03.21 07:58, Paul Richard Thomas via Fortran wrote:
This patch is straightforward but the isolation of the problem was rather
less so. Many thanks to Juergen for testcase reduction.
Regtested on FC33/x86_64 - OK for master?
Paul
Fortran: Fix problem with runtime pointer chack [PR99602].
2021-03-26 Paul Thomas
gcc/fortran/ChangeLog
PR fortran/99602
* trans-expr.c (gfc_conv_procedure_call): Use the _data attrs
for class expressions and detect proc pointer evaluations by
the non-null actual argument list.
gcc/testsuite/ChangeLog
PR fortran/99602
* gfortran.dg/pr99602.f90: New test.
* gfortran.dg/pr99602a.f90: New test.
* gfortran.dg/pr99602b.f90: New test.
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
! { dg-do compile }
! { dg-options "-fcheck=pointer -fdump-tree-original" }
!
! PR fortran/99602
!
module m
implicit none
contains
subroutine wr(y)
class(*) :: y
stop 1
end
end module m
use m
implicit none
integer, pointer :: iptr
class(*), pointer :: cptr
nullify (cptr, iptr)
call wr(iptr)
call wr(cptr)
end
! { dg-final { scan-tree-dump-times "_gfortran_runtime_error_at" "original" 2 } }
! { dg-final { scan-tree-dump-times "Pointer actual argument 'cptr'" "original" 1 } }
! { dg-final { scan-tree-dump-times "Pointer actual argument 'iptr'" "original" 1 } }
! { dg-do compile }
! { dg-options "-fcheck=pointer -fdump-tree-original" }
!
! PR fortran/99602
!
module m
implicit none
contains
subroutine wr(y)
class(*), pointer :: y
if (associated (y)) stop 1
end
end module m
use m
implicit none
class(*), pointer :: cptr
nullify (cptr)
call wr(cptr)
end
! { dg-final { scan-tree-dump-not "_gfortran_runtime_error_at" "original" } }
! { dg-final { scan-tree-dump-not "Pointer actual argument" "original" } }
Re: [PATCH 1/2] openacc: Fix lowering for derived-type mappings through array elements
Hi!
On 2021-03-25T12:54:31+0100, I wrote:
> On 2021-02-12T07:46:48-0800, Julian Brown wrote:
>> --- /dev/null
>> +++ b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
>> @@ -0,0 +1,109 @@
>> +[...]
>> +!$acc serial present(var3%t2(5)%t1%arr1)
>> +var3%t2(5)%t1%arr1(:,:) = 6
>> +!$acc end serial
>> +[...]
>
> I've pushed "'libgomp.oacc-fortran/derivedtypes-arrays-1.f90' OpenACC
> 'serial' construct diagnostic for nvptx offloading" to master branch in
> commit 8bafce1be11a301c2421483736c634b8bf330e69, and cherry-picked into
> devel/omp/gcc-10 branch in commit
> c89b23b73edeeb7e3d8cbad278e505c2d6d770c4, see attached.
I'd pushed the wrong thing to devel/omp/gcc-10 branch, so I've now pushed
"Adjust 'libgomp.oacc-fortran/derivedtypes-arrays-1.f90' for og10" in
commit 4777cf66403e311ff3f00bf3d9a60bd5b546f5ed, see attached.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
>From 4777cf66403e311ff3f00bf3d9a60bd5b546f5ed Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Fri, 26 Mar 2021 15:19:49 +0100
Subject: [PATCH] Adjust 'libgomp.oacc-fortran/derivedtypes-arrays-1.f90' for
og10
This is a fix-up for og10 commit c89b23b73edeeb7e3d8cbad278e505c2d6d770c4
"'libgomp.oacc-fortran/derivedtypes-arrays-1.f90' OpenACC 'serial' construct
diagnostic for nvptx offloading".
We're missing in og10 a few patches related to diagnostics location
tracking/checking, both compiler-side and testsuite-side.
libgomp/
* testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90: Adjust
for og10.
---
libgomp/ChangeLog.omp| 5 +
.../testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90 | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp
index b0af9c205a38..f131c2c79b7e 100644
--- a/libgomp/ChangeLog.omp
+++ b/libgomp/ChangeLog.omp
@@ -1,3 +1,8 @@
+2021-03-26 Thomas Schwinge
+
+ * testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90: Adjust
+ for og10.
+
2021-03-25 Kwok Cheung Yeung
Backport from mainline
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90 b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
index 7bca2df66285..0208e07ea937 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
+++ b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
@@ -88,7 +88,7 @@ end do
!$acc data copyin(var3%t2(5)%t1%arr1)
!$acc serial present(var3%t2(5)%t1%arr1)
-! { dg-warning "using vector_length \\(32\\), ignoring 1" "" { target openacc_nvidia_accel_selected } .-1 }
+! { dg-warning "using vector_length \\(32\\), ignoring 1" "" { target openacc_nvidia_accel_selected } 92 }
var3%t2(5)%t1%arr1(:,:) = 6
!$acc end serial
--
2.30.2
[Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test
This patch comes in two versions: submit.diff with Change.Logs or
submit2.diff with Change2.Logs.
The first fixes the problem by changing array temporaries from class
expressions into class temporaries. This permits the use of
gfc_get_class_from_expr to obtain the vptr for these temporaries and all
the good things that come with that when handling dynamic types. The second
part of the fix is to use the array element length from the class
descriptor, when reallocating on assignment. This is needed because the
vptr is being set too early. I will set about trying to track down why this
is happening and fix it after release.
The second version does the same as the first but puts in place a load of
tidying up that is permitted by the fix to class array temporaries.
I couldn't readily see how to prepare a testcase - ideas?
Both regtest on FC33/x86_64. The first was tested by Dominique (see the
PR). OK for master?
Regards
Paul
Change.Logs
Description: Binary data
Change2.Logs
Description: Binary data
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index c6725659093..8aa56d1ccb9 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -1403,9 +1403,6 @@ gfc_trans_create_temp_array (stmtblock_t * pre, stmtblock_t * post, gfc_ss * ss,
desc = gfc_create_var (type, "atmp");
GFC_DECL_PACKED_ARRAY (desc) = 1;
- info->descriptor = desc;
- size = gfc_index_one_node;
-
/* Emit a DECL_EXPR for the variable sized array type in
GFC_TYPE_ARRAY_DATAPTR_TYPE so the gimplification of its type
sizes works correctly. */
@@ -1416,9 +1413,40 @@ gfc_trans_create_temp_array (stmtblock_t * pre, stmtblock_t * post, gfc_ss * ss,
gfc_add_expr_to_block (pre, build1 (DECL_EXPR,
arraytype, TYPE_NAME (arraytype)));
- /* Fill in the array dtype. */
- tmp = gfc_conv_descriptor_dtype (desc);
- gfc_add_modify (pre, tmp, gfc_get_dtype (TREE_TYPE (desc)));
+ if (class_expr != NULL_TREE)
+{
+ tree class_data;
+ tree dtype;
+
+ /* Create a class temporary. */
+ tmp = gfc_create_var (TREE_TYPE (class_expr), "ctmp");
+ gfc_add_modify (pre, tmp, class_expr);
+
+ /* Assign the new descriptor to the _data field. This allows the
+ vptr _copy to be used for scalarized assignment since the class
+ temporary can be found from the descriptor. */
+ class_data = gfc_class_data_get (tmp);
+ tmp = fold_build1_loc (input_location, VIEW_CONVERT_EXPR,
+ TREE_TYPE (desc), desc);
+ gfc_add_modify (pre, class_data, tmp);
+
+ /* Take the dtype from the class expression. */
+ dtype = gfc_conv_descriptor_dtype (gfc_class_data_get (class_expr));
+ tmp = gfc_conv_descriptor_dtype (class_data);
+ gfc_add_modify (pre, tmp, dtype);
+
+ /* Point desc to the class _data field. */
+ desc = class_data;
+}
+ else
+{
+ /* Fill in the array dtype. */
+ tmp = gfc_conv_descriptor_dtype (desc);
+ gfc_add_modify (pre, tmp, gfc_get_dtype (TREE_TYPE (desc)));
+}
+
+ info->descriptor = desc;
+ size = gfc_index_one_node;
/*
Fill in the bounds and stride. This is a packed array, so:
@@ -3438,6 +3466,12 @@ build_class_array_ref (gfc_se *se, tree base, tree index)
&& GFC_DECL_SAVED_DESCRIPTOR (se->expr)
&& GFC_CLASS_TYPE_P (TREE_TYPE (GFC_DECL_SAVED_DESCRIPTOR (se->expr
decl = se->expr;
+ else if (!VAR_P (base) && gfc_get_class_from_expr (base))
+{
+ decl = gfc_get_class_from_expr (base);
+ se->class_vptr = gfc_evaluate_now (gfc_class_vptr_get (decl), &se->pre);
+ goto class_found;
+}
else
{
if (expr == NULL
@@ -3530,6 +3564,7 @@ build_class_array_ref (gfc_se *se, tree base, tree index)
if (POINTER_TYPE_P (TREE_TYPE (decl)))
decl = build_fold_indirect_ref_loc (input_location, decl);
+class_found:
if (!GFC_CLASS_TYPE_P (TREE_TYPE (decl)))
return false;
@@ -10274,23 +10309,10 @@ gfc_alloc_allocatable_for_assignment (gfc_loopinfo *loop,
}
else if (expr1->ts.type == BT_CLASS)
{
- tmp = expr1->rank ? gfc_get_class_from_expr (desc) : NULL_TREE;
- if (tmp == NULL_TREE)
- tmp = gfc_get_class_from_gfc_expr (expr1);
-
- if (tmp != NULL_TREE)
- {
- tmp2 = gfc_class_vptr_get (tmp);
- cond = fold_build2_loc (input_location, NE_EXPR,
- logical_type_node, tmp2,
- build_int_cst (TREE_TYPE (tmp2), 0));
- elemsize1 = gfc_class_vtab_size_get (tmp);
- elemsize1 = fold_build3_loc (input_location, COND_EXPR,
- gfc_array_index_type, cond,
- elemsize1, gfc_index_zero_node);
- }
- else
- elemsize1 = TYPE_SIZE_UNIT (gfc_typenode_for_spec (&CLASS_DATA (expr1)->ts));
+ /* Unfortunately, the lhs vptr is set too early in many cases.
+ Play it safe by using the descriptor element length. */
+ tmp = gfc_conv_descriptor_elem_len (desc);
+ elemsize1 = fold_convert (gfc_array_index_type, tmp);
}
else
elemsize1 = NULL_TREE;
@@ -10
off-by-one buffer overflow patch
This patch fixes an off-by-one buffer overflow issue.
Please commit.
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 8a96243e80d..3d449ae17fe 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -124,8 +124,10 @@ gfc_basic_typename (bt type)
const char *
gfc_typename (gfc_typespec *ts, bool for_hash)
{
- static char buffer1[GFC_MAX_SYMBOL_LEN + 7]; /* 7 for "TYPE()" + '\0'. */
- static char buffer2[GFC_MAX_SYMBOL_LEN + 7];
+ /* Need to add sufficient padding for "TYPE()" + '\0', "UNION()" + '\0',
+ or "CLASS()" + '\0'. */
+ static char buffer1[GFC_MAX_SYMBOL_LEN + 8];
+ static char buffer2[GFC_MAX_SYMBOL_LEN + 8];
static int flag = 0;
char *buffer;
gfc_typespec *ts1;
--
Steve
Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test
Hi Paul, I have your first patch in my working tree for some time. It works as expected without breaking anything in my own tests. I couldn't readily see how to prepare a testcase - ideas? I think the testcase is already in the test suite. Note the problem also affects GCC10 with a new release around the corner. Thanks for your work. Dominique
Re: off-by-one buffer overflow patch
I have proposed a similar patch in pr95998. I cannot commit to git!-( Thanks Dominique
Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test
Hi Dominique, What I meant was a test that would confirm the fix on all targets. BTW thanks for testing the patch! A Paul On Fri, 26 Mar 2021 at 17:29, wrote: > Hi Paul, > > I have your first patch in my working tree for some time. It works as > expected without breaking anything in my own tests. > > > I couldn't readily see how to prepare a testcase - ideas? > > I think the testcase is already in the test suite. > > Note the problem also affects GCC10 with a new release around the > corner. > > Thanks for your work. > > Dominique > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: off-by-one buffer overflow patch
On 3/26/21 10:38 AM, dhumieres.dominique--- via Fortran wrote: I have proposed a similar patch in pr95998. I cannot commit to git!-( Thanks Dominique I do not see a patch in 95998. Do you need help to do a commit? Jerry
