[Patch, fortran] PR67740 - Wrong association status of allocatable character pointer in derived types
Hi All,
The title line of the PR should have been changed a long time since. As
noted in comment 5, the original problem was fixed in 10.5.
This patch fixes the problem described in comments 4 and 6, where the
hidden string length component was not being set in pointer assignment of
character arrays.
The fix regtests. OK for trunk and 13-branch?
Thanks are due to Harald for bringing this to my attention.
Paul
Fortran: Set hidden string length for pointer components [PR67440]
2023-10-11 Paul Thomas
gcc/fortran
PR fortran/pr67740
* trans-expr.cc (gfc_trans_pointer_assignment): Set the hidden
string length component for pointer assignment to character
pointer components.
gcc/testsuite/
PR fortran/87477
* gfortran.dg/pr67740.f90: New test
! {dg-do compile }
! { dg-options "-fdump-tree-original" }
!
! Check the fix for the testcase in comment 4, where the hidden string length
! component of the array pointer component was not set.
!
! Contributed by Sebastien Bardeau
!
program test2
implicit none
character(len=10), allocatable, target :: s(:)
character(len=:), pointer :: sptr(:)
type :: pointer_typec0_t
character(len=:), pointer :: data0
character(len=:), pointer :: data1(:)
end type pointer_typec0_t
type(pointer_typec0_t) :: co
!
allocate(s(3))
s(1) = '1234567890'
s(2) = 'qwertyuio '
s(3) = 'asdfghjk '
!
sptr => s
co%data0 => s(1)
co%data1 => s
!
if (any (sptr .ne. s)) stop 1
if (co%data0 .ne. s(1)) stop 2
if (any (co%data1 .ne. s)) stop 3 ! Hidden string length was not set
end program test2
! { dg-final { scan-tree-dump-times "co._data1_length = 10;" 1 "original" } }diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 860b73c4968..7beefa2e69c 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -10403,11 +10403,36 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2)
}
if (expr1->ts.type == BT_CHARACTER
- && expr1->symtree->n.sym->ts.deferred
- && expr1->symtree->n.sym->ts.u.cl->backend_decl
- && VAR_P (expr1->symtree->n.sym->ts.u.cl->backend_decl))
+ && expr1->ts.deferred)
{
- tmp = expr1->symtree->n.sym->ts.u.cl->backend_decl;
+ gfc_symbol *psym = expr1->symtree->n.sym;
+ tmp = NULL_TREE;
+ if (psym->ts.type == BT_CHARACTER)
+ {
+ gcc_assert (psym->ts.u.cl->backend_decl
+ && VAR_P (psym->ts.u.cl->backend_decl));
+ tmp = psym->ts.u.cl->backend_decl;
+ }
+ else if (expr1->ts.u.cl->backend_decl
+ && VAR_P (expr1->ts.u.cl->backend_decl))
+ tmp = expr1->ts.u.cl->backend_decl;
+ else if (TREE_CODE (lse.expr) == COMPONENT_REF)
+ {
+ gfc_ref *ref = expr1->ref;
+ for (;ref; ref = ref->next)
+ {
+ if (ref->type == REF_COMPONENT
+ && ref->u.c.component->ts.type == BT_CHARACTER
+ && gfc_deferred_strlen (ref->u.c.component, &tmp))
+ tmp = fold_build3_loc (input_location, COMPONENT_REF,
+ TREE_TYPE (tmp),
+ TREE_OPERAND (lse.expr, 0),
+ tmp, NULL_TREE);
+ }
+ }
+
+ gcc_assert (tmp);
+
if (expr2->expr_type != EXPR_NULL)
gfc_add_modify (&block, tmp,
fold_convert (TREE_TYPE (tmp), strlen_rhs));
Re: [Patch, fortran] PR67740 - Wrong association status of allocatable character pointer in derived types
Hi Paul, On 10/11/23 10:48, Paul Richard Thomas wrote: Hi All, The title line of the PR should have been changed a long time since. As noted in comment 5, the original problem was fixed in 10.5. This patch fixes the problem described in comments 4 and 6, where the hidden string length component was not being set in pointer assignment of character arrays. The fix regtests. OK for trunk and 13-branch? this is OK for both. I'd suggest to wait a couple of days or a week before backporting. Thanks for the patch! Harald Thanks are due to Harald for bringing this to my attention. Paul Fortran: Set hidden string length for pointer components [PR67440] 2023-10-11 Paul Thomas gcc/fortran PR fortran/pr67740 * trans-expr.cc (gfc_trans_pointer_assignment): Set the hidden string length component for pointer assignment to character pointer components. gcc/testsuite/ PR fortran/87477 * gfortran.dg/pr67740.f90: New test
Re: [Patch, fortran] PR67740 - Wrong association status of allocatable character pointer in derived types
Hi Paul,
the patch is fine, but I forgot the mention that the testcase needs fixing:
Instead of
! {dg-do compile }
you'll likely want
! { dg-do run }
(Note the space before the dg-command.)
Cheers,
Harald
On 10/11/23 21:06, Harald Anlauf wrote:
Hi Paul,
On 10/11/23 10:48, Paul Richard Thomas wrote:
Hi All,
The title line of the PR should have been changed a long time since. As
noted in comment 5, the original problem was fixed in 10.5.
This patch fixes the problem described in comments 4 and 6, where the
hidden string length component was not being set in pointer assignment of
character arrays.
The fix regtests. OK for trunk and 13-branch?
this is OK for both.
I'd suggest to wait a couple of days or a week before backporting.
Thanks for the patch!
Harald
Thanks are due to Harald for bringing this to my attention.
Paul
Fortran: Set hidden string length for pointer components [PR67440]
2023-10-11 Paul Thomas
gcc/fortran
PR fortran/pr67740
* trans-expr.cc (gfc_trans_pointer_assignment): Set the hidden
string length component for pointer assignment to character
pointer components.
gcc/testsuite/
PR fortran/87477
* gfortran.dg/pr67740.f90: New test
[PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]
Dear All,
the attached trivial patch fixes (= catches) a forgotten corner-case
in the detection of a name conflict between an internal procedure and
a local declaration for the case that the latter is a derived type.
Another torture test by Gerhard... ;-) Used to ICE previously.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 75dc455f21cea07e64b422c9994ab8879df388de Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 6 Oct 2023 22:21:56 +0200
Subject: [PATCH] fortran: fix handling of options -ffpe-trap and -ffpe-summary
[PR110957]
gcc/fortran/ChangeLog:
PR fortran/110957
* invoke.texi: Update documentation to reflect '-ffpe-trap=none'.
* options.cc (gfc_handle_fpe_option): Fix mixup up of error messages
for options -ffpe-trap and -ffpe-summary. Accept '-ffpe-trap=none'
to clear FPU traps previously set on command line.
---
gcc/fortran/invoke.texi | 6 --
gcc/fortran/options.cc | 9 ++---
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 38150b1e29e..10387e39501 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1294,7 +1294,8 @@ Specify a list of floating point exception traps to enable. On most
systems, if a floating point exception occurs and the trap for that
exception is enabled, a SIGFPE signal will be sent and the program
being aborted, producing a core file useful for debugging. @var{list}
-is a (possibly empty) comma-separated list of the following
+is a (possibly empty) comma-separated list of either @samp{none} (to
+clear the set of exceptions to be trapped), or of the following
exceptions: @samp{invalid} (invalid floating point operation, such as
@code{SQRT(-1.0)}), @samp{zero} (division by zero), @samp{overflow}
(overflow in a floating point operation), @samp{underflow} (underflow
@@ -1314,7 +1315,8 @@ If the option is used more than once in the command line, the lists will
be joined: '@code{ffpe-trap=}@var{list1} @code{ffpe-trap=}@var{list2}'
is equivalent to @code{ffpe-trap=}@var{list1},@var{list2}.
-Note that once enabled an exception cannot be disabled (no negative form).
+Note that once enabled an exception cannot be disabled (no negative form),
+except by clearing all traps by specifying @samp{none}.
Many, if not most, floating point operations incur loss of precision
due to rounding, and hence the @code{ffpe-trap=inexact} is likely to
diff --git a/gcc/fortran/options.cc b/gcc/fortran/options.cc
index 27311961325..2ad22478042 100644
--- a/gcc/fortran/options.cc
+++ b/gcc/fortran/options.cc
@@ -555,9 +555,12 @@ gfc_handle_fpe_option (const char *arg, bool trap)
pos++;
result = 0;
- if (!trap && strncmp ("none", arg, pos) == 0)
+ if (strncmp ("none", arg, pos) == 0)
{
- gfc_option.fpe_summary = 0;
+ if (trap)
+ gfc_option.fpe = 0;
+ else
+ gfc_option.fpe_summary = 0;
arg += pos;
pos = 0;
continue;
@@ -586,7 +589,7 @@ gfc_handle_fpe_option (const char *arg, bool trap)
break;
}
}
- if (!result && !trap)
+ if (!result && trap)
gfc_fatal_error ("Argument to %<-ffpe-trap%> is not valid: %s", arg);
else if (!result)
gfc_fatal_error ("Argument to %<-ffpe-summary%> is not valid: %s", arg);
--
2.35.3
Re: [PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]
Dear All,
sorry for attaching the wrong patch - this time it is the correct one!
Harald
On 10/11/23 21:39, Harald Anlauf wrote:
Dear All,
the attached trivial patch fixes (= catches) a forgotten corner-case
in the detection of a name conflict between an internal procedure and
a local declaration for the case that the latter is a derived type.
Another torture test by Gerhard... ;-) Used to ICE previously.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 84de03c97f899df91f2b7e7af4a5bbc09412a3fe Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 11 Oct 2023 21:29:35 +0200
Subject: [PATCH] Fortran: name conflict between internal procedure and derived
type [PR104351]
gcc/fortran/ChangeLog:
PR fortran/104351
* decl.cc (get_proc_name): Extend name conflict detection between
internal procedure and previous declaration also to derived type.
gcc/testsuite/ChangeLog:
PR fortran/104351
* gfortran.dg/derived_function_interface_1.f90: Adjust pattern.
* gfortran.dg/pr104351.f90: New test.
---
gcc/fortran/decl.cc| 4 +++-
.../gfortran.dg/derived_function_interface_1.f90 | 2 +-
gcc/testsuite/gfortran.dg/pr104351.f90 | 14 ++
3 files changed, 18 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr104351.f90
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 4a3c5b86de0..bdd3be32a46 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -1404,7 +1404,9 @@ get_proc_name (const char *name, gfc_symbol **result, bool module_fcn_entry)
/* Trap declarations of attributes in encompassing scope. The
signature for this is that ts.kind is nonzero for no-CLASS
entity. For a CLASS entity, ts.kind is zero. */
- if ((sym->ts.kind != 0 || sym->ts.type == BT_CLASS)
+ if ((sym->ts.kind != 0
+ || sym->ts.type == BT_CLASS
+ || sym->ts.type == BT_DERIVED)
&& !sym->attr.implicit_type
&& sym->attr.proc == 0
&& gfc_current_ns->parent != NULL
diff --git a/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90 b/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90
index 24a00950912..5438ad49c6a 100644
--- a/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90
+++ b/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90
@@ -38,7 +38,7 @@ end function ext_fun
contains
- type(foo) function fun() ! { dg-error "already has an explicit interface" }
+ type(foo) function fun() ! { dg-error "has an explicit interface" }
end function fun ! { dg-error "Expecting END PROGRAM" }
end
diff --git a/gcc/testsuite/gfortran.dg/pr104351.f90 b/gcc/testsuite/gfortran.dg/pr104351.f90
new file mode 100644
index 000..86b47e03340
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr104351.f90
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! PR fortran/104351
+! Contributed by G.Steinmetz
+
+program p
+ implicit none
+ type t
+ end type
+ type(t) :: f
+contains
+ real function f() result(z) ! { dg-error "has an explicit interface" }
+z = 0.0 ! { dg-error "assignment" }
+ end function f ! { dg-error "Expecting END PROGRAM" }
+end
--
2.35.3
Re: [Patch, fortran] PR67740 - Wrong association status of allocatable character pointer in derived types
Hi Harald and Bernhard,
Indeed, you are right about the space. However, the compile is intentional.
This catches the fix:
! { dg-final { scan-tree-dump-times "co._data1_length = 10;" 1 "original" }
}
Also, it helps to get the PR number right!
I was rushing to get the patch out before leaving for work and so even more
error prone than usual
Cheers
Paul
On Wed, 11 Oct 2023 at 20:21, Harald Anlauf wrote:
> Hi Paul,
>
> the patch is fine, but I forgot the mention that the testcase needs fixing:
>
> Instead of
>
> ! {dg-do compile }
>
> you'll likely want
>
> ! { dg-do run }
>
> (Note the space before the dg-command.)
>
> Cheers,
> Harald
>
> On 10/11/23 21:06, Harald Anlauf wrote:
> > Hi Paul,
> >
> > On 10/11/23 10:48, Paul Richard Thomas wrote:
> >> Hi All,
> >>
> >> The title line of the PR should have been changed a long time since. As
> >> noted in comment 5, the original problem was fixed in 10.5.
> >>
> >> This patch fixes the problem described in comments 4 and 6, where the
> >> hidden string length component was not being set in pointer assignment
> of
> >> character arrays.
> >>
> >> The fix regtests. OK for trunk and 13-branch?
> >
> > this is OK for both.
> >
> > I'd suggest to wait a couple of days or a week before backporting.
> >
> > Thanks for the patch!
> >
> > Harald
> >
> >> Thanks are due to Harald for bringing this to my attention.
> >>
> >> Paul
> >>
> >> Fortran: Set hidden string length for pointer components [PR67440]
> >>
> >> 2023-10-11 Paul Thomas
> >>
> >> gcc/fortran
> >> PR fortran/pr67740
> >> * trans-expr.cc (gfc_trans_pointer_assignment): Set the hidden
> >> string length component for pointer assignment to character
> >> pointer components.
> >>
> >> gcc/testsuite/
> >> PR fortran/87477
> >> * gfortran.dg/pr67740.f90: New test
> >>
> >
> >
>
>
