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 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
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
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 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
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
?
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 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
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
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
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
..., 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 /
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
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.
> >
> >
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
.
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
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
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
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
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
: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
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
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
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
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
?
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
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
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'
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
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
t, here it is.
>
> Best regards
>
> Thomas
--
Andre Vehreschild * Email: vehre ad gmx dot de
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
:
> 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
!
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
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
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
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
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
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).
>
x86_64-pc-linux-gnu. ON for mainline?
>
> Thanks,
> Harald
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
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:
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
Hi all,
I just merged the patch series as gcc-15-7644-gd3244675441.
Thanks for all the reviews.
I will now prepare the Relasenotes.
Regards and thanks again,
Andre
On Tue, 18 Feb 2025 18:13:53 +0100
Thomas Koenig wrote:
> Am 18.02.25 um 16:00 schrieb Andre Vehreschild:
> >
Hi 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
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
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,
> >
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
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
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
.
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
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:
for the patch!
>
> Best regards
>
> Thomas
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
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
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 :-)
&
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
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
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,
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
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
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
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
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
Makefile next.
>
> Undergoing testing on x86_64-linux, OK to push?
> FX
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
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
-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
.
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
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!
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
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
601 - 686 of 686 matches
Mail list logo
