Re: [Fortran, Coarray] Call-out to everyone having Fortran coarray-codes available

Very much appreciated. Thank you! - Andre On Mon, 21 Jul 2025 13:38:56 +0200 Arjen Markus wrote: > I have a not-so-trivial, but compact test case for you. I will try it out > with the receipe you gave :). > > Regards, > > Arjen > > Op ma 21 jul 2025 om 13:31 s

[Fortran, Coarray] Call-out to everyone having Fortran coarray-codes available

ory library for using coarrays with gfortran from version 16 on. It can provide great speed improvements in comparison to MPI-based implementations, but is limited to a single node where all CPUs can share memory. Any feedback is greatly appreciated. Thanks and regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Fortran, Patch, PR119106, v1] Allow iterator substitution in array constructors

; After a false start, the patch was applied to mainline, did what it was > supposed to do and regtests fine. > > Ok for mainline. > > Thanks > > Paul > > > On Fri, 18 Jul 2025 at 13:42, Andre Vehreschild wrote: > > > Hi all, hi Harald, > > > >

Re: [PATCH] Fortran: fix bogus runtime error with optional procedure argument [PR121145]

Hi Harald, that looks fine to me. Ok to commit and backport. Thanks for the patch. - Andre Andre Vehreschild * ve...@gmx.de Am 18. Juli 2025 21:19:00 schrieb Harald Anlauf : Dear all, the attached simple and obvious patch fixes an erroneous runtime check with -fcheck=pointer when passing a

[Fortran, Patch, PR119106, v1] Allow iterator substitution in array constructors

-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From faabad5c90b7505b7e118ff3fa1dcbfb4ff4d428 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Fri, 27 Jun 2025 11:42:54 +0200 Subject: [PATCH] Fortran: Allow for iterator substitution in

Re: [PATCH, v2] Fortran: fix minor issues with coarrays (extended)

check_add_new_comp_handle_array (e, type, add_data); > > > If I read the comment in the if-branch and match it against my > expectation, I am confused. Why only "pure elemental"? Why not > allow simply "pure"? And wouldn't it be better to move the e

Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

OpenCoarray tests revealed some/a lot of issues in caf_shmem. I am currently regtesting the patch and will publish as soon as it regtests cleanly. Regards, Andre On Fri, 4 Jul 2025 10:51:43 -0700 Jerry D wrote: > On 7/4/25 5:12 AM, Andre Vehreschild wrote: > > Hi all, >

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

tatement before the assignment. > > I think it's the only missing bit. > > > > Mikael, > > I believe you are right: the testcase is technically invalid > without an > >allocate(list(0)) > > as in the original testcase in the PR. > > A corresponding fix is approved. > > Thanks, > Harald > -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Ping, Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

Hi Jerry, thanks for the review. Pushed as gcc-16-2086-gd1f05661fa6. Thanks again, Andre On Mon, 7 Jul 2025 10:49:50 -0700 Jerry D wrote: > On 7/7/25 8:39 AM, Andre Vehreschild wrote: > > Ping! > > > OK for mainline. > > Thanks, > > Jerry > &g

Re: [Ping, Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

Ping! On Thu, 26 Jun 2025 15:32:47 +0200 Andre Vehreschild wrote: > Hi, > > I found a bug in the module cleanup expression at the end of the test. In the > attached patch it is corrected. > > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > > Regards, &

Re: [PATCH, v2] Fortran: fix minor issues with coarrays (extended)

*/ > check_add_new_comp_handle_array (e, type, add_data); > else > > Can you please elaborate? > > I understood the code comment in the way that any pure or elemental > intrinsic should be handled in the else branch. Or do you have > an example which is diffe

[Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

-freebsd14.3. Ok for mainline? Thanks to Steve for bringing these deficiencies to my attention. Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 6a50f10bfa802fc93eaf302bf5493506b5795e6a Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Wed, 2 Jul 2025 11:47:18

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

compile Toon's random_weather code and run it. Regards, Andre On Wed, 2 Jul 2025 16:12:57 -0700 Jerry D wrote: > On 7/2/25 9:40 AM, Jerry D wrote: > > On 7/2/25 3:14 AM, Andre Vehreschild wrote: > >> Hi all, > >> > >> I successfully cre

Re: [PATCH] Fortran: fix minor issues with coarrays (extended)

ency between pure/elemental functions being either > >  non-intrinsic or intrinsic.  Checking for the latter was likely missed > >  from the beginning. > > > > No new testcase. > > > > Regtested on x86_64-pc-linux-gnu.  OK for mainline? > > > > Thanks

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

er to backport this patch to gcc-15 is about a week. Regards, Andre On Wed, 2 Jul 2025 09:40:59 -0700 Jerry D wrote: > On 7/2/25 3:14 AM, Andre Vehreschild wrote: > > Hi all, > > > > I successfully created a big mess with the previous patch. First of all by > &

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

bother and all my mistakes. I am really sorry to have wasted your time. The patch has been regtested fine on x86_64-pc-linux-gnu / F41. Ok for mainline and later backport to gcc-15? Regards, Andre On Tue, 1 Jul 2025 11:17:58 +0200 Andre Vehreschild wrote: > Hi Harald, > > thank

Re: [Fortran, Patch, PR120847 (was: PR120846), v1] Fix ICE when a function is called more than once in a coarray expression.

wrote: > Am 30.06.25 um 15:29 schrieb Andre Vehreschild: > > Hi all, > > > > attached patch fixes an ICE when in an expression with a coindex a function > > was used more than once. E.g. coarray(mod( something ), mod( something else > > ))[i] ICE'd because a

Re: [Fortran, Patch, PR120843, v2] Fix reject valid, because of inconformable coranks

Hi Harald, thanks for the review. Committed as gcc-16-1885-g1b0930e9046. Will backport to gcc-15 in about a week. Thanks again. Regards, Andre On Mon, 30 Jun 2025 22:31:08 +0200 Harald Anlauf wrote: > Am 30.06.25 um 15:25 schrieb Andre Vehreschild: > > Hi all, > > &

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

ed tests 6 > /home/kargl/gcc/obj/gcc/gfortran version 16.0.0 20250629 (experimental) > (GCC) > > I suspect we'll need to have > > #include "config.h" > > #indef HAVE_UNISTD_H > #include > #endif > > and similar for other headers files. I further suspect that this > are going to be rough on CYWIN/MINGW. > > -- Andre Vehreschild * Email: vehre ad gmx dot de

[Fortran, Patch, PR120846, v1] Fix ICE when a function is called more than once in a coarray expression.

k for mainline and gcc-15 later on? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From e4d4dd9768f7797e30542ec99b16093a663c65f3 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Fri, 27 Jun 2025 15:31:21 +0200 Subject: [PATCH] Fortran: Ensure arguments in coarray cal

Re: [Fortran, Patch, PR120843, v2] Fix reject valid, because of inconformable coranks

Hi all, here now the version of the patch that seems to be more complete. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline and later backport to gcc-15? Regards, Andre On Fri, 27 Jun 2025 15:44:20 +0200 Andre Vehreschild wrote: > I take this patch back. It seems to

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Steve, I would do git am pr88076_v1_1.patch or patch -p1 each of the patch files. Then they go where they ought to be. Pro tip: create a new branch before doing the git am, then you can just switch back to master when desired. - Andre Andre Vehreschild * ve...@gmx.de Am 29. Juni 2025 20

Re: [Fortran, Patch, PR120843, v1] Fix reject valid, because of inconformable coranks

I take this patch back. It seems to be incomplete. - Andre On Fri, 27 Jun 2025 14:45:36 +0200 Andre Vehreschild wrote: > Hi all, > > this patch fixes a reject valid when the coranks of two operands do not match > and no coindex is given. I.e. when only an implicit this_image co

[Fortran, Patch, PR120843, v1] Fix reject valid, because of inconformable coranks

Hi all, this patch fixes a reject valid when the coranks of two operands do not match and no coindex is given. I.e. when only an implicit this_image co-ref is used. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

mail). So when you find something suitable, please throw it at caf_shmem. Regards, Andre Andre Vehreschild * ve...@gmx.de Am 26. Juni 2025 19:15:06 schrieb Jerry D : On 6/26/25 12:22 AM, Andre Vehreschild wrote: Hi Jerry, thanks for testing. I have fixed IMO most of the whitespace issues i

Re: [Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

Hi, I found a bug in the module cleanup expression at the end of the test. In the attached patch it is corrected. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre On Wed, 25 Jun 2025 15:48:11 +0200 Andre Vehreschild wrote: > Hi, > > Antony Lewis

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

et it. Thanks again, Andre On Wed, 25 Jun 2025 22:24:46 +0200 Harald Anlauf wrote: > Am 25.06.25 um 13:39 schrieb Andre Vehreschild: > > Hi all, > > > > attached patch fixes an out of bounds access in the clean up code of a > > concatenating array constructo

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

en need by. But for the time being, I think what I presented is quite usable. Did that answer your questions? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

n 6/24/25 11:49 PM, Andre Vehreschild wrote: > > Hi Jerry, > > > > thank you very much. Just try it. I can only imagine that Paul had a somehow > > corrupted build directory or left overs from some previous build. I am still > > wondering, that I got no automated mai

[Patch, Fortran, Coarray, PR88076, v1] 4/6 Add a shared memory multi process coarray library.

Vehreschild * Email: vehre ad gmx dot de From b4bdfd44ee3d1658eb67ef1a4cdf0de91b50386a Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Wed, 18 Jun 2025 09:23:32 +0200 Subject: [PATCH 4/6] Fortran: Fix signatures of coarray API and caf_single. The teams argument to some functions was marked as

[Patch, Fortran, Coarray, PR88076, v1] 2/6 Add a shared memory multi process coarray library.

Hi all, this patch fixes handling of optional arguments to coarray routines. Again I stumbled over this while implementing caf_shmem. I did not find a ticket either. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot

[Patch, Fortran, Coarray, PR88076, v1] 3/6 Add a shared memory multi process coarray library.

-gnu / F41. Ok for mainline? To test this one needs caf_shmem in place, because only there the required beef to detect the issue is present. The test modifications in the last commit of this series add a testcase for these two case. Regards, Andre -- Andre Vehreschild * Email: vehre ad

[Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

nline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 2c7c6a6db78c448a158ee4f952cf2236665001ca Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Wed, 25 Jun 2025 14:46:16 +0200 Subject: [PATCH] Fortran: Ensure finalizers are created correctly [PR1

[Fortran, Patch, v1] 3/(3) Prevent creating tree that is never used.

Vehreschild * Email: vehre ad gmx dot de From 52a7898f0b460dfcd64117b399826592e8f0978b Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Wed, 25 Jun 2025 12:27:35 +0200 Subject: [PATCH 3/3] Fortran: Prevent creation of unused tree. gcc/fortran/ChangeLog: * trans.cc (gfc_allocate_using_malloc

[Fortran, Patch, v1] 2/(3) Stop spending memory in coarray single mode executables.

Vehreschild * Email: vehre ad gmx dot de From a888d8952e8fa6f516fde22519fab33d60d3f0c4 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Wed, 25 Jun 2025 12:27:04 +0200 Subject: [PATCH 2/3] Fortran: Fix wasting memory in coarray single mode. gcc/fortran/ChangeLog: * resolve.cc (resolve_fl_derived0

[Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

, that there will be 3 patches. Only this one fixes the bug. The other fixes I found while hunting this issue and because they play in the general same area, I don't want to loose them. I therefore publish them in this context. Regards, Andre -- Andre Vehreschild * Email: vehre ad gm

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

build upon each other. Just try it. The more feedback, the better. Regards, Andre On Tue, 24 Jun 2025 11:07:23 -0700 Jerry D wrote: > On 6/24/25 6:09 AM, Andre Vehreschild wrote: > > Hi all, > > > > this series of patches (six in total) adds a new coarr

Re: [Patch, Fortran, Coarray, PR88076, v1] 6/6 Add a shared memory multi process coarray library.

pects some rough edges on non-linux system. > I'll find out this weekend when I give his patch a spin on > FreeBSD. Hopefully, a windows10/11 user can test the patch. > -- Andre Vehreschild * Email: vehre ad gmx dot de

[Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

ne using a debug build of coarray_icar on an Intel Core i7-5775C CPU @ 3.30GHz having 24GB, and running Fedora Linux 41 with all recent patches. Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de

[Patch, Fortran, Coarray, PR88076, v1] 1/6 Add a shared memory multi process coarray library.

Hi all, this small patch unifies handling of the optional team argument to failed_/stopped_images(). I did not find a ticket for this, but stumbled over it while implementing caf_shmem. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild

[Patch, Fortran, Coarray, PR88076, v1] 6/6 Add a shared memory multi process coarray library.

-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 2eafd3c6b52507d1690c7ab565e32db33a39455e Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Wed, 18 Jun 2025 09:26:22 +0200 Subject: [PATCH 6/6] Fortran: Enable coarray tests for multi

Re: [PATCH] libfortran: Simplify Makefile logic

riables. This is possible for all except matmul, which > needs its own special flags. > > I also include some checking in the regenerate.sh script, to should make sure > the list of generated files in the script and in the makefile stay in sync. > > Tested on x86_64-linux, OK to push? > > FX > -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [PATCH] libfortran: Add script to regenerate source files

Makefile next. > > Undergoing testing on x86_64-linux, OK to push? > FX > > -- Andre Vehreschild * Email: vehre ad gmx dot de

Re: [Fortran, Patch, PR120483, v2] Fix wrong type of saved allocatable strings.

Hi Harald, merged as gcc-16-1096-gafa2de8093a. Thanks again for the review. Regards, Andre On Tue, 3 Jun 2025 21:59:52 +0200 Harald Anlauf wrote: > Hi Andre, > > On 6/3/25 13:31, Andre Vehreschild wrote: > > Hi all, > > > > thanks for the explanations, Ch

Re: [Fortran, Patch, PR120483, v2] Fix wrong type of saved allocatable strings.

correct me. Thanks for the ok, I will merge tomorrow first thing in the morning. Regards, Andre Andre Vehreschild * ve...@gmx.de Am 3. Juni 2025 22:00:00 schrieb Harald Anlauf : Hi Andre, On 6/3/25 13:31, Andre Vehreschild wrote: Hi all, thanks for the explanations, Christophe. This is v

Re: [PATCH] Fortran: ICE due to missing locus with data statement for coarray [PR99838]

Hi Harald, Lgtm. That patch is nearly obvious. Ok for trunk and backport. Thanks for the patch, Andre Andre Vehreschild * ve...@gmx.de Am 3. Juni 2025 20:43:52 schrieb Harald Anlauf : Dear all, here's a fix for another one of Gerhard's "torture tests" that triggers

Re: [Fortran, Patch, PR120483, v2] Fix wrong type of saved allocatable strings.

f the reference. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre On Tue, 3 Jun 2025 10:14:29 +0200 Christophe Lyon wrote: > Hi! > > > On Mon, 2 Jun 2025 at 20:53, Andre Vehreschild wrote: > > > > Hi Thomas, > > > > thanks

Re: [Fortran, Patch, PR120483, v1] Fix wrong type of saved allocatable strings.

ed patches checked by a CI? That's fantastic! I will continue to investigate how to fix that issue. Regards, Andre Andre Vehreschild * ve...@gmx.de Am 2. Juni 2025 20:10:06 schrieb Thomas Koenig : Hi Andre, attached patch fixes a missing substring ref on a saved allocatable string. The

[Fortran, Patch, PR120483, v1] Fix wrong type of saved allocatable strings.

on x86_64-pc-linux-gnu / F41. Ok for mainlines? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From f05992908acd4aeded9d40d78db4c6720a500e5b Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Mon, 2 Jun 2025 10:41:48 +0200 Subject: [PATCH] Fortran: Fix missing

Re: [PATCH] Fortran: default-initialization and functions returning derived type[PR85750]

LGTM! Thanks for the Patch. - Andre Andre Vehreschild * ve...@gmx.de Am 15. Mai 2025 22:36:19 schrieb Harald Anlauf : Dear all, the attached patch fixes missing default-initialization of function results of derived type that happens under some conditions, see PR. The logic when default

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

..., but the issue > addressed here might show up only in an instrumented compiler > (ASAN or UBSAN?). And since each message here is emitted by > gfc_fatal_error(), one could only test one case per testcase. > (IMHO testing this would be insane.) > > > Regtests ok on x86_64-pc-linux-gnu /

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

know how to test this in the testsuite. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 56a5099b9ed307b1c3cd1bfbe2058ef74f43 Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Tue, 22 Apr 2025 10:11:52

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

Hi Andre, > > > > On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild > <mailto:ve...@gmx.de>> wrote: > > > > Hi Jerry, > > > > thanks for the review and sorry for the long delay. With publishing > > the team's > > patches for

[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

  1   2   3   4   5   6   7   8   >