Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.

em in the beginning. I must have done something wrong. Please accept my apologies and regards, Andre On Fri, 29 Sep 2023 15:13:56 +0200 Andre Vehreschild via Fortran wrote: > Hi Paul, > > thanks. Commit to trunk as a680274616ec6b26ccfdcee400ed7f54e341d40c > and backpo

Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.

i Andre, > > > > > > The patch looks fine to me. Since you mention it in the comment, is it > > > worth declaring the derived type 'foo' in a module and giving it a > > > final routine? > > > > > > Thanks for the patch. > > > >

Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.

> > The patch looks fine to me. Since you mention it in the comment, is it > worth declaring the derived type 'foo' in a module and giving it a > final routine? > > Thanks for the patch. > > Paul > > On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fo

[Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.

Hi all, attached patch fixes a crash in coarray programs when an allocatable derived typed coarray was freed explicitly. The generated cleanup code did not take into account, that the coarray may have been deallocated already. The patch fixes this by moving the statements accessing components insi

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

Hi all, hi Harald, thanks for the review. I choose to use gfc_replace_expr() and retested. Everything went fine now. Also thank you clarifying the pdt as a component in a derived type and that that is still a bug and I didn't do it wrong. I have pushed the attached patch seconds ago. Thanks for

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] 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

[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: Possible funding of gfortran work

Hi Mikael, please find my answers inline. > > I understand. I would have been happy in the past when a client had as much > > knowledge and structure than we already have. Under "Project goal" we now > > have about 300 words. So we could add more. > Well, It wouldn't be really part of the goal, m

Re: Possible funding of gfortran work

Hi Benson, thanks for the input. I will incorporate it. Regards, Andre On Thu, 8 Jun 2023 08:34:54 +0300 Benson Muite wrote: > On 6/5/23 13:07, Andre Vehreschild wrote: > > Hi Benson, > > > > thank you for your input. Comments are inline: > > > >> Maybe add Quantum Espresso: > >> https

Re: Possible funding of gfortran work

Hi Mikael, ... > Yes, I don't like it but I understand the need for estimating. > I have looked at the evaluation criteria at [1]. There is among other > things: > > Furthermore, we look at how well the planning for the project is laid out. > > Are the activities well-structured, appropriate and

Re: Possible funding of gfortran work

I have referenced LAPACK now. I hope this is ok? - Andre On Mon, 5 Jun 2023 14:16:43 +0200 Thomas Koenig wrote: > On 05.06.23 12:07, Andre Vehreschild wrote: > >> R and Octave may also be good examples of use cases. > > Mhhh, both are not written in Fortran, right? > > They are not, but at leas

Re: Possible funding of gfortran work

Hi Thomas, thanks for the idea. My doctor father will like it, because he is one of the authors. - Andre On Sun, 4 Jun 2023 09:49:51 +0200 Thomas Koenig wrote: > On 01.06.23 13:12, Benson Muite via Fortran wrote: > > > R and Octave may also be good examples of use cases. > > More generally, La

Re: Possible funding of gfortran work

Hi Jerry, thanks. I switched from FAST to OpenFAST in the list of references. Strangely my google search never pointed me to OpenFAST. Regards, Andre On Thu, 1 Jun 2023 17:53:21 -0700 Jerry D wrote: > On 6/1/23 2:18 AM, Andre Vehreschild wrote: > > Hi Damian, all, > > > > thank you for

Re: Possible funding of gfortran work

Hi Benson, thank you for your input. Comments are inline: > Maybe add Quantum Espresso: > https://www.quantum-espresso.org/ done > R and Octave may also be good examples of use cases. Mhhh, both are not written in Fortran, right? I don't feel tempted to include other programming languages into

Re: Possible funding of gfortran work

Hi Mikael, thanks for your valuable input. I have commented inline: > The latter paragraph seems more an answer to the question "why is it > critical for gfortran to get funding" than "why is it critical for a > funding body to choose gfortran"? > > One idea about the latter question: > so tha

Re: Possible funding of gfortran work

Hi Damian, all, thank you for your input. I have incorporated most of it. Due to Germany stepping out of nuclear use, I have reduced the cites on these to a minimum. I don't know anything about the people evaluating the proposal and don't want to be rejected just because of ideological reasons. He

Re: Possible funding of gfortran work

Hi Thomas, I have revamp the proposal a bit more. Thank you for your input. I took some of it "as is", but I also rephrased some of it. I hope you are ok with that. Here is what I have so far: --- - Title: GFortran-Improvement - Abstract: Enable the free gfortran compiler to support contempora

Re: Possible funding of gfortran work

Hi all, thank you for all your input. I have read the funding requirements and checked out the application form. We have to agree on a project goal and describe why it is critical to fund this project. Let me try a first shot on this: - Title: GFortran-Improvement - Abstract: Enable the free

Re: Possible funding of gfortran work

Hi Thomas, working full-time on a gfortran engagement would be possible for me. Given that my company is Germany based and we have some capacity, that would be feasible for us. We also have some knowledge about how to invoice authorities, which can be a bit difficult sometimes. So I regard coarr

Re: is there a way to find out gfortran version and/or options from a given binary?

Hi Kay, did you try: $ strings coarray_collectives_18 | grep GNU GCC: (GNU) 11.2.1 20211203 (Red Hat 11.2.1-7) GCC: (GNU) 12.0.1 20220214 (experimental) GNU Fortran2008 12.0.1 20220214 (experimental) -mtune=generic -march=x86-64 -g -fcoarray=lib -fintrinsic-modules-path /home/vehre/Projekte/gcc/

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: [Backport, committed, PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^

237fb5b8. > > Thanks for pointing this out. > > Regards, > Andre > > On Fri, 28 Jan 2022 10:36:23 +0100 > Andre Vehreschild via Fortran wrote: > > > Hi Tobias, > > > > ups, sorry, reverted immediately. > > > > Regards, >

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

where with submit 26e237fb5b8. Thanks for pointing this out. Regards, Andre On Fri, 28 Jan 2022 10:36:23 +0100 Andre Vehreschild via Fortran wrote: > Hi Tobias, > > ups, sorry, reverted immediately. > > Regards, > Andre > > On Fri, 28 Jan 2022 10:

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

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 schrieb Andre Vehreschild via Fortran: > >>> Hi all, &g

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

01.22 um 17:32 schrieb Andre Vehreschild via Fortran: > > 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,

[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

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

the testsuite provides a variable for stat. Will wait two weeks for any errors introduced by this patch before backporting to gcc-11, ok? Regards, Andre On Tue, 22 Jun 2021 10:37:27 +0200 Tobias Burnus wrote: > Hi Andre, > > On 22.06.21 09:40, Andre Vehreschild via Fort

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

UM: > and, with -fcoarray=single, errmsg is not touched > as stat is (unconditionally) 0 (success).. > > > On 19.06.21 13:23, Andre Vehreschild via Fortran wrote: > > PING! > > > > On Fri, 4 Jun 2021 18:05:18 +0200 > > Andre Vehreschild wrote: > >

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: [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

[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 --

[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.

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

Hi Martin, thanks for pointing that out. I haven't committed for quite some time now and could not find on the webpage how this works nowadays. I was thinking that the special gcc-git-command should have added the Changelog entries automagically and immediately. That they are added by a daily bump

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

[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

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

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, 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 Vehreschil

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

Hi Steve, hi all, I agree. The cas-things have been removed (I will put the patch for them into the pr98301 ticket, so safe them), streamlining the patch a bit more. Bootstraped and regtested ok on x86_64-linux/f33. Ok for trunk? Regards, Andre Steve Kargl PR fortran/98301 - random_

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

Ok, I changed it in the log-file already. - Andre On Sat, 24 Apr 2021 08:44:24 -0700 Steve Kargl wrote: > On Sat, Apr 24, 2021 at 12:49:45PM +0200, Andre Vehreschild wrote: > > > > @Steve: Is this your correct mail address for the changelog or do you > > prefer a different one? > > > > I s

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

Hi Steve, hi all, thank you for pointing that out, Steve. When I started the work, I told myself, that I have to remember to add your patch to the submit. Well, that did not last for more than eight hours and I had forgotten. So here is now the combination of Steve's and my patch (attached). Boo

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

Hi folks, please find attached the library part for supporting RANDOM_INIT for coarray=lib enabled fortran translations. There is also a patch for the Opencoarray library to add RANDOM_INIT there. I am not sure, whether I have modified the gfortran.map file in the libgfortran directory correctly,