Re: [Patch, Fortran] Allow ref'ing PDT's len() in parameter-initializer [PR102003]

Hi Andre, I forgot to answer your other question: Am 11.07.23 um 18:23 schrieb Andre Vehreschild via Gcc-patches: I tried to use a pdt within a derived type as a component. Is that not allowed by the standard? I know, I could hunt in the standard for it, but when someone knows out of his head,

Re: [Patch, Fortran] Allow ref'ing PDT's len() in parameter-initializer [PR102003]

Hi Andre, this looks much better now! This looks mostly good to me, except for a typo in the testcase: + if (p% ci% len /= 42) stop 4 There is no component "ci", only "c". The testsuite would fail. Regarding the memleak: replacing // TODO: Fix leaking expr tmp, when simplify is done

Re: [PATCH] Fortran: formal symbol attributes for intrinsic procedures [PR110288]

On Tue, Jul 11, 2023 at 09:39:31PM +0200, Harald Anlauf via Fortran wrote: > Dear all, > > for intrinsic procedures we derive the typespec of the formal symbol > attributes from the actual arguments. This can have an undesired > effect for character actual arguments, as the argument passing >

[PATCH] Fortran: formal symbol attributes for intrinsic procedures [PR110288]

Dear all, for intrinsic procedures we derive the typespec of the formal symbol attributes from the actual arguments. This can have an undesired effect for character actual arguments, as the argument passing conventions differ for deferred-length (length is passed by reference) and otherwise

Re: [Patch, Fortran] Allow ref'ing PDT's len() in parameter-initializer [PR102003]

Hi Harald, attached is a new version of the patch. This now also respects inquiry-LEN. Btw, there is a potential memory leak in the simplify for inquiry functions. I have added a note into the code. I tried to use a pdt within a derived type as a component. Is that not allowed by the standard? I

Re: [PATCH] fortran: Release symbols in reversed order [PR106050]

Hi Mikhail, That's more than OK by me. Thanks for attacking this PR. I have a couple more of Steve's orphans waiting to be packaged up - 91960 and 104649. I'll submit them this evening.100607 is closed-fixed and 103796 seems to be fixed. Regards Paul On Tue, 11 Jul 2023 at 13:08, Mikael

[PATCH] fortran: Release symbols in reversed order [PR106050]

Hello, I saw the light regarding this PR after Paul posted a comment yesterday. Regression test in progress on x86_64-pc-linux-gnu. I plan to push in the next hours. Mikael -- >8 -- Release symbols in reversed order wrt the order they were allocated. This fixes an error recovery ICE in the

[PATCH 3/3] fortran: Reorder array argument evaluation parts [PR92178]

In the case of an array actual arg passed to a polymorphic array dummy with INTENT(OUT) attribute, reorder the argument evaluation code to the following: - first evaluate arguments' values, and data references, - deallocate data references associated with an allocatable, intent(out) dummy, -

[PATCH 2/3] fortran: Factor data references for scalar class argument wrapping [PR92178]

In the case of a scalar actual arg passed to a polymorphic assumed-rank dummy with INTENT(OUT) attribute, avoid repeatedly evaluating the actual argument reference by saving a pointer to it. This is non-optimal, but may also be invalid, because the data reference may depend on its own content.

[PATCH 0/3] Fix argument evaluation order [PR92178]

Hello, this is a followup to Harald's recent work [1] on the evaluation order of arguments, when one of them is passed to an intent(out) allocatable dummy and is deallocated before the call. This extends Harald's fix to support: - scalars passed to assumed rank dummies (patch 1), - scalars

[PATCH 1/3] fortran: defer class wrapper initialization after deallocation [PR92178]

If an actual argument is associated with an INTENT(OUT) dummy, and code to deallocate it is generated, generate the class wrapper initialization after the actual argument deallocation. This is achieved by passing a cleaned up expression to gfc_conv_class_to_class, so that the class wrapper

Re: Can't get the horse out of the gate

You might be better asking a question on comp.lang.fortran newsgroup or the Fortran discourse site (https://fortran-lang.discourse.group/). This mailing list is specifically for the gfortran compiler, not user questions. Also, I might add, the title and the contents of your message may be