From: Harald Anlauf <anlauf@gmx.de>
To: Paul Richard Thomas <paul.richard.thomas@gmail.com>,
"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>
Cc: chilikin.k@gmail.com
Subject: Re: [Patch, fortran] PR110987 and PR113885 - gimplifier ICEs and wrong results in finalization
Date: Thu, 28 Mar 2024 23:27:28 +0100 [thread overview]
Message-ID: <f550d85d-2cf6-40aa-b0cb-f9a5a5bae4c9@gmx.de> (raw)
In-Reply-To: <CAGkQGi+w71QrY9ksunrRwSG9pP2xU=VX5ojG0C8FSvP9sBXhxQ@mail.gmail.com>
Hi Paul,
Am 28.03.24 um 16:39 schrieb Paul Richard Thomas:
> Hi All,
>
> The attached patch has two elements:
>
> (i) A fix for gimplifier ICEs with derived type having no components. The
> reporter himself suggested (thanks Kirill!):
>
> - if (derived && derived->attr.zero_comp)
> + if (derived && (derived->components == NULL))
>
> As far as I can tell, this is the correct fix. I tried setting
> attr.zero_comp in resolve.cc for all the OK types without components but
> this caused all sorts of fallout.
>
> (ii) Final calls were occurring in the wrong place for finalizable
> elemental function calls within scalarizer loops. This caused incorrect
> results even for derived types with components. This is also fixed.
yes, this looks good here.
> It should be noted that finalizer calls from the rhs of an assignment are
> occurring at the wrong time, since F2018/24-7.5.6.3 requires:
> "If an executable construct references a nonpointer function, the result is
> finalized after execution of the innermost executable construct containing
> the reference.", while in the present implementation, this happening just
> before assignment to the lhs temporary. Fixing this is going to be really
> tough and invasive, so I decided that getting the right results and the
> correct number of finalization should be sufficient for the 14-branch
> release. As it happens, I had been mulling over how to do this for
> finalizations hidden in constructors and other contexts than assignment
> (eg. write statements or allocation with source). It's a few months away
> and will be appropriate for stage 1.
>
> Regtests on x86_64 - OK for mainline and then, after a bit, for backporting
> to 13-branch?
The patch looks rather "conservative" (read: safe) and appears to
fix the regressions very well, so go ahead as planned.
Thanks for the patch!
Harald
> Regards to all
>
> Paul
>
> Fortran: Fix a gimplifier ICE/wrong result with finalization [PR104555]
>
> 2024-03-28 Paul Thomas <pault@gcc.gnu.org>
>
> gcc/fortran
> PR fortran/36337
> PR fortran/110987
> PR fortran/113885
> * trans-expr.cc (gfc_trans_assignment_1): Place finalization
> block before rhs post block for elemental rhs.
> * trans.cc (gfc_finalize_tree_expr): Check directly if a type
> has no components, rather than the zero components attribute.
> Treat elemental zero component expressions in the same way as
> scalars.
>
>
> gcc/testsuite/
> PR fortran/113885
> * gfortran.dg/finalize_54.f90: New test.
> * gfortran.dg/finalize_55.f90: New test.
>
> gcc/testsuite/
> PR fortran/110987
> * gfortran.dg/finalize_56.f90: New test.
>
next prev parent reply other threads:[~2024-03-28 22:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-28 15:39 Paul Richard Thomas
2024-03-28 22:27 ` Harald Anlauf [this message]
2024-03-29 8:07 ` Paul Richard Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f550d85d-2cf6-40aa-b0cb-f9a5a5bae4c9@gmx.de \
--to=anlauf@gmx.de \
--cc=chilikin.k@gmail.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=paul.richard.thomas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).