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

expr (tmp); > tmp = gfc_copy_expr (*newp); > } > > or rather > >if (inquiry->next) > gfc_replace_expr (tmp, *newp); > > at least shrinks the leak a bit. (Untested otherwise). > > OK with one of the above changes (provided it survives re

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

Hi all, while browsing the pdt meta-bug I came across 102003 and thought to myself: Well, that one is easy. How foolish of me... Anyway, the solution attached prevents a pdt_len (or pdt_kind) expression in a function call (e.g. len() or kind()) to mark the whole expression as a pdt one. The secon

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

Hi Harald, I do get why this happens. I still don't get why I have to do this 'optimization' manually. I mean, this rewriting of expressions is needed in more than one location and most probably already present somewhere. So who can point me in the right direction? Regards, Andre Andre Vehresch

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

arse_file() > ../../gcc-trunk/gcc/fortran/parse.cc:7235 > 0xa40a1f gfc_be_parse_file > ../../gcc-trunk/gcc/fortran/f95-lang.cc:229 > > The fortran-dump confirms that n is not simplified to a constant. > So while you're at it, do you also see a solution to this va

[PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^

Hi all, attached patch fixes wrong code generation when broadcasting a derived type containing allocatable and non-allocatable scalars. Furthermore does it prevent broadcasting of coarray-tokens, which are always local this_image. Thus having them on a different image makes no sense. Bootstrapped

[Submitted, PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^

Hi Harald, thanks for the fast review. I have submitted as c9c48ab7bad. Will wait for two weeks (reminder set :-)) before backporting to gcc-11. Thank you and regards, Andre On Tue, 25 Jan 2022 22:30:22 +0100 Harald Anlauf via Fortran wrote: > Hi Andre', > > Am 25.01.22 um 17:32 schri

Re: [Submitted, PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^

Hi Tobias, ups, sorry, reverted immediately. Regards, Andre On Fri, 28 Jan 2022 10:27:26 +0100 Tobias Burnus wrote: > Hi Andre, > > your patch breaks bootstrapping: > > ../../repos/gcc/gcc/fortran/trans-array.cc: In function ‘tree_node* > structure_alloc_comps(gfc_symbol*, tree, tree

Re: [Submitted, PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^

Hi Tobias, I don't know why that bootstrapped initially. I fixed the patch (naming a ``` else /* Prevent warning. */ cdesc = NULL_TREE; ``` obvious) and rerun bootstrap making sure to purge everything beforehand. It did not break bootstrap on x86_64-linux/f35. Hope it doesn't elsewhere with

Re: [Backport, committed, PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^

Hi all, two weeks have passed with no complains about the patch for PR103970. Therefore backported and pushed to gcc-11 as 680ee9c3332. Regards, Andre On Fri, 28 Jan 2022 12:39:17 +0100 Andre Vehreschild wrote: > Hi Tobias, > > I don't know why that bootstrapped initially. I fixed the

Re: [Backport gcc-11, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST

Hi everyone, sorry for missing out on the gcc-11 backport, but better late than never. Committed backport as ae57aae60d1. Regards, Andre On Wed, 23 Jun 2021 11:21:45 +0200 Tobias Burnus wrote: > On 23.06.21 10:23, Andre Vehreschild wrote: > > > Will wait two weeks for any errors int

Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran

Ping, ping! Please find attached a rebased version of the patch for the RANDOM_INIT issue with coarray Fortran. Nothing changed to the previous version, just rebased to current master. Regtested fine on x86_64-linux/f33. Ok for trunk? - Andre On Mon, 3 May 2021 08:20:36 -0700 Steve Kargl wrote

[Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST

Hi, the attached patch fixes an issue when calling CO_BROADCAST in -fcoarray=single mode, where the optional but non-present (in the calling scope) stat variable was assigned to before checking for it being not present. Regtests fine on x86-64-linux/f33. Ok for trunk? Regards, Andre -- A

Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran

Hi Steve and Jerry, thanks for the ok'ing. Committed as https://gcc.gnu.org/g:26ca6dbda23bc6dfab96ce07afa70ebacedfaf9c and https://gcc.gnu.org/g:c4771b3438a8cd9afcef1762957b763f8df3fa6e (for the missing changelog entries). - Andre On Fri, 21 May 2021 19:38:00 -0700 Jerry D wrote: > yes, pleas

Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran

every discussion on the mailing lists? Thanks for your help, Andre On Sat, 22 May 2021 19:58:57 +0200 Martin Liška wrote: > On 5/22/21 1:39 PM, Andre Vehreschild via Gcc-patches wrote: > > Hi Steve and Jerry, > > > > thanks for the ok'ing. > > &

[Ping, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST

Ping! On Fri, 21 May 2021 15:33:11 +0200 Andre Vehreschild wrote: > Hi, > > the attached patch fixes an issue when calling CO_BROADCAST in > -fcoarray=single mode, where the optional but non-present (in the calling > scope) stat variable was assigned to before checking for it being not present.

[Patch, Fortran, backport 2 gcc-11] PR98301 Re: RANDOM_INIT() and coarray Fortran

Hi all, I was asked to backport the patch for pr98301 to gcc-11. The patches have been in mainline for two weeks without any defect reports I could fined. The patch for mainline applied with a bit of shift cleanly. Regstested fine on x86_64/f33. Ok for backport gcc-11? Regards, Andre --

Re: [COMITTED, Patch, Fortran, backport 2 gcc-11] PR98301 Re: RANDOM_INIT() and coarray Fortran

Hi Steve, hi all, the patch for pr98301 has been backported to gcc-11 as 002745ca3668fc5e87c22acc81caaeaaadf9c47a Regards, Andre On Sat, 5 Jun 2021 09:27:16 -0700 Steve Kargl wrote: > On Sat, Jun 05, 2021 at 04:04:51PM +0200, Andre Vehreschild wrote: > > > > I was asked to backport the

Re: [Ping, Patch, Fortran, Update 2] PR98301 Re: RANDOM_INIT() and coarray Fortran

Ping! Ok for trunk? I have looked at other patches, but none was patching any location I have worked on previously. Therefore I can't return the favor of reviewing any currently open patches and have to ask for volunteers here. - Andre On Mon, 26 Apr 2021 12:36:36 +0200 Andre Vehreschild via Fo

Re: [Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays

Hi Paul, this and the Changelog LGTM at least for 12. Give it a consolidation time before applying to 11. Having had some issues in the vicinity of the code you addressed I am quite happy to see how easy the fix looks. Any chances you can take a look at https://gcc.gnu.org/pipermail/fortran/

Re: [Ping^2, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST

PING! On Fri, 4 Jun 2021 18:05:18 +0200 Andre Vehreschild wrote: > Ping! > > On Fri, 21 May 2021 15:33:11 +0200 > Andre Vehreschild wrote: > > > Hi, > > > > the attached patch fixes an issue when calling CO_BROADCAST in > > -fcoarray=single mode, where the optional but non-present (in the calli

Re: [Ping^2, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST

Hi Tobias, thanks for the review. To the questions: - I added a test only for -fcoarray=single because in the library case the optional stat is just propagated to the library, which is already tested a lot of times and which needs to handle the optional stat in any case. So an error there

Re: [Ping^2, Patch, Fortran] PR100337 Should be able to pass non-present optional arguments to CO_BROADCAST

Hi all, the fix for PR100337 was submitted as da13e4ebebb07a47d5fb50eab8893f8fe38683df. Thanks for the review Tobias. @Tobias: You are right, caf_single does not get much testing. But this part (not providing a stat) is tested multiple times, because of the laziness. Nearly none of the tests in