[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 --- Comment #10 from Paul Thomas --- Leave open partly because it is awaiting backporting to 14-branch but also because there are remaining, pre-existing issues involving parentheses around selector/source expressions: https://gcc.gnu.org/pipermail/fortran/2024-May/060510.html Paul
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 --- Comment #9 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:2d0eeb529d400e61197a09c56011be976dd81ef0 commit r15-394-g2d0eeb529d400e61197a09c56011be976dd81ef0 Author: Paul Thomas Date: Mon May 13 07:27:20 2024 +0100 Fortran: Fix wrong code in unlimited polymorphic assignment [PR113363] 2024-05-13 Paul Thomas gcc/fortran PR fortran/113363 * trans-array.cc (gfc_array_init_size): Use the expr3 dtype so that the correct element size is used. * trans-expr.cc (gfc_conv_procedure_call): Remove restriction that ss and ss->loop be present for the finalization of class array function results. (trans_class_assignment): Use free and malloc, rather than realloc, for character expressions assigned to unlimited poly entities. * trans-stmt.cc (gfc_trans_allocate): Build a correct rhs for the assignment of an unlimited polymorphic 'source'. gcc/testsuite/ PR fortran/113363 * gfortran.dg/pr113363.f90: New test.
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 Richard Biener changed: What|Removed |Added Target Milestone|14.0|14.2 --- Comment #8 from Richard Biener --- GCC 14.1 is being released, retargeting bugs to GCC 14.2.
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 --- Comment #7 from Paul Thomas --- Created attachment 57892 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57892=edit Fix for this PR The attachment has two fixes for the PR :-) The first chunk in trans-array.cc is an alternative to the direct, rather brutal chunk in trans-stmt.cc. The latter, though, isolates the fix to allocate statements. I am not entirely sure which is better. It needs some comments and a proper testcase. Cheers Paul
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #5) > (In reply to anlauf from comment #4) > > This PR has been fixed as part of the large commit r14-9489-g3fd46d859cda10 > > . > > Not here. As far as I can tell the results remain exactly the same for both > character and numeric results from 'foo'. Oops, I only checked that comment#0 is fixed (-> gfortran.dg/associate_66.f90) and overlooked the other case in comment#1. Reopening. Regarding ALLOCATE with SOURCE and CHARACTER, I have a partial patch for pr113793. Need to look again into that one.
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 Paul Thomas changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|FIXED |--- --- Comment #5 from Paul Thomas --- (In reply to anlauf from comment #4) > This PR has been fixed as part of the large commit r14-9489-g3fd46d859cda10 . Not here. As far as I can tell the results remain exactly the same for both character and numeric results from 'foo'. Is it possible that there is a patch lurking in your tree that has fixed it? Cheers Paul
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|NEW |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- This PR has been fixed as part of the large commit r14-9489-g3fd46d859cda10 .
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 --- Comment #3 from Paul Thomas --- (In reply to Paul Thomas from comment #2) > > > > Both allocation with source and assignment are broken :-( > > With numerical output from foo ([1,2,3,4,5]), we get: > >1 3 5 33 1 >1 2 3 4 5 >1 2 3 4 5 > > So allocation with source is broken here as well but assignment is OK. I have confirmed that the construction of e3rhs starting at trans-stmt.cc:6653 is the cause of the problem with allocation. I have to put this on one side until the end of February. Paul
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 Paul Thomas changed: What|Removed |Added Last reconfirmed||2024-01-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- > > Both allocation with source and assignment are broken :-( With numerical output from foo ([1,2,3,4,5]), we get: 1 3 5 33 1 1 2 3 4 5 1 2 3 4 5 So allocation with source is broken here as well but assignment is OK.
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363
--- Comment #1 from Paul Thomas ---
(In reply to anlauf from comment #0)
> While discussing a patch for PR89645/99065, the following issue with
> ASSOCIATE and unlimited polymorphic functions was found:
>
> https://gcc.gnu.org/pipermail/fortran/2024-January/060098.html
>
> program p
> implicit none
> class(*), allocatable :: x(:)
> x = foo()
> call prt (x)
> deallocate (x)! up to here all is fine...
> associate (var => foo()) ! <- crash here
> call prt (var) ! <- or here
> end associate
> contains
> function foo() result(res)
> class(*), allocatable :: res(:)
> res = [42]
> end function foo
> subroutine prt (x)
> class(*), intent(in) :: x(:)
> select type (x)
> type is (integer)
>print *, x
> class default
>stop 99
> end select
> end subroutine prt
> end
>
>
> This ICEs on current trunk for any of the indicated statements.
The associate bit is fixed with a one liner; with the patch applied:
@@ -2295,7 +2305,8 @@ trans_associate_var (gfc_symbol *sym, gfc_wrapped_block
*block)
}
/* Set the stringlength, when needed. */
- if (need_len_assign)
+ if (need_len_assign
+ && !(e->symtree->n.sym->attr.function && UNLIMITED_POLY
(e->symtree->n.sym)))
{
gfc_se se;
gfc_init_se (, NULL);
the following gives the output in the comments:
program p
implicit none
class(*), allocatable :: x(:)
allocate(x, source = foo())
call prt (x) ! Wrong output "6 hello e"
deallocate (x)
x = foo()
call prt (x) ! Wrong output "0 "
deallocate (x)!
associate (var => foo()) ! Now OK
call prt (var) ! Now OK - outputs: "6 hello bye "
end associate
contains
function foo() result(res)
class(*), allocatable :: res(:)
res = ["hello ","bye "]
end function foo
subroutine prt (x)
class(*), intent(in) :: x(:)
select type (x)
type is (character(*))
print *, len(x), x
class default
stop 99
end select
end subroutine prt
end
Both allocation with source and assignment are broken :-(
