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

to 16th master? Regards, Andre On Sun, 13 Apr 2025 18:40:44 -0700 Jerry D wrote: > 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: I

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

ix? I just want to prevent overlooking some typo or the like. Thanks again and regards, Andre On Sun, 13 Apr 2025 18:40:44 -0700 Jerry D wrote: > On 4/10/25 5:59 AM, Andre Vehreschild wrote: > > Hi all, > > > > I again have a series of patches. This time to improve

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

? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From b329c2d35cbc4a5ecf0445811f1236ef3c9e9611 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Fri, 14 Mar 2025 14:20:18 +0100 Subject: [PATCH 1/6] Fortran: Unify handling of STAT= and ERRMSG= optional arguments [PR87939

[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

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

implement the DRY principle. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 64c951fd2f64f5d4407076532fd57e8370254826 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Mon, 7 Apr 2025 09:36:24 +0200

[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

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

g and treatment as well as adding testcases and support in caf_single. 5/5: Update image_index() and num_images() support also in caf_single. All patches together have been bootstrapped and regtested ok on x86_64-pc-linux-gnu. Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs

.. DIM and the rank ... ??? > > > > Yes, 0 < dim <= ARRAY->rank being asserted. Sorry, for being imprecise, but I think there is an "in" too much in the error message! - Andre -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs

e precise. Just an idea. Please check your Changelog for style. When I am not mistaken, then a . has to be followed by two spaces. Or did this change? I like to use git gcc-verify on my commit message. That points out some easy to spot oversights. Besides those minor nits: Looks good to me. Ok to merge, when reports have verified. Thanks for the patch, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de

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 :-) &

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

Re: [PATCH] Fortran: fix bogus recursion with DT default initialization [PR118796]

Hi Harald, looks good to me. Thanks for the patch. - Andre Andre Vehreschild * ve...@gmx.de Am 26. März 2025 22:18:41 schrieb Harald Anlauf : Dear all, it seems that my patch for default-initialization of function results of derived type could trigger a weird issue if a type-bound function

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

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

le thing. > > OK fo mainline. > > Thanks for the patch > > Paul > > > On Thu, 20 Mar 2025 at 16:36, Andre Vehreschild wrote: > > > Hi all, > > > > attached patch fixes a 15-regression where an element of an actual > > temporary array, i.e., elemen

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

and, I propose, 14-branch. > > Regards and thanks > > Paul > > > On Fri, 21 Mar 2025 at 09:38, Andre Vehreschild wrote: > > > Hi all, > > > > attached patch fixes freeing of procedure pointers that are stored in a > > derived > > type&#

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

aving a hard time explaining things today. So I hope the code above will do. Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 8f9c24fe01a1e34bea2e1c95102329562abdb9e1 Mon Sep 17 00:00:00 2001 From: Andre Ve

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

s opinion is, but nevertheless feel free to voice up, if I did something wrong or mis-unterstood your intention. Thanks for looking at this and Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de

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

:-) > > In the meantime, this is more than band-aid, it is a necessary correction, > given the way associate is parsed. > > Regards and thanks for the patch > > Paul > > > On Tue, 18 Mar 2025 at 22:08, Harald Anlauf wrote: > > > Hi Andre, > > > &

Re: [Patch, fortran] PR85836: Implement the F2018 reduce intrinsic

cause > the .note.GNU-stack section is executable) > I think that this is unlikely to present a security issue, however, since > it disappears at -O1, I went through each of the options triggered by -O1 > but couldn't make it go away. Does anybody know why this is? > > Regtests OK with FC41/x86_64 - OK for mainline? > > Regards > > Paul -- Andre Vehreschild * Email: vehre ad gmx dot de

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

r mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 97eb018d0bc6f86d039d05d9e5d6be114f784c6d Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Mon, 17 Mar 2025 08:24:04 +0100 Subject: [PATCH] Fortran: Fix comp call in associate [PR119272] PR fortran/119272 g

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

complete. Thanks again for the review. Regards, Andre On Tue, 11 Mar 2025 21:49:05 +0100 Harald Anlauf wrote: > Hi Andre! > > Am 11.03.25 um 17:13 schrieb Andre Vehreschild: > > Hi all, > > > > attached patch adds parsing of TEAM_NUMBER= named arguments in coinde

Regression? Re: [patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

investigate, if I am right? Regards, Andre On Tue, 11 Mar 2025 17:45:16 +0100 Thomas Koenig wrote: > Am 11.03.25 um 10:22 schrieb Andre Vehreschild: > > Hi Thomas, > > > > looks good to me as well. Thanks for the patch. > > Committed as r15-7964. > >

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

PING! On Thu, 20 Feb 2025 10:54:30 +0100 Andre Vehreschild wrote: > Hi all, > > attached patch makes an attempt to announce the ABI-changes in the coarrays > library. Me being German always has difficulties to find a proper wording. So > please propose improvements. > > St

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

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

used, but left them out of the test, because those are addressed in PR87326. That PR is not yet merged. I intent to rebase, complete/adapt and merge it next. Then also caf_single gets support for team expressions. And of course OpenCoarrays. Regards, Andre -- Andre Vehreschild * Email

Re: [patch, fortran] Fix PR 119078, putting a procedure in an abstract interface into global namespace

t, here it is. > > Best regards > > Thomas -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

ote: > > On 3/10/25 1:08 AM, Andre Vehreschild wrote: > >> Hi Steve and Jerry, > >> > >> thanks for the review and the proposed changes. I have based on them, but > >> needed to adapt some places, because the meaning was changed. Can you > >> please &g

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

an html check script provided. You can also review > by looking with a web browser. > > For texi files, if make info succeeds and review the resulting info > files installed in the usr/share if I recall correctly. > > Jerry -- Andre Vehreschild * Email: vehre ad gmx dot de F

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

t; 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'

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

r that error. It might be needed to prevent generating the parm.NN variable for the lhs, because that is mostly useless there. (Or I don't understand (yet) how to use it). Regstests ok on x86_64-pc-linux-gnu / F41. Ok for mainline or other suggestions? Regards, Andre -- Andre Vehresch

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

ue, 4 Mar 2025 22:58:37 +0100 Harald Anlauf wrote: > 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 diff

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

? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 3acd5266f70c29d6b2b3078e122f61f6537b602d Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Tue, 4 Mar 2025 17:06:31 +0100 Subject: [PATCH] Fortran: Add view convert to pointer assign when only pointer/alloc attr

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

l be a suitable delay. > I have several Steinmetz sourced regression fixes to bring to the list in > the next days. > > Cheers > > Paul > > > On Tue, 4 Mar 2025 at 12:02, Andre Vehreschild wrote: > > > Hi all, > > > > attached patch fixes a 12-regression

[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

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

Re: [patch, Fortran] Fix PR 119049 and 119074, external prototypes with different arglists

to C23). > > Regression-tested. > > Comments? Suggestions for better wordings? Is -Wall too strong, > should this be -Wextra (but then nobody would see it, probably...)? > OK for trunk? > > Best regards > > Thomas -- Andre Vehreschild * Email: vehre ad gmx dot de

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

. This patch consists of two parts, the first is just some code complexity reduction, where an existing attr is now used instead of checking for BT_CLASS type and branching. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad

Re: [PATCH] Fortran: reject empty derived type with bind(C) attribute [PR101577]

e J3 ML that > there was a defect in older standards. The attached patch > now generates an error when -std=f20xx is specified, and > continues to generate a warning otherwise. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > -- Andre Vehreschild * Email: vehre ad gmx dot de

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

:09:46 + Paul Richard Thomas wrote: > 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

Re: [PUSHED] nvptx: Build libgfortran with '-mfake-ptx-alloca' [PR107635]

nk, what it would need to have a coarray library that makes use of a GPU, i.e. to really formulate the parallel code for nvptx with coarrays and how the expressions would need to look like. Any thoughts about that? Regards, Andre Andre Vehreschild * ve...@gmx.de Am 28. Februar 2025 20:40:40 sch

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

! T arr[]; arr[0] = bar(); temp = &arr[0]; ... Now we're safe, because freeing temp->a sets arr[0].a to NULL and the following loop is safe. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad

Re: [PATCH 0/4] Fortran: Improve flow of intrinsics/library documentation [PR47928]

an: Move "Standard" subheading in documentation [PR47928] > > gcc/fortran/gfortran.texi | 387 ++-- > gcc/fortran/intrinsic.texi | 3912 ++-- > 2 files changed, 2147 insertions(+), 2152 deletions(-) > -- Andre Vehreschild * Email: vehre ad gmx dot de

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

Re: [PUSHED] nvptx: Build libgfortran with '-mfake-ptx-alloca' [PR107635]

c': > +AM_CFLAGS += -mfake-ptx-alloca > diff --git a/libgfortran/configure.host b/libgfortran/configure.host > index 291188d19c2..9abd40f511a 100644 > --- a/libgfortran/configure.host > +++ b/libgfortran/configure.host > @@ -91,6 +91,10 @@ case "${target}" in > tmake_file="t-aix" > ;; > > + nvptx-*-none) > + tmake_file="$tmake_file t-nvptx" > + ;; > + >*) > ;; > -- Andre Vehreschild * Email: vehre ad gmx dot de

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

three testcases, because their tree-dump-scans did not fit anymore. In one case a variable was not used in the two others the counts did not match any more. Regstests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From

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

for the patch! > > Best regards > > Thomas > -- Andre Vehreschild * Email: vehre ad gmx dot de

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

. I also check F2018 standard and could not find any mention that a c_ptr is disallowed or needs to be treated specially in an associate. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From

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 f

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

case). The current fix just removes the save_expr from the lhs in an assignment and everything is fine. Regtest ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 9307720090584a324b24b32e187a2da43ceaf969 Mon Sep 17 00:

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

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 sch

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

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

patch fixes this. Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Btw, in theory this should be last patch for this PR. Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 14432031c7f247e2b4d7e76614553b5379d543b2 Mon Sep 17 00:00:00 2001 From: Andre

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 2

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

n was compiled to. So looking at the function-decl's tree n-th formal argument is the way to go there. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From efc6ed615b36bb6b42a43f6f35bf81a1adce2941 Mon Sep 17 00:

Re: [PATCH] Fortran: initialize non-saved pointers with -fcheck=pointer [PR48958]

x86_64-pc-linux-gnu. ON for mainline? > > Thanks, > Harald > -- Andre Vehreschild * Email: vehre ad gmx dot de

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

s could be handled with AC_FUNC_ALLOCA (like libcpp does) or checking > for alloca.h and including it if found (like libssp does), I guess > there's a simpler way: several runtime libs use __builtin_alloca > unconditionally (libgcc, libquadmath, libstdc++-v3). >

[Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

don't see? Regards, Ande -- Andre Vehreschild * Email: vehre ad gmx dot de From 8b1ba25dd27c89dc6ff860835431e09f3895a4e1 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Thu, 20 Feb 2025 10:47:22 +0100 Subject: [PATCH] gcc-15/changes: Document coarray changes. ABI of coarray

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

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

ge where the > explanation is given, so people can google it, and a mention in the > release notes) would be acceptable, but is there anything that > can be done in addition? I can provide an entry in release notes, if need be. Where do I have to do this? Never did. Thanks again, Andre

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

00 Jerry D wrote: > 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. > > > >

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

/coarray/get_with_scalar_fn.f90: New test. -- Andre Vehreschild * Email: vehre ad gmx dot de From b49b88f98d6cb63058c480e8646603f4dd82f83a Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Wed, 22 Jan 2025 13:36:21 +0100 Subject: [PATCH 3/7] Fortran: Allow to use non-pure/non-elemental

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

: * gfortran.dg/coarray/send_char_array_1.f90: Extend test to catch more cases. * gfortran.dg/coarray_42.f90: Invert tests use, because no longer a send is needed when local memory in a coarray is allocated. -- Andre Vehreschild * Email: vehre ad gmx dot de From

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

/coarray_lib_comm_1.f90: Fix up scan_trees. -- Andre Vehreschild * Email: vehre ad gmx dot de From 86dd7d61b13942f5f198a21aa22b3eb46fa658b1 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Fri, 7 Feb 2025 11:25:31 +0100 Subject: [PATCH 6/7] Fortran: Add transfer_between_remotes [PR107635] Add the

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

. gcc/testsuite/ChangeLog: * gfortran.dg/coarray/coarray_allocated.f90: Adapt to new method of checking on remote image. * gfortran.dg/coarray_lib_alloc_4.f90: Same. -- Andre Vehreschild * Email: vehre ad gmx dot de From ca929ce62d0f07b274113a20a5900d525526d25e Mon Sep 17 00:00

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

renamed ABI function. * gfortran.dg/coarray_stat_function.f90: Same. * gfortran.dg/coindexed_1.f90: Same. -- Andre Vehreschild * Email: vehre ad gmx dot de From abed47e1c0a28eff5b8c93e60b037d2bd7fd8999 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Wed, 8 Jan 2025 12:33

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

(_gfortran_caf_finalize): Free memory preventing leaks. (_gfortran_caf_get_by_ct): Fix constness. -- Andre Vehreschild * Email: vehre ad gmx dot de From 2d20eba3b976ae368167620a3a3846b81c0a213d Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Wed, 8 Jan 2025 12:33:27 +0100 Subject: [PATCH 1/7

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

64-pc-linux-gnu /F41. No issues where detected. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Patch, fortran] PR118750 - [14/15 Regression] ICE on associate with elemental function with polymorphic array dummy argument

Hi Paul, looks fine to me. Thanks for the patch, Andre Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Tel.: +49 178 3637538 * ve...@gmx.de Am 6. Februar 2025 16:49:18 schrieb Paul Richard Thomas : This regression must have been generated during my ASSOCIATE campaign; I am not sure when

Re: [patch. libgfortran] PR118571 UTF-8 output and the A edit descriptor

bfortran/118571 > > libgfortran/ChangeLog: > > * io/write.c (write_utf8_char4): Adjust the src_len to the > format width w_len when greater than zero. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/utf8_3.f03: New test. -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

LOCAL_INIT are not yet supported for ‘*do > concurrent*’ constructs at *(1)* > > > % gfortran --version > > GNU Fortran (GCC) 15.0.1 20250119 (experimental) > > Copyright (C) 2025 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Patch, fortran] PR96087 - [12/13/14/15 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1575

terface. Look for the formal symbol by name in the containing > proc and use its backend decl. > * trans-expr.cc (gfc_apply_interface_mapping_to_expr): For the > same reason, match the name, rather than the symbol address to > perform the mapping. > > gcc/testsuite/ > PR fortran/

Re: [Patch] Fortran: Create fresh ts.u.cl for result in gfc_get_symbol_for_expr [PR118441]

uild & regtested on x86-64-gnu-linux. > OK? Other thoughts? > > Tobias > > PS: The issue is long standing but since a recent GCC 15 > commit (cf. PR), the issue is now triggered and causes an ICE > for the testcase from the PR. -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Patch, Fortran, PR118337, v1] Fortran: Fix Fortran *.mod compatibility [PR118337]

tran-env.def" > - create_intrinsic_function (symbol[i].name, symbol[i].id, > mod, > - INTMOD_ISO_FORTRAN_ENV, false, > - NULL); > - break; > + create_intrinsic_function (symbol[i].name, symbol[i].id, mod

Re: [patch, Fortran] -fc-prototypes fixes.

c_prototypes): Adjust prototype. > * parse.cc (gfc_parse_file): Adjust call to gfc_dump_c_prototypes. > > > Regression-tested. As for testcases... as the dump is to > standard output, I don't know how to do that. If anybody > has an idea, please let me know. > > OK for trunk? > > Best regards > > Thomas > > > -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Patch, Fortran, PR118337, v1] Fortran: Fix Fortran *.mod compatibility [PR118337]

Hi Mikael, merged only patch #2 as gcc-15-6729-gd1071402055. Thanks for the ok and regards, Andre On Wed, 8 Jan 2025 22:46:15 +0100 Mikael Morin wrote: > Le 08/01/2025 à 18:23, Andre Vehreschild a écrit : > > > > First of all the recursive attr must not be set on vty

Re: [Patch, Fortran, PR118337, v1] Fortran: Fix Fortran *.mod compatibility [PR118337]

2025 22:41:13 +0100 Mikael Morin wrote: > Le 08/01/2025 à 18:37, Jakub Jelinek a écrit : > > On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote: > >> gcc/fortran/ChangeLog: > >> > >>PR fortran/118337 > >>* module.cc (use_iso_for

Re: [Patch, Fortran, PR118337, v1] Fortran: Fix Fortran *.mod compatibility [PR118337]

ing it yourself. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards and many thanks to all your valued input and patches, Andre On Wed, 8 Jan 2025 16:34:18 +0100 Jakub Jelinek wrote: > On Wed, Jan 08, 2025 at 04:09:36PM +0100, Andre Vehreschild wrote: > > One

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

fail anymore. Now regtesting. - Andre On Wed, 8 Jan 2025 15:59:43 +0100 Jakub Jelinek wrote: > On Wed, Jan 08, 2025 at 03:48:46PM +0100, Andre Vehreschild wrote: > > Hi, > > > > I have added this small patch (attached). Unfortunately I got regressions > > > >

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

ne ok for trunk (that is one I've fully tested already) > and the second one too if it passes bootstrap/regtest? > > Jakub > -- Andre Vehreschild * Email: vehre ad gmx dot de From 10e43b4c5953a30a2fb6c89dc815290484f29d54 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date:

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

et_uint_kind_from_width_isofortranenv (64), > GFC_STD_UNSIGNED) + > > /* The arguments to NAMED_KINDARRAY are: > -- an internal name > @@ -154,6 +138,26 @@ NAMED_DERIVED_TYPE (ISOFORTRAN_TEAM_TYPE > ? get_int_kind_from_node (ptr_type_node) > : gfc_default_integer_kind, GFC_STD_F2018) > > +NAMED_INTCST (ISOFORTRANENV_LOGICAL8, "logical8", \ > + gfc_get_int_kind_from_width_isofortranenv (8), GFC_STD_F2023) > +NAMED_INTCST (ISOFORTRANENV_LOGICAL16, "logical16", \ > + gfc_get_int_kind_from_width_isofortranenv (16), GFC_STD_F2023) > +NAMED_INTCST (ISOFORTRANENV_LOGICAL32, "logical32", \ > + gfc_get_int_kind_from_width_isofortranenv (32), GFC_STD_F2023) > +NAMED_INTCST (ISOFORTRANENV_LOGICAL64, "logical64", \ > + gfc_get_int_kind_from_width_isofortranenv (64), GFC_STD_F2023) > +NAMED_INTCST (ISOFORTRANENV_REAL16, "real16", \ > + gfc_get_real_kind_from_width_isofortranenv (16), GFC_STD_F2023) > + > +NAMED_UINTCST (ISOFORTRANENV_UINT8, "uint8", \ > +gfc_get_uint_kind_from_width_isofortranenv (8), > GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT16, "uint16", \ > +gfc_get_uint_kind_from_width_isofortranenv (16), > GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT32, "uint32", \ > +gfc_get_uint_kind_from_width_isofortranenv (32), > GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT64, "uint64", \ > +gfc_get_uint_kind_from_width_isofortranenv (64), > GFC_STD_UNSIGNED) + > #undef NAMED_INTCST > #undef NAMED_UINTCST > #undef NAMED_KINDARRAY > > Jakub > -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

x27;t know it, don't bother. - Andre On Wed, 8 Jan 2025 12:05:47 +0100 Mikael Morin wrote: > Hello, > > Le 08/01/2025 à 11:34, Andre Vehreschild a écrit : > > > > The flag is used now to indicate, that a type can (indirectly) reference > > itself. Not having t

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

wrote: > On Wed, Jan 08, 2025 at 11:53:53AM +0100, Andre Vehreschild wrote: > > Well, thinking about it, it smells like a side-effect of the 116669 fix. A > > type getting the recursive marker enforces the generation of the vtype for > > it. I don't see yet, why the iso_c_

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

ed, 8 Jan 2025 11:42:28 +0100 Jakub Jelinek wrote: > On Wed, Jan 08, 2025 at 11:34:35AM +0100, Andre Vehreschild wrote: > > marking the vtypes as recursive is odd, but should not be taken as any > > incompatibility marker. Pre version 15 gfortran does not check the recursive &

Re: [WIP PATCH] fortran: Accept "15" modules for compatibility [PR118337]

IGNED) -NAMED_UINTCST (ISOFORTRANENV_UINT64, "uint64", \ > -gfc_get_uint_kind_from_width_isofortranenv (64), > GFC_STD_UNSIGNED) + > > /* The arguments to NAMED_KINDARRAY are: > -- an internal name > @@ -154,6 +138,26 @@ NAMED_DERIVED_TYPE (ISOFORTRAN_TEAM_TYPE > ? get_int_kind_from_node (ptr_type_node) > : gfc_default_integer_kind, GFC_STD_F2018) > > +NAMED_INTCST (ISOFORTRANENV_LOGICAL8, "logical8", \ > + gfc_get_int_kind_from_width_isofortranenv (8), GFC_STD_F2023) > +NAMED_INTCST (ISOFORTRANENV_LOGICAL16, "logical16", \ > + gfc_get_int_kind_from_width_isofortranenv (16), GFC_STD_F2023) > +NAMED_INTCST (ISOFORTRANENV_LOGICAL32, "logical32", \ > + gfc_get_int_kind_from_width_isofortranenv (32), GFC_STD_F2023) > +NAMED_INTCST (ISOFORTRANENV_LOGICAL64, "logical64", \ > + gfc_get_int_kind_from_width_isofortranenv (64), GFC_STD_F2023) > +NAMED_INTCST (ISOFORTRANENV_REAL16, "real16", \ > + gfc_get_real_kind_from_width_isofortranenv (16), GFC_STD_F2023) > + > +NAMED_UINTCST (ISOFORTRANENV_UINT8, "uint8", \ > +gfc_get_uint_kind_from_width_isofortranenv (8), > GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT16, "uint16", \ > +gfc_get_uint_kind_from_width_isofortranenv (16), > GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT32, "uint32", \ > +gfc_get_uint_kind_from_width_isofortranenv (32), > GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT64, "uint64", \ > +gfc_get_uint_kind_from_width_isofortranenv (64), > GFC_STD_UNSIGNED) + > #undef NAMED_INTCST > #undef NAMED_UINTCST > #undef NAMED_KINDARRAY > > Jakub > -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version}

elf is that the Ada FE doesn't tell > Ada version at all - there is just "GNU Ada" and dwarf2out.cc right now > implies it is Ada 95 for DWARF3 and Ada 83 otherwise. > And in the Fortran case, while the FE provides a version, it only > does so for Fortran 2003 and 2008 (

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 ping

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

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

, Andre On Mon, 6 Jan 2025 11:06:46 +0100 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: > &

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 abs

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

Re: [r15-6415 Regression] FAIL: gfortran.dg/coarray_lib_comm_1.f90 -Os scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 on Linu

Hi Paul, thanks for the quick review. Pushed as gcc-15-6425-gdae506f73bd Thanks again, Andre On Mon, 23 Dec 2024 15:13:50 + Paul Richard Thomas wrote: > Hi Andre, > > It looks good to me. > > Thanks > > Paul > > > On Mon, 23 Dec 2024 at 14:58, Andr

Re: [Patch, fortran] PR116254/118059 -[15 Regression] Bugs triggered by class_transformational_1/2.f90

requires a temporary. > > Regression tests without errors - OK for mainline? > > Seasons greetings to one and all. > > Paul -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [r15-6415 Regression] FAIL: gfortran.dg/coarray_lib_comm_1.f90 -Os scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 on Li

? Regards, Andre On Mon, 23 Dec 2024 04:52:50 +0800 "haochen.jiang" wrote: > On Linux/x86_64, > > 586477d67bf2e320e8ec41f82b194259c1dcc43a is the first bad commit > commit 586477d67bf2e320e8ec41f82b194259c1dcc43a > Author: Andre Vehreschild > Date: F

Re: [2nd PING, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

Hi Jerry, thanks for taking a look. Committed as gcc-15-6415-g586477d67bf. Thanks again, Andre On Sat, 21 Dec 2024 15:27:52 -0800 Jerry D wrote: > On 12/20/24 9:09 AM, Andre Vehreschild wrote: > > Thank you very much Jerry. > > > > The delta between the two patche

Re: [PING] [PATCH, part4] Fortran: fix passing of NULL() to assumed-rank, derived type dummy [PR104819]

for mainline? > > > > Thanks, > > Harald > > > > P.S.: if someone would like to assist with the case of class > > dummies, please let me know. > > > > -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [2nd PING, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

due to other patches. And I will be around for fixing occurring issues. Btw, in the OpenCoarrays GitHub repo the branch for 774 implements this new way of accessing data for mpi. Thanks again for looking and regards, Andre Andre Vehreschild

Re: [2nd PING, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

Hi all, pinging again. Please note, that attached patch is a slightly updated version. Regtests ok on x86_64-pc-linux-gnu. Ok for mainline? Regards, Andre On Mon, 16 Dec 2024 10:58:22 +0100 Andre Vehreschild wrote: > PING! > > On Fri, 6 Dec 2024 19:10:08 +0100 > Andre

Re: [Fortran, Patch, PR57598] Fix coarray STOP

Hi Jerry, thanks for the review. Committed as gcc-15-6383-ga25cc268846 Thanks again, Andre On Thu, 19 Dec 2024 11:09:20 -0800 Jerry D wrote: > On 12/19/24 4:13 AM, Andre Vehreschild wrote: > > Hi all, > > > > attached patch fixes a rather old open issue, that I st

  1   2   3   4   5   6   7   >