public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug fortran/105658] New: Passing array component to unlimited polymorphic routine passes wrong slice @ 2022-05-19 9:28 zed.three at gmail dot com 2024-02-20 19:50 ` [Bug fortran/105658] " cvs-commit at gcc dot gnu.org ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: zed.three at gmail dot com @ 2022-05-19 9:28 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105658 Bug ID: 105658 Summary: Passing array component to unlimited polymorphic routine passes wrong slice Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- The following program: program f implicit none type :: foo integer :: member1 integer :: member2 end type foo type(foo), dimension(3) :: thing = [foo(1, 2), foo(3, 4), foo(5, 6)] call print_poly(thing%member1) call print_int(thing%member1) contains subroutine print_poly(array) class(*), dimension(:), intent(in) :: array select type(array) type is (integer) print*, array end select end subroutine subroutine print_int(array) integer, dimension(:), intent(in) :: array print*, array end subroutine end program f prints: 1 2 3 1 3 5 when we would expect: 1 3 5 1 3 5 Adding `-fcheck=all`, we get the warning "Fortran runtime warning: An array temporary was created" _only_ for the call to `print_int`. Adding an extra set of parentheses to the `print_poly` call (`call print_poly((thing%member1))` gives the expected behaviour, I guess because it's forcing an array temporary? This behaviour is present in 4.9.4 through to the trunk currently available on Compiler Explorer ((Compiler-Explorer-Build-gcc-7da9a089608b0ca09683332ce014fb6184842724-binutils-2.38) 13.0.0 20220518 (experimental)) ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/105658] Passing array component to unlimited polymorphic routine passes wrong slice 2022-05-19 9:28 [Bug fortran/105658] New: Passing array component to unlimited polymorphic routine passes wrong slice zed.three at gmail dot com @ 2024-02-20 19:50 ` cvs-commit at gcc dot gnu.org 2024-02-20 19:57 ` anlauf at gcc dot gnu.org 2024-03-06 21:12 ` anlauf at gcc dot gnu.org 2 siblings, 0 replies; 4+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2024-02-20 19:50 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105658 --- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>: https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2 commit r14-9086-g14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2 Author: Peter Hill <peter.hill@york.ac.uk> Date: Tue Feb 20 20:42:53 2024 +0100 Fortran: fix passing array component ref to polymorphic procedures PR fortran/105658 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_intrinsic_to_class): When passing an array component reference of intrinsic type to a procedure with an unlimited polymorphic dummy argument, a temporary should be created. gcc/testsuite/ChangeLog: * gfortran.dg/PR105658.f90: New test. Signed-off-by: Peter Hill <peter.hill@york.ac.uk> ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/105658] Passing array component to unlimited polymorphic routine passes wrong slice 2022-05-19 9:28 [Bug fortran/105658] New: Passing array component to unlimited polymorphic routine passes wrong slice zed.three at gmail dot com 2024-02-20 19:50 ` [Bug fortran/105658] " cvs-commit at gcc dot gnu.org @ 2024-02-20 19:57 ` anlauf at gcc dot gnu.org 2024-03-06 21:12 ` anlauf at gcc dot gnu.org 2 siblings, 0 replies; 4+ messages in thread From: anlauf at gcc dot gnu.org @ 2024-02-20 19:57 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105658 anlauf at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anlauf at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed| |2024-02-20 Status|UNCONFIRMED |NEW --- Comment #2 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14 so far. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/105658] Passing array component to unlimited polymorphic routine passes wrong slice 2022-05-19 9:28 [Bug fortran/105658] New: Passing array component to unlimited polymorphic routine passes wrong slice zed.three at gmail dot com 2024-02-20 19:50 ` [Bug fortran/105658] " cvs-commit at gcc dot gnu.org 2024-02-20 19:57 ` anlauf at gcc dot gnu.org @ 2024-03-06 21:12 ` anlauf at gcc dot gnu.org 2 siblings, 0 replies; 4+ messages in thread From: anlauf at gcc dot gnu.org @ 2024-03-06 21:12 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105658 anlauf at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Priority|P3 |P4 Target Milestone|--- |14.0 Status|NEW |RESOLVED --- Comment #3 from anlauf at gcc dot gnu.org --- Backporting to 13-branch appears to depend on a backport of Paul's commit r14-870-g6c95fe9bc05537, or part of it, plus maybe more. Might be risky. Setting target milestone to 14 and closing. Thanks to Peter for the patch! ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-03-06 21:12 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-19 9:28 [Bug fortran/105658] New: Passing array component to unlimited polymorphic routine passes wrong slice zed.three at gmail dot com 2024-02-20 19:50 ` [Bug fortran/105658] " cvs-commit at gcc dot gnu.org 2024-02-20 19:57 ` anlauf at gcc dot gnu.org 2024-03-06 21:12 ` anlauf at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).