-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
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 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
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,
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
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
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
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
-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
open for
suggestions and other ideas. So feel free to add your opinion.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
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
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
; 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,
> >
> >
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
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
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
? 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
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
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
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
>
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
.
Bootstrapped and regtested ok on x86_64-linux/F35.
Ok, for trunk and backport to 12 and 11-branch after decent time?
I perceived that 12 is closed for this kind of bugfix, therefore asking ok for
13.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2022-01-24
01.22 um 17:32 schrieb Andre Vehreschild via Fortran:
> > Hi all,
> >
> > attached patch fixes wrong code generation when broadcasting a derived type
> > containing allocatable and non-allocatable scalars. Furthermore does it
> > prevent broadcasting of coarray-tokens,
ta_set (&tmpblock, cdesc, comp); |
> ~^~~~
> ../../repos/gcc/gcc/fortran/trans-array.cc:9082:16: note: ‘cdesc’ was
> declared here 9082 | tree cdesc; |^ cc1plus:
> all warnings being treated as errors make[3]: *** [Makefile:1143:
> fortran/trans-array.o] Error 1
>
where with submit
26e237fb5b8.
Thanks for pointing this out.
Regards,
Andre
On Fri, 28 Jan 2022 10:36:23 +0100
Andre Vehreschild via Fortran wrote:
> Hi Tobias,
>
> ups, sorry, reverted immediately.
>
> Regards,
> Andre
>
> On Fri, 28 Jan 2022 10:
Hi all,
two weeks have passed with no complains about the patch for PR103970. Therefore
backported and pushed to gcc-11 as 680ee9c3332.
Regards,
Andre
On Fri, 28 Jan 2022 12:39:17 +0100
Andre Vehreschild wrote:
> Hi Tobias,
>
> I don't know why that bootstrapped init
Hi everyone,
sorry for missing out on the gcc-11 backport, but better late than never.
Committed backport as ae57aae60d1.
Regards,
Andre
On Wed, 23 Jun 2021 11:21:45 +0200
Tobias Burnus wrote:
> On 23.06.21 10:23, Andre Vehreschild wrote:
>
> > Will wait two weeks fo
version information available
> > from/in a binary? Maybe accessible with objdump or strings?
> >
> > For ifort, we use the -sox option ("This option tells the compiler to
> > save the compilation options and version number in the executable file.
> > ..."). This enables e.g. strings /path/to/binary | grep Intel
> >
> > Or is there a gfortran option that makes this accessible in a binary?
> >
> > Thanks,
> > Kay
> >
> >
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
This is probably
> something that contributors could fit in much better, and would provide
> an additional incentive to take up gfortran work again :-)
>
> Do you know if this is, in fact, a possibility?
>
> Best regards
>
> Thomas
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
> > Cheers.
> > Mikael
>
> The original person who contacted me at FortranDiscourse already
> submitted a proposal for something to do with Fortran-Lang and is
> offering to assist with a gfortran proposal. I asked for a direct email
> address so I could relay this to you if you do not have it. I also gave
> saveral of your emails to him asking to contact you directly.
>
> Regards,
>
> Jerry
--
Andre Vehreschild * Email: vehre ad gmx dot de
ively with gfortran, and the best way
> to demonstrate that is to already have a track record of accepted
> patches (preferably gfortran, but also gcc in general). That does not
> mean that this track record needs to be years or decades old, but it
> should exist.
>
> Also, people recommended by a current contributor should be able
> to participate; but we should probably discuss people who apply
> on a case-by-case basis.
>
> (The above is my personal opinion, please discuss if anybody has
> a different opinion).
>
> Best regards
>
> Thomas
--
Andre Vehreschild * Email: vehre ad gmx dot de
e activities?
- Who (maintainer, contributor, organization) would be most qualified to
implement this work/receive the support and why?
---
Any input welcome.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
orking full-time on them?
I am asking that specifically because we need to estimate the person days they
pay for and time boundary up to when the project will be done.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
rcial needs and in large parts volunteers. Funding by
companies was mostly done by allowing employees to work on features required for
the company and donating the code.
Is that what you were trying to add?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi Jerry,
thanks. I switched from FAST to OpenFAST in the list of references. Strangely
my google search never pointed me to OpenFAST.
Regards,
Andre
On Thu, 1 Jun 2023 17:53:21 -0700
Jerry D wrote:
> On 6/1/23 2:18 AM, Andre Vehreschild wrote:
> > Hi Damian, all,
> >
gt; More generally, Lapack is written in Fortran, and R uses Lapack
> (as we found out the hard way with PR 90329). And Lapack is really
> a foundation of linear algebra, which is at the heart of a _lot_
> of scientific software.
--
Andre Vehreschild * Email: vehre ad gmx dot de
I have referenced LAPACK now. I hope this is ok?
- Andre
On Mon, 5 Jun 2023 14:16:43 +0200
Thomas Koenig wrote:
> On 05.06.23 12:07, Andre Vehreschild wrote:
> >> R and Octave may also be good examples of use cases.
> > Mhhh, both are not written in Fortran, right?
>
&
;:
---
- Who (maintainer, contributor, organization) would be most qualified to
implement this work/receive the support and why?
Maurice Ulrich @ Badger Systems GmbH -- Project management
Dr. Andre Vehreschild @ Badger Systems GmbH -- Contributed to distributed
memory coarray, teams and failed
Hi Benson,
thanks for the input. I will incorporate it.
Regards,
Andre
On Thu, 8 Jun 2023 08:34:54 +0300
Benson Muite wrote:
> On 6/5/23 13:07, Andre Vehreschild wrote:
> > Hi Benson,
> >
> > thank you for your input. Comments are inline:
> >
>
in the application form.
:-) Removing technical speech is not the problem... But I like the plan
although I wouldn't know what to do in each case.
> > Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced
> > in gfortran development and component dependencies.
> >
> I'm not affiliated to any company, university or organization. Just
> myself. :-)
Sorry, I did not mean any insult. What do you prefer? "not affiliated" or
"private", ...?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
-linux-gnu/Fedora 37.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
* expr.cc (gfc_match_init_expr): Prevent PDT analysis for function
calls.
* simplify.cc (gfc_simplify_len): Replace len() of PDT with pdt
component
Hi Harald,
I do get why this happens. I still don't get why I have to do this
'optimization' manually. I mean, this rewriting of expressions is needed in
more than one location and most probably already present somewhere. So who
can point me in the right direction?
Regard
arse_file()
> ../../gcc-trunk/gcc/fortran/parse.cc:7235
> 0xa40a1f gfc_be_parse_file
> ../../gcc-trunk/gcc/fortran/f95-lang.cc:229
>
> The fortran-dump confirms that n is not simplified to a constant.
> So while you're at it, do you also see a solution to this va
expr (tmp);
> tmp = gfc_copy_expr (*newp);
> }
>
> or rather
>
>if (inquiry->next)
> gfc_replace_expr (tmp, *newp);
>
> at least shrinks the leak a bit. (Untested otherwise).
>
> OK with one of the above changes (provided it survives re
inside the derived type
into the block guard by its allocated check.
Regtested ok on f37/x86_64. Ok for master?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e0fc8ebc46b..8e94a9a469f 100644
--- a/gcc
>
> The patch looks fine to me. Since you mention it in the comment, is it
> worth declaring the derived type 'foo' in a module and giving it a
> final routine?
>
> Thanks for the patch.
>
> Paul
>
> On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fo
ed - it's fine for trunk and, I would suggest, 13-branch.
>
> Cheers
>
> Paul
>
> On Fri, 29 Sept 2023 at 11:01, Andre Vehreschild wrote:
> >
> > Hi Paul,
> >
> > thanks for the quick review. I've added a testcase with a module and
em in the beginning. I must have done something wrong.
Please accept my apologies and regards,
Andre
On Fri, 29 Sep 2023 15:13:56 +0200
Andre Vehreschild via Fortran wrote:
> Hi Paul,
>
> thanks. Commit to trunk as a680274616ec6b26ccfdcee400ed7f54e341d40c
> and backpo
E WHO HAVE CONTRIBUTED
> AND MAINTAINED GFORTRAN FOR YEARS. gfortran needs new blood, or
> it is destined for the bit bucket.
>
> > I believe Andre
> > Verheschild has some limited availability so I'm cc'ing him and will
> > discuss it with him if he's int
mbining your patch with my patch if you intend to
> commit; otherwise, attach your patch to the PR and sit patiently
> until someone can do the combined commit.
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index cc9d8
don't know when Thomas/Nicolas will merge their
> work-in-progress.
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index cc9d85543ca..7365dde47bf 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.
Ping!
Ok for trunk?
I have looked at other patches, but none was patching any location I have
worked on previously. Therefore I can't return the favor of reviewing any
currently open patches and have to ask for volunteers here.
- Andre
On Mon, 26 Apr 2021 12:36:36 +0200
Andre Vehreschil
e
> class actual arguments passed to non-descriptor formal args by
> using the data pointer, stored as the symbol's backend decl.
>
> gcc/testsuite/ChangeLog
>
> PR fortran/46691
> PR fortran/99819
> * gfortran.dg/class_dummy_6.f90: New test.
> * gfortran.dg/class_dummy_6.f90: New test.
--
Andre Vehreschild * Email: vehre ad gmx dot de
wrote:
> On Mon, May 03, 2021 at 11:21:10AM +0200, Andre Vehreschild wrote:
> > Ping!
> >
> > Ok for trunk?
> >
> > I have looked at other patches, but none was patching any location I have
> > worked on previously. Therefore I can't return the favor of revie
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
PR fortran/100337
* trans-intrinsic.c (conv_co_collective): Check stat for null ptr
before dereferrencing.
gcc/testsuite/ChangeLog:
PR fortran/100337
* gfortran.dg/coarray_collectives_17.f90: New test.
diff --git a/gcc
> yes, please commit
>
> On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote:
> > On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote:
> >> Ping, ping!
> >>
> >> Please find attached a rebased version of the patch for the RANDOM_INIT
> >> iss
every discussion on the mailing lists?
Thanks for your help,
Andre
On Sat, 22 May 2021 19:58:57 +0200
Martin Liška wrote:
> On 5/22/21 1:39 PM, Andre Vehreschild via Gcc-patches wrote:
> > Hi Steve and Jerry,
> >
> > thanks for the ok'ing.
> >
&
Ping!
On Fri, 21 May 2021 15:33:11 +0200
Andre Vehreschild wrote:
> Hi,
>
> the attached patch fixes an issue when calling CO_BROADCAST in
> -fcoarray=single mode, where the optional but non-present (in the calling
> scope) stat variable was assigned to before checking for it be
--
Andre Vehreschild * Email: vehre ad gmx dot de
Steve Kargl
PR fortran/98301 - random_init() is broken
Correct implementation of random_init() when -fcoarray=lib is given.
Backport from mainline.
gcc/fortran/ChangeLog:
PR fortran/98301
* trans-decl.c (gfc_build_builtin_function_decls): Move
Hi Steve, hi all,
the patch for pr98301 has been backported to gcc-11 as
002745ca3668fc5e87c22acc81caaeaaadf9c47a
Regards,
Andre
On Sat, 5 Jun 2021 09:27:16 -0700
Steve Kargl wrote:
> On Sat, Jun 05, 2021 at 04:04:51PM +0200, Andre Vehreschild wrote:
> >
> > I was as
PING!
On Fri, 4 Jun 2021 18:05:18 +0200
Andre Vehreschild wrote:
> Ping!
>
> On Fri, 21 May 2021 15:33:11 +0200
> Andre Vehreschild wrote:
>
> > Hi,
> >
> > the attached patch fixes an issue when calling CO_BROADCAST in
> > -fcoarray=single mode, whe
UM:
> and, with -fcoarray=single, errmsg is not touched
> as stat is (unconditionally) 0 (success)..
>
>
> On 19.06.21 13:23, Andre Vehreschild via Fortran wrote:
> > PING!
> >
> > On Fri, 4 Jun 2021 18:05:18 +0200
> > Andre Vehreschild wrote:
> >
the testsuite provides a variable for stat.
Will wait two weeks for any errors introduced by this patch before backporting
to gcc-11, ok?
Regards,
Andre
On Tue, 22 Jun 2021 10:37:27 +0200
Tobias Burnus wrote:
> Hi Andre,
>
> On 22.06.21 09:40, Andre Vehreschild via Fort
Ok, I changed it in the log-file already.
- Andre
On Sat, 24 Apr 2021 08:44:24 -0700
Steve Kargl wrote:
> On Sat, Apr 24, 2021 at 12:49:45PM +0200, Andre Vehreschild wrote:
> >
> > @Steve: Is this your correct mail address for the changelog or do you
> > prefer a differe
301 - 371 of 371 matches
Mail list logo
