ermail/gcc-testresults/2025-July/854023.html
>
> and got two test failures:
>
> FAIL: gfortran.dg/coarray/alloc_comp_4.f90 -fcoarray=lib -O2
> -lcaf_shmem execution test
> FAIL: gfortran.dg/coarray/stopped_images_2.f08 -fcoarray=lib -O2
> -lcaf_shmem execution test
>
> Hope that's useful.
>
> Kind regards,
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi Harald,
Am 27. Juli 2025 22:25:40 schrieb Harald Anlauf :
Harald, are you still unconvinced? Do we need to discuss the behavior of
the testcase test_teams_1? or something else?
I will not make any specific suggestions about the actual implementation
of coarrays in gfortran.
Let me phrase
nd many similarities.
Regards,
AndreAndre Vehreschild * ve...@gmx.de
Am 27. Juli 2025 21:18:21 schrieb Mikael Morin :
Le 27/07/2025 à 17:35, Andre Vehreschild a écrit :
On Sun, 27 Jul 2025 16:57:14 +0200
Mikael Morin wrote:
Le 27/07/2025 à 12:57, Andre Vehreschild a écrit :
Hi Mikael,
In t
On Sun, 27 Jul 2025 16:57:14 +0200
Mikael Morin wrote:
> Le 27/07/2025 à 12:57, Andre Vehreschild a écrit :
> > Hi Mikael,
> >
> >>> In this example, image 1, i.e., for
> >>> Opencoarrays a thread on image one takes the data from the executing
>
eral
> architecture of the coarray implementation.
Then let's continue with small but continuous steps.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
? Yes, mea culpa. I did it wrong in
the beginning and am just trying to correct my wrongs.
Regards,
Andre
Andre Vehreschild * ve...@gmx.de
Am 26. Juli 2025 22:32:53 schrieb Mikael Morin :
Le 26/07/2025 à 19:03, Harald Anlauf a écrit :
Gesendet: Samstag, 26. Juli 2025 um 15:17
Von: "Mi
hich refers
> to the current team, and coindex 1 of the initial team.
> (This is why I asked about communicators and alike, as this assignment
> might be correct only under very special conditions, or I just don't
> understand it.)
To my understanding that assignment is allowed by the
at help? I mean, we are way off of the original question, which was if it
is ok to always compute a function result on the image initiating a
communication instead of in the caf_accessor. That patch has still to be merged
or joined to the pr88076 series.
Thanks for coming back to this.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
0x1044a52ff] shmem.c:91
> + 9 counter_barrier_wait (in h) + 48 [0x1044a8a80]
> counter_barrier.c:70 2166 Thread_408707823: com.apple.rosetta.exceptionserver
> 2166 ??? (in runtime) load address 0x7ff7fff8b000 + 0x13e58
> [0x7ff7fff9ee58] 2166 ??? (in runtime) load address 0x7ff7fff8b000 +
> 0x123e0 [0x7ff7fff9d3e0] 2166 ??? (in runtime) load address 0x7ff7fff8b000
> + 0x4944 [0x7ff7fff8f944]
--
Andre Vehreschild * Email: vehre ad gmx dot de
open for
suggestions and other ideas. So feel free to add your opinion.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi Toon,
the coarray_native branch is not where Jerry has put the caf_shmem patches.
Coarray native is an older branch, that used a different approach to shared
memory coarrays. Caf_shmem is partially based on it.
The branch Jerry has build is
remotes/origin/devel/gfortran-test
- AndreAndr
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
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
; 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,
> >
> >
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
-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
m-team/src/tests/unit/teams/test_teams_1.f90
>
> Frankly, you need to provide more details for me.
> Or maybe someone else can jump in and help me out...
>
> (Note: the above testcase fails with ifx, and it is not clear to me whether
> it is rather an issue with Intel.)
>
>
t; > until I can set up a better gfortran testing repo that is maintained
> > current to trunk. One may have to register with sourceware to access this,
> > I have not checked. I would appreciate anyone willing to build and test
> > this branch to help flush out any issues.
> >
> > Feedback and/or test results welcome.
> >
> > Regards,
> >
> > Jerry
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
rrays, Jerry, then please make sure to use separate and
> > clean build directories. The build stuff from OpenCoarrays is sometimes not
> > cleaning up its artifacts correctly, so that .o's stay that better
> > shouldn't.
> >
> > Hope to get back to gfortran hacking by mid of the week and that this few
> > tips helped.
> >
> > Regards,
> > Andre
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
of the week and that this few tips
helped.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
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
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,
>
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
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
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,
&
*/
> 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
-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
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
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
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
> &
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
Hi Jerry,
thanks for the report. I am positive that I merged the correct patch, but
I'll check tomorrow when it's a little bit cooler. At the moment it's so
incredibly hot, one can't concentrate.
Sorry for the mess,
Andre
Andre Vehreschild * ve...@gmx.de
Am 1. Juli 2
|
and the same for op2. I will fix it tomorrow. Sorry again for all the bother.
- Andre
Andre Vehreschild * ve...@gmx.de
Am 1. Juli 2025 19:33:41 schrieb Jerry D :
Hi all,
With latest trunk this morning after Andre's commits I am still getting
failures
with Toon's random_weather.f90
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,
> >
&
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
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
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
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
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
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
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
ill give it a try here so we can have some data points.
>
> Jerry
>
> On Thu, Jun 26, 2025, 2:08 PM Toon Moene wrote:
>
> > On 6/26/25 21:34, Thomas Koenig wrote:
> >
> > > Am 26.06.25 um 10:15 schrieb Andre Vehreschild:
> >
> > &g
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
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
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
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
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
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
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
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
, 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
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
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
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
-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
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
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
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
-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
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
Makefile next.
>
> Undergoing testing on x86_64-linux, OK to push?
> FX
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
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
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
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
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
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
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
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
..., 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 /
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
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
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
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
Hi Jerry,
the archive has it here
https://gcc.gnu.org/pipermail/fortran/2025-April/062017.html part 4
And part 5 here
https://gcc.gnu.org/pipermail/fortran/2025-April/062020.html
The mail's order unfortunately got mixed up, but they should all be there.
Regards,
Andre
Andre Vehreschild
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
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
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
?
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
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
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
+0200
Mikael Morin wrote:
> Hello,
>
> Le 08/04/2025 à 15:29, Andre Vehreschild a écrit :
> > Hi all,
> >
> > while working at teams stuff I encountered some issue with the ASSOCIATE
> > statement:
> >
> > 1. First of all: It does not open its namespace
, because that is not recursive.
Any comments, insight or pointers to why a "defined" associate-name must not
occur in an associate expr, but may occur in an associate immediately
following, are very much appreciated!
Puzzled regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
.. 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
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
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 :-)
&
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
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
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&#
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 *
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
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
:-)
>
> 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,
> >
> &
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
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
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
:
> 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
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.
>
>
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
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'
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
1 - 100 of 371 matches
Mail list logo
