Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas <paul.richard.thomas@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

Hi Thomas,

I was thinking of a function in resolve.cc, similar
to generate_component_assignments that would generate the final call and,
where necessary, generate a temporary and place rhs finalization after the
assignment. Since this would only involve ordinary assignment and
subroutine calls, I think that it is compatible both with forall and where
constructs.

I guess that I should check whether or not generate_component_assignments
should not be placed within frontend_passes.cc. This part of resolve.cc
precedes your efforts, I believe.

Generating the final calls in the frontend would eliminate a substantial
amount of rather opaque code.

Best regards

Paul


On Sun, 8 Jan 2023 at 12:03, Thomas Koenig <tkoenig@netcologne.de> wrote:

> Hi Paul,
>
> > What causes the ICES?
>
> There were a few PRs along this line.  Usually, it is the
> front-end pass inserting code which is illegal Fortran, and
> the later stages then asserting that it doesn't happen.
>
> Here are a few examples:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 (function
> elimination in OMP Workshare)
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 (forall)
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69154 (matmul
> in where)
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 (in
> associate).
>
> If you want to do the finalization of function results via
> a front end pass, creating a variable and then assigning it
> from within these constructs can cause these kinds of problems.
>
> Best regards
>
>         Thomas
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein