Re: [Fortran, Patch, PR119200, v1] Use correct locus while check()ing coarray functions.

Hi Harald, thanks for the review. > this is bordering on the obvious and thus OK, except for: Well, it wasn't so obvious, when was able to add a mistake ;-) I have fixed that and committed as gcc-16-94-gcc2716a3f52. Thanks again for the review, Andre > > @@ -6967,7 +6972,8 @@ gfc_che

Re: [Fortran, Patch, PR119200, v1] Use correct locus while check()ing coarray functions.

Hi Andre, Am 22.04.25 um 15:07 schrieb Andre Vehreschild: Hi all, attached patch fixes an illegal use of gfc_current_locus during the check()-phase of several coarray functions. Instead gfc_current_intrinsic_where needs to be used. this is bordering on the obvious and thus OK, except for: @@

[Fortran, Patch, PR119200, v1] Use correct locus while check()ing coarray functions.

Hi all, attached patch fixes an illegal use of gfc_current_locus during the check()-phase of several coarray functions. Instead gfc_current_intrinsic_where needs to be used. This error does not crash gfortran reliably. But valgrind reports an access to uninitialized memory. I therefore do not know

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

Hi Jerry, hi Paul, thanks for the review. Committed as gcc-16-79-g6e3b92848b5 (for the 6 of 5 commit) on mainline. Thanks again for the fast review. Regards, Andre On Fri, 18 Apr 2025 18:27:03 -0700 Jerry D wrote: > On 4/18/25 9:13 AM, Paul Richard Thomas wrote: > > Hi Andre, > > >

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

On 4/18/25 9:13 AM, Paul Richard Thomas wrote: Hi Andre, On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild > wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request f

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support (was: Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support)

Hi Andre, On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild wrote: > Hi Jerry, > > thanks for the review and sorry for the long delay. With publishing the > team's > patches for gfortran, I also created a pull request for OpenCoarrays. > There I > was asked to add some testcase with more "beef" in

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

On 4/18/25 8:05 AM, Jerry D wrote: On 4/17/25 6:20 AM, Andre Vehreschild wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with more "beef

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

On 4/17/25 6:20 AM, Andre Vehreschild wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with more "beef" in it. I.e. something that really ma

[Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support (was: Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support)

Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with more "beef" in it. I.e. something that really makes use of teams and not only smoke tests it. T

Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

On 4/13/25 11:47 PM, Andre Vehreschild wrote: Hi Jerry, thank you very much for the review. I would love to fix the nits you found, but I don't see, what you see. Can you elaborate? May be some mail client has removed something, or I am missing something. Are you commenting on gfc_error (

Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

Hi Jerry, thank you very much for the review. I would love to fix the nits you found, but I don't see, what you see. Can you elaborate? May be some mail client has removed something, or I am missing something. Are you commenting on > gfc_error ( > "%s argument at %L must be a scalar %s vari

Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

On 4/10/25 5:59 AM, Andre Vehreschild wrote: Hi all, I again have a series of patches. This time to improve the teams support in gfortran. 1/5: Improves/Unifies handling of STAT= and ERRMSG= handling, which is part of all TEAM statements. I wanted to prevent repeating myself over and over so I

[Fortran, Patch, Teams, 1/5] Unify handling of STAT= and ERRMSG= optional arguments [PR87939]

Hi all, this patch unifies handling of STAT= and ERRMSG= for some users of these optional arguments. The first introduction of the arguments seems to stem from SYNC, which choose the rule name sync_stat in the Fortran grammar. Therefore I named the structure and participating routines the same. Th

[Fortran, Patch, Team, 3/5] Update get_team, team_number and image_status to F2018 [PR88154, PR88960, PR97210, PR103001]

Hi all, attached patch reworks GET_TEAM(), TEAM_NUMBER() and IMAGE_STATUS() to adhere to the Fortran 2018 as much as possible and to play nicely with the previous patch of the TEAM statements. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild

[Fortran, Patch, Team, 4/5] Add team-support to this_image [PR87326]

Hi all, attached patch reworks the implementation of THIS_IMAGE() to adhere as much as possible to the Fortran 2018 standard. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From c6da27813d7a7622cae2663af7e25d21e

[Fortran, Patch, Team, 2/5] Improve F2018 TEAM handling [PR87326, PR87556, PR88254, PR103896]

Hi all, attached patch reworks (FORM|CHANGE|END|SYNC) TEAM to implement the Fortran 2018 as much as possible. This work has been done in sync with enhancing the OpenCoarrays library. Because CHANGE TEAM has an association list very similar to ASSOCIATE, the common code has been factored out to imp

[Fortran, Patch, Teams, 5/5] Add teams support in image_index and num_images for F2018

Hi all, attached patch reworks the NUM_IMAGES() implementation to adhere to the Fortran 2018 standard. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 1d0262dc068f4c6018d669a88387dbb7baaff39a Mon Sep 17 00:0

[Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

Hi all, I again have a series of patches. This time to improve the teams support in gfortran. 1/5: Improves/Unifies handling of STAT= and ERRMSG= handling, which is part of all TEAM statements. I wanted to prevent repeating myself over and over so I factored this out (DRY principle). Because the

Re: [Fortran, Patch, PR119380, v1] Fix freeing procedure pointers in components

Hi all, the backport to gcc-14 has been committed as: gcc-14.2.0-996-gf955c5b409a Regards, Andre On Fri, 21 Mar 2025 13:33:37 +0100 Andre Vehreschild wrote: > Hi Paul, > > well, I had those might complicated patches bit my mightily. So let's hope for > the best :-) > > Thanks for the r

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

On 3/20/25 9:20 AM, Andre Vehreschild wrote: Hi all, attached patch fixes a 15-regression where an element of an actual temporary array, i.e., elemental([ e1, e2...]) passed to the formal polymorphic dummy leads to a double free of the derived types components. This patch prevents this by preven

[Fortran, Patch, PR119380, v1] Fix freeing procedure pointers in components

Hi all, attached patch fixes freeing of procedure pointers that are stored in a derived type's component. GFortran did that already for polymorphic types but missed out on the others. Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email:

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

Hi Jerry, thanks for the review and the kind words. Committed as gcc-15-8481-g0f344846a62 Thanks again, Andre On Thu, 20 Mar 2025 11:42:35 -0700 Jerry D wrote: > On 3/20/25 9:20 AM, Andre Vehreschild wrote: > > Hi all, > > > > attached patch fixes a 15-regression where an element of an

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

Hi Andre, I am reasonably familiar with the mess that is gfc_conv_procedure_call :-) So in spite of you having a hard time explaining things today, I see your patch as verging on 'obvious' and is certainly the best that can be done without refactoring the whole thing. OK fo mainline. Thanks for

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

Hi Paul, thanks for the (additional) review. The patch has been merged already as gcc-15-8481-g0f344846a62. But I totally agree, that conv_procedure_call is calling (pun intended) for a refactoring. Thanks again, Andre On Fri, 21 Mar 2025 14:34:13 + Paul Richard Thomas wrote: > Hi

Re: [Fortran, Patch, PR119380, v1] Fix freeing procedure pointers in components

Hi Paul, well, I had those might complicated patches bit my mightily. So let's hope for the best :-) Thanks for the review. Committed with your proposed change in the testcase as gcc-15-8642-ga5c69abf138 Thanks again, Andre On Fri, 21 Mar 2025 10:40:11 + Paul Richard Thomas wrote:

Re: [Fortran, Patch, PR119380, v1] Fix freeing procedure pointers in components

Hi Andre, Gosh, that's a mighty complicated patch :-) I suggest changing the comment in the test case: s/Check that components of procedure pointer aren't freeed./Do not free procedure pointer components/ or some such. OK for mainline and, I propose, 14-branch. Regards and thanks Paul On Fri

[Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

Hi all, attached patch fixes a 15-regression where an element of an actual temporary array, i.e., elemental([ e1, e2...]) passed to the formal polymorphic dummy leads to a double free of the derived types components. This patch prevents this by preventing the deallocation of the array constructors

Re: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi Harald, thanks for the comments. > your solution looks basically correct to me, but I wonder why to > return early w/o error. Would the following logic be wrong? > > @@ -7349,7 +7357,8 @@ resolve_compcall (gfc_expr* e, const char **name) > gfc_symtree* target; > > /* Check that's real

Re: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi Harald and Paul, thanks for the reviews. Committed as gcc-15-8297-g9a13dc48a3a. Paul, I am working on the change team construct at the moment. It has an association list embedded. I will finish that work hopefully soon. After that it will be safe for you to "get out your notes and restart" w/o

Re: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi Andre and Harald, It looks good to me too. Indeed, the associate construct is a strange one since TKR guessing is done at a very early stage so that the associate block can be parsed. About a year ago, I started looking at tackling this by delaying parsing the blocks until the containing block

Re: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi Andre, Am 17.03.25 um 09:56 schrieb Andre Vehreschild: The issue is that the tbp (the typebound proc info structure) is not resolved completely when the associate tries to do an early resolve to determine the rank of the associate variable. When the expression to be resolved for that contains

[Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi all, when Harald attached this PR to the associate meta-bug, I immediately thought: "Oh, this another one of these missing branches on ts.type == BT_CLASS thingies". Well, I was wrong. The issue is that the tbp (the typebound proc info structure) is not resolved completely when the associate t

Re: [Fortran, Patch, PR98903, v1] Add parsing and code gen for TEAM_NUMBER in coindexes.

Hi Harald, thanks for the review. Committed with the requested changes (intrinsic module ISO_FORTRAN_ENV and indexes -> indices in the description) as gcc-15-7997-gbaa9b2b8d2e I haven't added F2023 NOTIFY= image-selector yet, because at the moment I am striving to get F2018 more complete. Thanks

Re: [Fortran, Patch, PR98903, v1] Add parsing and code gen for TEAM_NUMBER in coindexes.

Hi Andre! Am 11.03.25 um 17:13 schrieb Andre Vehreschild: Hi all, attached patch adds parsing of TEAM_NUMBER= named arguments in coindexed expressions. The patch also ensures that once in an image_selector_list no more regular coarray indexes are accepted, i.e. coarray[1,2,3, STAT=S, 5] is reje

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi Harald and Jerry, thanks for taking the time to read my false assumptions ;-) The assumption that v1%n(n:m, m:n) => v2%n(m:n, n:m) is valid in a pointer remapping is wrong. (F2018 §10.2.2.3 paragraph 9). The rhs is neither simply contiguous nor of rank one and therefore rejected. I spent some

[Fortran, Patch, PR98903, v1] Add parsing and code gen for TEAM_NUMBER in coindexes.

Hi all, attached patch adds parsing of TEAM_NUMBER= named arguments in coindexed expressions. The patch also ensures that once in an image_selector_list no more regular coarray indexes are accepted, i.e. coarray[1,2,3, STAT=S, 5] is rejected, because the 5 must not come after any of (STAT, TEAM, T

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi Andre, Am 06.03.25 um 09:15 schrieb Andre Vehreschild: Hi Harald, I try to explain why I think my patch although solving the issue for this case, does not do so in every case: My patch lets dependency analysis figure that the two objects can not have any dependencies on each other or memory

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi Harald, I try to explain why I think my patch although solving the issue for this case, does not do so in every case: My patch lets dependency analysis figure that the two objects can not have any dependencies on each other or memory they are pointing to when the types are different. Lets assu

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi Andre, Jerry already OK'ed your patch, but: Am 05.03.25 um 15:34 schrieb Andre Vehreschild: This fixes the PR, but not really the problem, because when say a obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I don't have a solution for that error. It might be needed to

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

On 3/5/25 6:34 AM, Andre Vehreschild wrote: Hi all, attached patch fixes a gimplification error when a pointer remapping on derived type's components with deferred arrays is made. The issue boiled down to the dependency analysis being to loose. It saw a dependency as soon as both sides of the =>

[Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi all, attached patch fixes a gimplification error when a pointer remapping on derived type's components with deferred arrays is made. The issue boiled down to the dependency analysis being to loose. It saw a dependency as soon as both sides of the => had a derived type, independent of the actual

Re: [Fortran, Patch, PR104684, v1] Fix gimple error when pointer assigning alloc array.

Hi Harald, thanks for the review. Committed as gcc-15-7826-g705ae582d51. The fix for pr107143 may be something similar. I am having a harder time getting a testcase correct, then fixing the gimplification fault (that's fixed, but the test is fouling me). Thanks again, Andre On Tue, 4 Ma

Re: [Fortran, Patch, PR104684, v1] Fix gimple error when pointer assigning alloc array.

Hi Andre, Am 04.03.25 um 17:11 schrieb Andre Vehreschild: Hi all, attached patch fixes a gimplification fault when a pointer assignment to an allocatable array is done. The tree type is different, because of that flag in the lang_specific structure. View-converting the type fixes the issue. Re

[Fortran, Patch, PR104684, v1] Fix gimple error when pointer assigning alloc array.

Hi all, attached patch fixes a gimplification fault when a pointer assignment to an allocatable array is done. The tree type is different, because of that flag in the lang_specific structure. View-converting the type fixes the issue. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Reg

Re: [Fortran, Patch, PR103391, v1] Fix gimple error on assign to pointer array.

Hi Paul, thanks for the review. Committed as gcc-15-7812-g04909c7ecc0. Yes please: you do the backport. Thank you very much. I am looking at pr104684 at the moment, which is the last regression on my list (i.e. that I am assigned or cc'ed to). When the regression test for this is fine, I will co

Re: [Fortran, Patch, PR103391, v1] Fix gimple error on assign to pointer array.

Hi Andre, You beat me to it! I had just noticed the missing indirect reference. Yes, this is good for mainline and backporting to 14-branch at very least. Thanks for the patch. If you want to do the push to mainline, I will do the backporting if you like? I'll not be back at base for a little whi

[Fortran, Patch, PR103391, v1] Fix gimple error on assign to pointer array.

Hi all, attached patch fixes a 12-regression when an assignment to a pointer array is done. The issue was a missing indirect ref on assign as it was already done for allocatable arrays. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email

Re: [Fortran, Patch, PR77872, v1] Fix ICE when getting caf-token from abstract class type.

Hi Steve, thanks for the review. Committed as gcc-15-7804-g5bd66483839. Thanks again, Andre On Mon, 3 Mar 2025 12:34:49 -0800 Steve Kargl wrote: > On Mon, Mar 03, 2025 at 03:58:24PM +0100, Andre Vehreschild wrote: > > > > attached patches fix a 12-regression, when a caf token is reques

Re: [Fortran, Patch, PR77872, v1] Fix ICE when getting caf-token from abstract class type.

On Mon, Mar 03, 2025 at 03:58:24PM +0100, Andre Vehreschild wrote: > > attached patches fix a 12-regression, when a caf token is requested from an > abstract class-typed dummy. The token was not looked up in the correct spot. > Due the class typed object getting an artificial variable for direct d

[Fortran, Patch, PR77872, v1] Fix ICE when getting caf-token from abstract class type.

Hi all, attached patches fix a 12-regression, when a caf token is requested from an abstract class-typed dummy. The token was not looked up in the correct spot. Due the class typed object getting an artificial variable for direct derived type access, the get_caf_decl was looking at the wrong decl.

Re: [Fortran, Patch, PR118747, v1] Prevent double free alloc. comp. in derived type function results

Hi Paul, thanks for the review. Committed as gcc-15-7789-g43c11931acc. The regression is tagged as 15-regression only and was caused by PR fortran/90068. At least the change in trans-array.cc:2000-.. is one of major causes for that regression. Thanks again, Andre On Sat, 1 Mar 2025 08:0

Re: [Fortran, Patch, PR118747, v1] Prevent double free alloc. comp. in derived type function results

Hi Andre, This looks fine to me. You say that this is a regression. How far back does it go? OK for mainline and, if required, for backporting. Thanks for the patch. Paul On Fri, 28 Feb 2025 at 15:54, Andre Vehreschild wrote: > Hi all, > > on this regression I had to chew a longer time. Ass

[Fortran, Patch, PR118747, v1] Prevent double free alloc. comp. in derived type function results

Hi all, on this regression I had to chew a longer time. Assume this Fortran: type T integer, allocatable:: a end type T result(type T) function bar() allocate(bar%a) end function call foo([bar()]) That Fortran fragment was translated to something like (pseudo code): T temp; T arr[]; temp

Re: [Fortran, Patch, PR118730, v1] Ensure user-finalized type is referenced

Hi Harald, thanks for the review. Committed as gcc-15-7747-gc1606e383a3. Thanks again, Andre On Thu, 27 Feb 2025 21:13:08 +0100 Harald Anlauf wrote: > Hi Andre, > > Am 27.02.25 um 18:36 schrieb Andre Vehreschild: > > Hi all, > > > > attached patch fixes user defined finalizers in deriv

Re: [Fortran, Patch, PR118730, v1] Ensure user-finalized type is referenced

Hi Andre, Am 27.02.25 um 18:36 schrieb Andre Vehreschild: Hi all, attached patch fixes user defined finalizers in derived (class) types not getting called, when the variable declared of that type was not used in the current block. The patch ensures calling the finalizer by marking the variable

[Fortran, Patch, PR118730, v1] Ensure user-finalized type is referenced

Hi all, attached patch fixes user defined finalizers in derived (class) types not getting called, when the variable declared of that type was not used in the current block. The patch ensures calling the finalizer by marking the variable referenced, if it has not been. Additionally I had to patch

Re: [Fortran, Patch, PR118789, v1] Fix associate to void*

Hi Thomas, thanks for the review. Committed as gcc-15-7726-g0fc1abcc46e. Thanks again, Andre On Wed, 26 Feb 2025 21:40:51 +0100 Thomas Koenig wrote: > Hi Andre, > > > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > > Looks good to me. > > Thanks for the patch! > > Best reg

Re: [Fortran, Patch, PR118789, v1] Fix associate to void*

Hi Andre, Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Looks good to me. Thanks for the patch! Best regards Thomas

[Fortran, Patch, PR118789, v1] Fix associate to void*

Hi all, here is my shot on fixing this PR. The issue is, that when checking if the tree to associate to is a pointer, gfortran does not respect void* aka c_ptr correctly. On the tree level this can be done by checking the compatibility of the data pointed to. If not, then just add an address op.

Re: [Fortran, Patch, PR108233, v1] Prevent SAVE_EXPR on lhs in assign.

Hi Jerry, thanks for the review. Committed as gcc-15-7712-g751b37047b2. Thanks again, Andre On Tue, 25 Feb 2025 09:49:29 -0800 Jerry D wrote: > On 2/25/25 9:18 AM, Andre Vehreschild wrote: > > Hi all, > > > > for some recreation after all the coarray stuff, I found this pr cc'ed to > >

Re: [Fortran, Patch, PR108233, v1] Prevent SAVE_EXPR on lhs in assign.

On 2/25/25 9:18 AM, Andre Vehreschild wrote: Hi all, for some recreation after all the coarray stuff, I found this pr cc'ed to me. Taking a look at it, I figured that using a SAVE_EXPR on the lhs of the assignment was doing the harm. The data seems to be not written back into the vector shaped d

[Fortran, Patch, PR108233, v1] Prevent SAVE_EXPR on lhs in assign.

Hi all, for some recreation after all the coarray stuff, I found this pr cc'ed to me. Taking a look at it, I figured that using a SAVE_EXPR on the lhs of the assignment was doing the harm. The data seems to be not written back into the vector shaped data type (like a complex number in this case).

Re: [Fortran, Patch, PR107635, 4_v2] Fix class type and descriptor handling for new coarray interface [PR107635]

Hi Harald, thanks for the review. Committed this and the other patch as gcc-15-7694-gaf73228fdb2. Thanks again, Andre On Mon, 24 Feb 2025 20:22:17 +0100 Harald Anlauf wrote: > Hi Andre, > > Am 24.02.25 um 16:44 schrieb Andre Vehreschild: > > Hi Harald, > > > > I have added some comment

Re: [Fortran, Patch, PR107635, 4_v2] Fix class type and descriptor handling for new coarray interface [PR107635]

Hi Harald, Oops, I've mixed up the two attachments. Sorry for that and thank you for detecting it and ok'ing. I will merge tomorrow morning. Thanks again, Andre Andre Vehreschild * ve...@gmx.de Am 24. Februar 2025 20:22:25 schrieb Harald Anlauf : Hi Andre, Am 24.02.25 um 16:44 schrieb Andre V

Re: [Fortran, Patch, PR107635, 4_v2] Fix class type and descriptor handling for new coarray interface [PR107635]

Hi Andre, Am 24.02.25 um 16:44 schrieb Andre Vehreschild: Hi Harald, I have added some comment(s). Can you take another look? assuming that you refer to the attachment of the other submission: that one is perfect! This one is also OK. Thanks for the patch(es)! Harald Regtested ok on x86_

Re: [Fortran, Patch, PR107635, 4_v2] Fix class type and descriptor handling for new coarray interface [PR107635]

Hi Harald, I have added some comment(s). Can you take another look? Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre On Sat, 22 Feb 2025 17:36:55 +0100 Andre Vehreschild wrote: > Hi Harald, > > thanks for the review. Silently I'd hoped that there is some macr

[Fortran, Patch, PR107635, 5_v1] Use correct data size in caf_transfer_between_remotes

Hi all, I nearly forgot to publish this patch: When transfering data between two remote images, i.e. a third images asks image one to read some data and then asks image two to put that data into its memory, the size of the data to transfer between these two images was miscalculated. The attached

Re: [Fortran, Patch, PR107635, 4_v1] Fix class type and descriptor handling for new coarray interface [PR107635]

Hi Harald, thanks for the review. Silently I'd hoped that there is some macro to get the i-th argument, that I just haven't found and someone could point me to. I will add a comment, when ko one comes up with the macro by Monday. Thanks, Andre Andre Vehreschild * ve...@gmx.de Am 22. Februar 2025

Re: [Fortran, Patch, PR107635, 4_v1] Fix class type and descriptor handling for new coarray interface [PR107635]

Hi Andre, Am 21.02.25 um 14:35 schrieb Andre Vehreschild: Hi all, during testing and compiling some larger coarray codes, I found a few deficiencies. One was with handling class types when splitting the coarray expression and the other was that the backend_decl of a formal argument in a functio

[Fortran, Patch, PR107635, 4_v1] Fix class type and descriptor handling for new coarray interface [PR107635]

Hi all, during testing and compiling some larger coarray codes, I found a few deficiencies. One was with handling class types when splitting the coarray expression and the other was that the backend_decl of a formal argument in a function's symbol was not the same as the one the function was compi

Re: 6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes

Hi Andre, > thanks for testing and also for giving a solution. I was sure, I would break > something. Fixed as obvious as gcc-15-7662-g08bdc2ac98a after regtesting ok on > x86_64-pc-linux-gnu / Fedora 41 (which gets more unstable with every update I > receive IMO). I opted for the __builtin_alloca

Re: 6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes

Hi Rainer, thanks for testing and also for giving a solution. I was sure, I would break something. Fixed as obvious as gcc-15-7662-g08bdc2ac98a after regtesting ok on x86_64-pc-linux-gnu / Fedora 41 (which gets more unstable with every update I receive IMO). I opted for the __builtin_alloca versio

Re: 6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes

Hi Andre, this patch broke Solaris bootstrap: /vol/gcc/src/hg/master/local/libgfortran/caf/single.c: In function ‘_gfortran_caf_transfer_between_remotes’: /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:675:23: error: implicit declaration of function ‘alloca’ [-Wimplicit-function-declarat

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

Hi all, I just merged the patch series as gcc-15-7644-gd3244675441. Thanks for all the reviews. I will now prepare the Relasenotes. Regards and thanks again, Andre On Tue, 18 Feb 2025 18:13:53 +0100 Thomas Koenig wrote: > Am 18.02.25 um 16:00 schrieb Andre Vehreschild: > > Hi Thomas,

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

Am 18.02.25 um 16:00 schrieb Andre Vehreschild: Hi Thomas, This patch series (of necessity) introduces ABI changes. What will happen with user code compiled against the old interface? That depends on the library you are linking against. When using caf_single from gfortran, then you will get

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

Hi Thomas, > This patch series (of necessity) introduces ABI changes. What will > happen with user code compiled against the old interface? That depends on the library you are linking against. When using caf_single from gfortran, then you will get link failures when you mix code compiled by gfor

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

Hi Jerry, thank you very much for taking on the job of reviewing and sorry for my late answer. In fact, I was having a hard time figuring regressions in the OpenCoarrays library. This also answers your first question: Yes, OpenCoarrays will make use of the new interface. Most of the changes in th

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

Am 14.02.25 um 19:19 schrieb Jerry D: I think this is good to commit. (all 7 parts) I think so too, with one caveat... Does anyone else have any comments? This patch series (of necessity) introduces ABI changes. What will happen with user code compiled against the old interface? I guess

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

On 2/13/25 11:48 AM, Jerry D wrote: On 2/10/25 2:25 AM, Andre Vehreschild wrote: [PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635] I have applied all patches. Regression tested OK here. From patch 5 there was one reject: patching file gcc/testsuite/gfortran.dg/coarray/send

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

On 2/10/25 2:25 AM, Andre Vehreschild wrote: [PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635] I have applied all patches. Regression tested OK here. From patch 5 there was one reject: patching file gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90 Hunk #1 FAILED at 39

Re: 1/7 [Fortran, Patch, Coarray, PR107635] Move caf_get-rewrite to rewrite.cc

On 2/10/25 2:25 AM, Andre Vehreschild wrote: [PATCH 1/7] Fortran: Move caf_get-rewrite to rewrite.cc [PR107635] Add a rewriter to keep all expression tree manipulation that is not optimization together. At the moment this is just a move from resolve.cc, but will be extended to handle more cases

3/7 [Fortran, Patch, Coarray, PR107635] Allow to use non-pure/non-elemental functions in coarray indexes

[PATCH 3/7] Fortran: Allow to use non-pure/non-elemental functions in coarray indexes [PR107635] Extract calls to non-pure or non-elemental functions from index expressions on a coarray. gcc/fortran/ChangeLog: PR fortran/107635 * rewrite.cc (get_arrayspec_from_expr): Treat arra

5/7 [Fortran, Patch, Coarray, PR107635] Add send_to_remote

[PATCH 5/7] Fortran: Add send_to_remote [PR107635] Refactor to use send_to_remote instead of the slow send_by_ref. gcc/fortran/ChangeLog: PR fortran/107635 * gfortran.h (enum gfc_isym_id): Add SENDGET-isym. * gfortran.texi: Add documentation for send_to_remote. *

6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes

[PATCH 6/7] Fortran: Add transfer_between_remotes [PR107635] Add the last missing coarray data manipulation routine using remote accessors. gcc/fortran/ChangeLog: PR fortran/107635 * gfortran.texi: Add documentation for transfer_between_remotes. * intrinsic.cc (add_subro

4/7 [Fortran, Patch, Coarray, PR107635] Add caf_is_present_on_remote.

[PATCH 4/7] Fortran: Add caf_is_present_on_remote. [PR107635] Replace caf_is_present by caf_is_present_on_remote which is using a dedicated callback for each object to test on the remote image. gcc/fortran/ChangeLog: PR fortran/107635 * gfortran.h (enum gfc_isym_id): Add caf_is_

2/7 [Fortran, Patch, Coarray, PR107635] Prepare for more caf-rework.

[PATCH 2/7] Fortran: Prepare for more caf-rework. [PR107635] Factor out generation of code to get remote function index and to create the additional data structure. Rename caf_get_by_ct to caf_get_from_remote. gcc/fortran/ChangeLog: PR fortran/107635 * gfortran.texi: Rename caf

1/7 [Fortran, Patch, Coarray, PR107635] Move caf_get-rewrite to rewrite.cc

[PATCH 1/7] Fortran: Move caf_get-rewrite to rewrite.cc [PR107635] Add a rewriter to keep all expression tree manipulation that is not optimization together. At the moment this is just a move from resolve.cc, but will be extended to handle more cases where rewriting the expression tree may be eas

0/7 [Fortran, Patch, Coarray, PR107635] Implement call to remote side routine for caf

Hi all, this small series of patches adds/changes the way coarray access to data on remote images is done. Previously for more elaborate access pattern (e.g. an allocatable array in a derived type component stored in an array) the access was done by emulating Fortran's addressing in C. When using

Re: [Ping, Fortran, Patch, PR114612, v1] Fix missing deep-copy for allocatable components of derived types having cycles.

Hi Jerry, thanks again for the review. Pushed as gcc-15-6618-g25b380dc63c. Regards, Andre On Mon, 6 Jan 2025 09:15:39 -0800 Jerry D wrote: > On 1/6/25 2:08 AM, Andre Vehreschild wrote: > > Hi all, > > > > attached patch has been rebased to latest trunk. Just pinging! > > > > Regtests o

Re: [-Ping-, Fortran, Patch, PR116669, v3] Fix ICE in deallocation of derived types having cyclic dependencies

Hi Jerry, thanks for the review. Pushed as gcc-15-6615-gd8970909490 with the tweak ;-) Have a good year and thanks again, Andre On Mon, 6 Jan 2025 09:13:27 -0800 Jerry D wrote: > On 1/6/25 6:21 AM, Andre Vehreschild wrote: > > Hi all, > > > > during looking for something completely di

Re: [Ping, Fortran, Patch, PR114612, v1] Fix missing deep-copy for allocatable components of derived types having cycles.

On 1/6/25 2:08 AM, Andre Vehreschild wrote: Hi all, attached patch has been rebased to latest trunk. Just pinging! Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? - Andre On Fri, 13 Dec 2024 12:10:58 +0100 Andre Vehreschild wrote: Hi all, attached patch fixes deep-copying (or r

Re: [-Ping-, Fortran, Patch, PR116669, v3] Fix ICE in deallocation of derived types having cyclic dependencies

On 1/6/25 6:21 AM, Andre Vehreschild wrote: Hi all, during looking for something completely different, I figured, that gcc does not use std::set internally, but its implementation of hash_set. I therefore adapted the patch to use it. Nothing more changed. Still regtests ok on x86_64-pc-linux-gn

Re: [Ping, Fortran, Patch, PR116669, v1] Fix ICE in deallocation of derived types having cyclic dependencies

On 1/6/25 2:06 AM, Andre Vehreschild wrote: Hi all, pinging attached rebased patch. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? - Andre On Thu, 12 Dec 2024 14:50:13 +0100 Andre Vehreschild wrote: Hi all, attached patch improves analysis of cycles in derived types, i.e. type

Re: [-Ping-, Fortran, Patch, PR116669, v3] Fix ICE in deallocation of derived types having cyclic dependencies

Hi all, during looking for something completely different, I figured, that gcc does not use std::set internally, but its implementation of hash_set. I therefore adapted the patch to use it. Nothing more changed. Still regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, An

Re: [Ping, Fortran, Patch, PR114612, v1] Fix missing deep-copy for allocatable components of derived types having cycles.

Hi all, attached patch has been rebased to latest trunk. Just pinging! Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? - Andre On Fri, 13 Dec 2024 12:10:58 +0100 Andre Vehreschild wrote: > Hi all, > > attached patch fixes deep-copying (or rather its former absence) for > allocatabl

Re: [Ping, Fortran, Patch, PR116669, v1] Fix ICE in deallocation of derived types having cyclic dependencies

Hi all, pinging attached rebased patch. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? - Andre On Thu, 12 Dec 2024 14:50:13 +0100 Andre Vehreschild wrote: > Hi all, > > attached patch improves analysis of cycles in derived types, i.e. type > dependencies ala: > > type(T) > type(

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

On 12/30/24 12:34 AM, Paul Richard Thomas wrote: Hi Jerry, With such an illustrious group of contributors, I can hardly say 'no', can I? :-) It looks fine to me - OK for trunk. Regards Paul Thanks Paul. Special thanks to Steve for taking this on. commit efc0981077a70c4de4596f682c4aeade0

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

Hi Jerry, With such an illustrious group of contributors, I can hardly say 'no', can I? :-) It looks fine to me - OK for trunk. Regards Paul On Sun, 29 Dec 2024 at 23:10, Jerry D wrote: > Attached is the revised patch incorporating handling of optional > arguments of a calling procedure and

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

Attached is the revised patch incorporating handling of optional arguments of a calling procedure and simplified checking for C interoperability. See the PR for much discussion. Regression tested on x86_64_linux_gnu. Two test cases. OK for trunk? Author: Steven G. Kargl Date: Sun Dec 29

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

Hi Steve, Am 18.12.24 um 22:37 schrieb Steve Kargl: So, it seems that this section of the patch + gfc_init_se (&asis_se, se); + gfc_conv_expr (&asis_se, asis); + gfc_add_block_to_block (&se->pre, &asis_se.pre); + tmp = fold_build3_loc (input_location, COND_EXPR,

  1   2   3   4   5   6   7   >