[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||clange001 at gmail dot com --- Comment #15 from anlauf at gcc dot gnu.org --- *** Bug 106317 has been marked as a duplicate of this bug. ***
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #14 from Bálint Aradi --- Thanks a lot for fixing it!
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Paul Thomas --- Fixed on 13-branch and trunk. Thanks for the report Paul
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #12 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:6fb12d3a0456a3503a670d95803aef10549f0134 commit r13-7986-g6fb12d3a0456a3503a670d95803aef10549f0134 Author: Paul Thomas Date: Thu Oct 12 07:26:59 2023 +0100 Fortran: Set hidden string length for pointer components [PR67740]. 2023-10-11 Paul Thomas gcc/fortran PR fortran/67740 * trans-expr.cc (gfc_trans_pointer_assignment): Set the hidden string length component for pointer assignment to character pointer components. gcc/testsuite/ PR fortran/67740 * gfortran.dg/pr67740.f90: New test (cherry picked from commit 701363d827d45d3e3601735fa42f95644fda8b64)
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #11 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:701363d827d45d3e3601735fa42f95644fda8b64 commit r14-4583-g701363d827d45d3e3601735fa42f95644fda8b64 Author: Paul Thomas Date: Thu Oct 12 07:26:59 2023 +0100 Fortran: Set hidden string length for pointer components [PR67740]. 2023-10-11 Paul Thomas gcc/fortran PR fortran/67740 * trans-expr.cc (gfc_trans_pointer_assignment): Set the hidden string length component for pointer assignment to character pointer components. gcc/testsuite/ PR fortran/67740 * gfortran.dg/pr67740.f90: New test
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #9) Addendum: > I was suspecting gfc_conv_variable as a possibly further place for a fix: > it has a loop over ref's that looks incomplete for REF_COMPONENT. I tried my version of a patch in that place, which worked for the testcases here but gave wrong code already for slightly more complex pointer assignments, like type(pointer_typec0_t) :: co, xo ... xo%data1 => co%data1 so let's go with your patch.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #8) > Created attachment 56073 [details] > "Fix" for this PR > > Hi Harald, > > You are touching the right place. However, this should be happening in > gfc_conv_expr_descriptor I would have thought so that strlen_lhs comes back > with the correct value. Yes, this might be a latent issue still showing up elsewhere for deferred length, although your patch seems to fix cases immediately related to those in this PR. I was suspecting gfc_conv_variable as a possibly further place for a fix: it has a loop over ref's that looks incomplete for REF_COMPONENT. Nevertheless, your patch works for me.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #8 from Paul Thomas --- Created attachment 56073 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56073=edit "Fix" for this PR Hi Harald, You are touching the right place. However, this should be happening in gfc_conv_expr_descriptor I would have thought so that strlen_lhs comes back with the correct value. Cheers Paul
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
--- Comment #7 from anlauf at gcc dot gnu.org ---
The following snippet in gfc_trans_pointer_assignment looks suspicious:
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))
{
tmp = expr1->symtree->n.sym->ts.u.cl->backend_decl;
if (expr2->expr_type != EXPR_NULL)
gfc_add_modify (, tmp,
fold_convert (TREE_TYPE (tmp), strlen_rhs));
else
gfc_add_modify (, tmp, build_zero_cst (TREE_TYPE (tmp)));
}
I wonder whether it should read:
if (expr1->ts.type == BT_CHARACTER
&& expr1->ts.deferred
...
Furthermore, expr1->ts.u.cl->backend_decl appears not set properly,
and I fail to see why.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code --- Comment #6 from anlauf at gcc dot gnu.org --- Extending the testcase in comment#4: program test2 implicit none character(len=10), allocatable, target :: s(:) character(len=:), pointer :: sptr(:) type :: pointer_typec0_t 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 print *, sptr ! OK co%data1 => s print *, co%data1 ! not OK ! print *,len(co%data1(1)),len_trim(co%data1(1)),co%data1(1) print *,len(co%data1(2)),len_trim(co%data1(2)),co%data1(2) print *,len(co%data1(3)),len_trim(co%data1(3)),co%data1(3) end program test2 The tree-dump has: .sptr = 10; sptr = s; sptr.span = s.span; but co.data1 = s; co.data1.span = s.span; so we don't set the character length in the association.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Created attachment 55998 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55998=edit Testcase for scalar pointer The original testcase from comment#0 failed with 9.5.0, but works with 10.5.0 and newer. An extended deja-gnuified testcase for this is attached. The variant with array-valued pointers in comment#4 still fails.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 Sebastien Bardeau changed: What|Removed |Added CC||bardeau at iram dot fr --- Comment #4 from Sebastien Bardeau --- I have pretty much the same kind of issue with gfortran 10.2.0 and 11.0.1 (20210426). The following code shows invalid results (printed lengths are 0). Sometimes I even get a program crash. If the 'data1' component is a standalone pointer (i.e. out of the derived type), I have no issue then. program test2 character(len=10), target, allocatable :: s(:) type :: pointer_typec0_t 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 ' ! co%data1 => s ! print *,len(co%data1(1)),len_trim(co%data1(1)),co%data1(1) print *,len(co%data1(2)),len_trim(co%data1(2)),co%data1(2) print *,len(co%data1(3)),len_trim(co%data1(3)),co%data1(3) end program test2
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > The dump-tree looks funny: it appears that in the last test > > print *, "Associated contents?", associated(p1%string, p2%string) > > the association is already evaluated at compile time to .false. I do not understand the following code in trans-intrinsic.c, which may be part of the underlying cause: 8426 nonzero_charlen = NULL_TREE; 8427 if (arg1->expr->ts.type == BT_CHARACTER) 8428nonzero_charlen = fold_build2_loc (input_location, NE_EXPR, 8429 logical_type_node, 8430 arg1->expr->ts.u.cl->backend_decl, 8431 build_zero_cst 8432 (TREE_TYPE (arg1->expr->ts.u.cl->backend_decl))); and 8500 /* If target is present zero character length pointers cannot 8501 be associated. */ 8502 if (nonzero_charlen != NULL_TREE) 8503se->expr = fold_build2_loc (input_location, TRUTH_AND_EXPR, 8504logical_type_node, 8505se->expr, nonzero_charlen);
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- The dump-tree looks funny: it appears that in the last test print *, "Associated contents?", associated(p1%string, p2%string) the association is already evaluated at compile time to .false.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed with 5.2 and 6.0. I get the following ICE with 4.9 pr67740.f90:20:0: internal compiler error: in gimplify_expr, at gimplify.c:8538 allocate(character(4) :: myBase%string) the change occurred between revisions r221423 (2015-03-13, ICE) and r2214164+patches (2015-03-16, compiles).
