[Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]
The problem is that inside the main program,
y = f(z)
where the the result of z is
type(t) :: z(size(x%a))
and 'x' is a dummy argument.
'x' looses the attr.dummy in gfc_add_interface_mapping
and this leads to an additional indirect ref in
gfc_maybe_dereference_var - but after the first indirect
ref, TREE_TYPE is alread a RECORD_TYPE ...
The simple fix is to simply punt when the argument
is not a pointer or reference.
This patch additionally fixes a comment in
conv_parent_component_references.
Those parts are obvious. The only potentially risky
change is the comparison change from a name-wise comparison
to a pointer-based comparison. I think it is fine and the
testsuite did not find any issue, but you prefer, I can
also exclude it.
OK for mainline? How about GCC 10/11 backports?
(I think leaving out the last change, it should be very safe to do.)
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Fortran: Fix gfc_maybe_dereference_var [PR104430]
PR fortran/104430
gcc/fortran/ChangeLog:
* trans-expr.cc (conv_parent_component_references): Fix comment;
simplify comparison.
(gfc_maybe_dereference_var): Avoid derefereing a nonpointer
gcc/testsuite/ChangeLog:
* gfortran.dg/class_result_10.f90: New test.
gcc/fortran/trans-expr.cc | 6 --
gcc/testsuite/gfortran.dg/class_result_10.f90 | 25 +
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index eb6a78c3a62..e441952818b 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -2805,9 +2805,9 @@ conv_parent_component_references (gfc_se * se, gfc_ref * ref)
dt = ref->u.c.sym;
c = ref->u.c.component;
- /* Return if the component is in the parent type. */
+ /* Return if the component is in this type, i.e. not in the parent type. */
for (cmp = dt->components; cmp; cmp = cmp->next)
-if (strcmp (c->name, cmp->name) == 0)
+if (c == cmp)
return;
/* Build a gfc_ref to recursively call gfc_conv_component_ref. */
@@ -2867,6 +2867,8 @@ tree
gfc_maybe_dereference_var (gfc_symbol *sym, tree var, bool descriptor_only_p,
bool is_classarray)
{
+ if (!POINTER_TYPE_P (TREE_TYPE (var)))
+return var;
if (is_CFI_desc (sym, NULL))
return build_fold_indirect_ref_loc (input_location, var);
diff --git a/gcc/testsuite/gfortran.dg/class_result_10.f90 b/gcc/testsuite/gfortran.dg/class_result_10.f90
new file mode 100644
index 000..acd9a73ebda
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_result_10.f90
@@ -0,0 +1,25 @@
+! { dg-do run}
+!
+! PR fortran/104430
+!
+! Contributed by G. Steinmetz
+
+module m
+ type t
+ integer :: a
+ end type
+contains
+ function f(x) result(z)
+ class(t) :: x(:)
+ type(t) :: z(size(x%a))
+ z%a = 42
+ end
+end
+program p
+ use m
+ class(t), allocatable :: y(:), z(:)
+ allocate (y(32))
+ z = f(y)
+ if (size(z) /= 32) stop 1
+ if (any (z%a /= 42)) stop 2
+end
[Patch] Fortran: Fix gfc_conv_gfc_desc_to_cfi_desc with NULL [PR104126]
Pre-remark: Related NULL, there some accepts-invalid issues, not addressed in
this
patch. See https://gcc.gnu.org/PR104819
This patch fixes an ICE (12 regression) with NULL() that has no MOLD argument.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Fortran: Fix gfc_conv_gfc_desc_to_cfi_desc with NULL [PR104126]
PR fortran/104126
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_gfc_desc_to_cfi_desc): Handle NULL
without MOLD.
gcc/testsuite/ChangeLog:
* gfortran.dg/null_actual_2.f90: New test.
gcc/fortran/trans-expr.cc | 13 +
gcc/testsuite/gfortran.dg/null_actual_2.f90 | 16
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index eb6a78c3a62..e8a78ccf4e1 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -5608,8 +5608,11 @@ gfc_conv_gfc_desc_to_cfi_desc (gfc_se *parmse, gfc_expr *e, gfc_symbol *fsym)
itype = (e->ts.u.derived->intmod_sym_id == ISOCBINDING_FUNPTR
? CFI_type_cfunptr : CFI_type_cptr);
else
-switch (e->ts.type)
- {
+{
+ if (e->expr_type == EXPR_NULL && e->ts.type == BT_UNKNOWN)
+ e->ts = fsym->ts;
+ switch (e->ts.type)
+ {
case BT_INTEGER:
case BT_LOGICAL:
case BT_REAL:
@@ -5647,7 +5650,8 @@ gfc_conv_gfc_desc_to_cfi_desc (gfc_se *parmse, gfc_expr *e, gfc_symbol *fsym)
case BT_UNKNOWN:
// FIXME: Really unreachable? Or reachable for type(*) ? If so, CFI_type_other?
gcc_unreachable ();
- }
+ }
+}
tmp = gfc_get_cfi_desc_type (cfi);
gfc_add_modify (&block, tmp,
@@ -5700,7 +5704,8 @@ gfc_conv_gfc_desc_to_cfi_desc (gfc_se *parmse, gfc_expr *e, gfc_symbol *fsym)
gfc_init_block (&block2);
/* Set elem_len, which may be only known at run time. */
- if (e->ts.type == BT_CHARACTER)
+ if (e->ts.type == BT_CHARACTER
+ && (e->expr_type != EXPR_NULL || gfc_strlen != NULL_TREE))
{
gcc_assert (gfc_strlen);
tmp = gfc_strlen;
diff --git a/gcc/testsuite/gfortran.dg/null_actual_2.f90 b/gcc/testsuite/gfortran.dg/null_actual_2.f90
new file mode 100644
index 000..de481f01295
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/null_actual_2.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+!
+! PR fortran/104126
+!
+! Contributed by G. Steinmetz
+!
+program p
+ use iso_c_binding, only: c_char
+ character(len=:,kind=c_char), pointer :: d
+ call s(null(d))
+ call s(null())
+contains
+ subroutine s(x) bind(c)
+ character(len=:, kind=c_char), pointer, intent(in) :: x
+ end
+end
[committed] Fortran: Fix typos
I saw that Jakub fixed some typos/duplicated words, I thought
I could do likewise – and I found some more in gcc/fortran.
Committed as r12-7524.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit e3ca3e7993696affe95a3ea24c2b133c14a056e4
Author: Tobias Burnus
Date: Mon Mar 7 17:20:52 2022 +0100
Fortran: Fix typos
gcc/fortran/ChangeLog:
* array.cc (gfc_ref_dimen_size): Fix comment typo.
* dump-parse-tree.cc (gfc_dump_c_prototypes): Likewise.
* frontend-passes.cc (cfe_code): Likewise.
* gfortran.texi: Likewise.
* resolve.cc (generate_component_assignments): Likewise.
* simplify.cc (gfc_simplify_this_image): Likewise.
* trans-expr.cc (trans_scalar_class_assign,
gfc_maybe_dereference_var): Likewise.
* intrinsic.texi: Remove word duplication.
* invoke.texi: Likewise.
diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index f1d92e00c98..eb9ed8580a0 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -2420,7 +2420,7 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen, mpz_t *result, mpz_t *end)
gfc_free_expr(stride_expr);
}
- /* Calculate the number of elements via gfc_dep_differce, but only if
+ /* Calculate the number of elements via gfc_dep_difference, but only if
start and end are both supplied in the reference or the array spec.
This is to guard against strange but valid code like
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 322416e6556..3635460bffd 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -3543,7 +3543,7 @@ gfc_dump_c_prototypes (gfc_namespace *ns, FILE *file)
gfc_traverse_ns (ns, write_interop_decl);
}
-/* Loop over all global symbols, writing out their declrations. */
+/* Loop over all global symbols, writing out their declarations. */
void
gfc_dump_external_c_prototypes (FILE * file)
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 22f1bb56a2b..4033f27df99 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-passes.cc
@@ -974,7 +974,7 @@ cfe_code (gfc_code **c, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
changed_statement = NULL;
/* Do not do anything inside a WHERE statement; scalar assignments, BLOCKs
- and allocation on assigment are prohibited inside WHERE, and finally
+ and allocation on assignment are prohibited inside WHERE, and finally
masking an expression would lead to wrong-code when replacing
WHERE (a>0)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 2a55676791b..f8737f4d323 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1093,7 +1093,7 @@ variable.
The maximum number of bytes of user data in a subrecord is 2147483639
(2 GiB - 9) for a four-byte record marker. This limit can be lowered
-with the @option{-fmax-subrecord-length} option, altough this is
+with the @option{-fmax-subrecord-length} option, although this is
rarely useful. If the length of a logical record exceeds this limit,
the data is distributed among several subrecords.
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index f182cacb4b8..e3cd8279960 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -12897,7 +12897,7 @@ end program real_kinds
@table @asis
@item @emph{Description}:
@code{SET_EXPONENT(X, I)} returns the real number whose fractional part
-is that that of @var{X} and whose exponent part is @var{I}.
+is that of @var{X} and whose exponent part is @var{I}.
@item @emph{Standard}:
Fortran 90 and later
@@ -12917,7 +12917,7 @@ Elemental function
@item @emph{Return value}:
The return value is of the same type and kind as @var{X}.
The real number whose fractional part
-is that that of @var{X} and whose exponent part if @var{I} is returned;
+is that of @var{X} and whose exponent part if @var{I} is returned;
it is @code{FRACTION(X) * RADIX(X)**I}.
@item @emph{Example}:
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 6435dc4d4de..5c7501a28b1 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1858,7 +1858,7 @@ except when optimizing for size via @option{-Os}. If the code
contains a very large number of argument that have to be packed, code
size and also compilation time may become excessive. If that is the
case, it may be better to disable this option. Instances of packing
-can be found by using by using @option{-Warray-temporaries}.
+can be found by using @option{-Warray-temporaries}.
@item -fexternal-blas
@opindex @code{fexternal-blas}
@@ -2068,7 +2068,7 @@ does not generate p
Re: [Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]
Hi Tobias, Am 07.03.22 um 15:01 schrieb Tobias Burnus: The problem is that inside the main program, y = f(z) where the the result of z is type(t) :: z(size(x%a)) and 'x' is a dummy argument. 'x' looses the attr.dummy in gfc_add_interface_mapping and this leads to an additional indirect ref in gfc_maybe_dereference_var - but after the first indirect ref, TREE_TYPE is alread a RECORD_TYPE ... The simple fix is to simply punt when the argument is not a pointer or reference. This patch additionally fixes a comment in conv_parent_component_references. LGTM. Regarding the commit message, there should be a period at the end of >(gfc_maybe_dereference_var): Avoid derefereing a nonpointer I think there are other PRs which profit from this fix. Can you please have a look at PR99585, and in particular the link in comment#0? ;-) Those parts are obvious. The only potentially risky change is the comparison change from a name-wise comparison to a pointer-based comparison. I think it is fine and the testsuite did not find any issue, but you prefer, I can also exclude it. I was thinking about this, too. But your change will prevent running into trouble in the (unlikely?) case c being a NULL pointer. OK for mainline? How about GCC 10/11 backports? (I think leaving out the last change, it should be very safe to do.) OK, as this is both an ICE-on-valid and a regression. Thanks for the patch! Harald Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
