actions.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From e073b32bd792f7db92334e89e546095c9ad583f8 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Wed, 17 Jul 2024 12:30:52 +0200
Subject: [PATCH
Hi all,
and the last ping.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
On Thu, 11 Jul 2024 16:05:09 +0200
Andre Vehreschild wrote:
> Hi all,
>
> the attached patch fixes a segfault in the compiler, where for pointer
> components of a
Hi all,
and another ping...
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
- Andre
On Thu, 11 Jul 2024 15:42:54 +0200
Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes using of coarrays as dummy arguments. The coarray
> dummy argument was not
Hi all,
pinging for attached patch rebased on master and my patch for 78466.
Anyone in for a review?
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
On Wed, 10 Jul 2024 14:51:53 +0200
Andre Vehreschild wrote:
> Hi all,
>
> the patch attac
Hi all,
just pinging on this patch. The attached patch is rebased to an unmodified
master as of this afternoon (CEST 3 p.m.).
Anyone in for a review?
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
On Wed, 10 Jul 2024 11:17:44 +0200
Andre Vehreschild
;> > On Sat, 13 Jul 2024 at 10:58, Paul Richard Thomas <
> >> > paul.richard.tho...@gmail.com> wrote:
> >> >
> >> >> Hi All,
> >> >>
> >> >> After messing around with argument mapping, where I found and fixed
> >> >> another bug, I realised that the problem lay with simplification of
> >> >> len_trim with an argument that is the element of a parameter array.
> >> The fix
> >> >> was then a straightforward lift of existing code in expr.cc. The
> >> mapping
> >> >> bug is also fixed by supplying the se string length when building
> >> character
> >> >> typespecs.
> >> >>
> >> >> Regtests just fine. OK for mainline? I believe that this is safe for
> >> >> backporting to 14-branch before the 14.2 release - thoughts?
> >>
> >> If you manage to correct/fix the above issues, I am fine with
> >> backporting, as this appears a very reasonable fix.
> >>
> >> Thanks,
> >> Harald
> >>
> >> >> Regards
> >> >>
> >> >> Paul
> >> >>
> >> >
> >>
> >>
--
Andre Vehreschild * Email: vehre ad gmx dot de
> >>
> > >> After messing around with argument mapping, where I found and fixed
> > >> another bug, I realised that the problem lay with simplification of
> > >> len_trim with an argument that is the element of a parameter array. The
> > fix
> > >> was then a straightforward lift of existing code in expr.cc. The mapping
> > >> bug is also fixed by supplying the se string length when building
> > character
> > >> typespecs.
> > >>
> > >> Regtests just fine. OK for mainline? I believe that this is safe for
> > >> backporting to 14-branch before the 14.2 release - thoughts?
> >
> > If you manage to correct/fix the above issues, I am fine with
> > backporting, as this appears a very reasonable fix.
> >
> > Thanks,
> > Harald
> >
> > >> Regards
> > >>
> > >> Paul
> > >>
> > >
> >
> >
--
Andre Vehreschild * Email: vehre ad gmx dot de
,
Andre
--
Andre Vehreschild * Email: vehre ad gcc dot gnu dot org
From 88f209316a980fbe78423d6aba747bb6b7fd404f Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Thu, 11 Jul 2024 15:44:56 +0200
Subject: [PATCH] [Fortran] Fix ICE in recompute_tree_invariant_for_addr_expr,
at tree.c:4535 [PR84244
Hi all,
attached patch fixes using of coarrays as dummy arguments. The coarray
dummy argument was not dereferenced correctly, which is fixed now.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gcc dot gnu dot org
Hi Richard,
bootstrap finally passed and the fix is now merged as
gcc-15-1971-gb9513c6746b
Thanks for your patience.
- Andre
On Thu, 11 Jul 2024 14:01:02 +0200
Richard Biener wrote:
> On Thu, Jul 11, 2024 at 11:24 AM Andre Vehreschild
> wrote:
> >
> > Hi Rich
Hi Richard,
would that be sufficient? Bootstrap is still running for me...
From c30c2cf829a094ba5e4c2c31333bed6e8c0d32af Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Thu, 11 Jul 2024 11:21:04 +0200
Subject: [PATCH] [Fortran] Fix bootstrap broken by gcc-15-1965-ge4f2f46e015
gcc
Hi Richard,
I am sorry to hear that. Shall I revert?
- Andre
On Thu, 11 Jul 2024 10:57:48 +0200
Richard Biener wrote:
> On Thu, Jul 11, 2024 at 10:54 AM Richard Biener
> wrote:
> >
> > On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild
> > wrote:
> > >
&
Hi Harald,
thank you very much for ok'ing this large patch. Merged as
gcc-15-1965-ge4f2f46e015
Looking forward to get (no) bug reports ;-)
Thanks again,
Andre
On Wed, 10 Jul 2024 20:52:37 +0200
Harald Anlauf wrote:
> Hi Andre,
>
> Am 10.07.24 um 10:45 schrieb Andre Vehreschil
is of course still
provided and needed later on.
I hope this fixes the ICE in the IPA: inline phase, because I never saw it. Is
that what you had in mind @Richard?
Regtests ok on x86_64-pc-linux-gnu/Fedora 39. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 32d8a8da4e1e6120c515932878994514e04c909d Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Thu, 31 Dec 2020 10:40:30 +0100
Subject: [PATCH] Fortran: Fix Explicit cobounds of a procedures parameter not
respected [PR78466
39. Ok for mainline?
Regards,
Andre
On Fri, 5 Jul 2024 22:10:16 +0200
Harald Anlauf wrote:
> Hi Andre,
>
> Am 03.07.24 um 12:58 schrieb Andre Vehreschild:
> > Hi Harald,
> >
> > I am sorry for the long delay, but fixing the negative stride lead from one
> >
wrote:
> Hi Andre,
>
> Am 19.06.24 um 09:07 schrieb Andre Vehreschild:
> > Hi Harald,
> >
> > thank you for the investigation and useful tips. I had to figure what went
> > wrong here, but I now figured, that the array needs repacking when a
> > nega
the PR is marked as a regression, is it also OK for backporting?
>
> Thanks,
> Harald
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
e me with any insights; eg, by rerunning the testcase outside
> of the dejagnu framework?
>
> Thank you for doing this testing, by the way, even if the failure is a bit
> obscure at the moment.
>
> Best regards
>
> Paul
--
Andre Vehreschild * Email: vehre ad gmx dot de
est and to assign this patch to the dustbin of history. It
> should be rather straightforward to provide an interface to the existing
> library functions that produces significantly less inline code than my
> implementation.
>
> I will commit the patch, though, and will revert as and when class-aware
> library functions are in place.
>
> Thanks again
>
> Paul
--
Andre Vehreschild * Email: vehre ad gmx dot de
most of the test statements are factored out into
> their own subroutines in order to expose the code generated for each. This
> was essential for the debugging but can be undone if preferred.
>
> Regtests just fine - OK for mainline?
>
> Paul
--
Andre Vehreschild * Email: vehre ad gmx dot de
on my
> side. I like gfc_class_set_vptr. Please remove the commented out assert,
> unless you intend to deploy it.
>
> OK for mainline.
>
> Thanks for the patches.
>
> Regards
>
> Paul
>
>
> On Fri, 21 Jun 2024 at 07:39, Andre Vehreschild wrote:
>
> > Hi Paul
> Paul
>
>
> On Tue, 11 Jun 2024 at 13:57, Andre Vehreschild wrote:
>
> > Hi all,
> >
> > the attached patch fix the last case in the bug report. The inital example
> > code
> > is already fixed by the combination of PR90068 and PR90072. The issue
linux-gnu. OK for mainline?
>
> Thanks,
> Harald
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
allocated potentially by pack, and also
updated the testcase to include the negative stride.
Regtests fine on x86_64-pc-linux-gnu/Fedora 39. Ok for mainline?
Regards,
Andre
On Sun, 16 Jun 2024 23:27:46 +0200
Harald Anlauf wrote:
<< snipped for brevity >>>
--
Andre Vehreschild * E
> Thanks for the patch!
>
> Harald
>
>
> Am 14.06.24 um 09:22 schrieb Andre Vehreschild:
> > Hi all,
> >
> > I messed up renaming of the coarray_alloc_comp-test. This is fixed in the
> > second version of the patch. Sorry for the inconvenience.
> >
> &g
.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 86ac3179e1314ca1c41f52025c5a156ad7346dc1 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 14 Jun 2024 16:54:37 +0200
Subject: [PATCH] Fortran: [PR96992] Fix rejecting class arrays of different
ranks as storage a
mments. I think that I have
> incorporated them fully in the attached.
>
> OK for mainline and ...?
>
> Paul
>
>
> On Mon, 10 Jun 2024 at 08:19, Andre Vehreschild wrote:
>
> > Hi Paul,
> >
> > while looking at your patch I see calls to gfc_add_init_cle
Jun 2024 16:12:38 +0200
Andre Vehreschild wrote:
> Hi all,
>
> attached patch has already been present in 2020, but lost my attention. It
> fixes an ICE in the testsuite. The old mails description is:
>
> attached patch fixes PR96418 where the code in the testsuite when compile
was
derefed as an array, but it was no array. Introducing the test for the
descriptor removes the ICE.
Regtests ok on x86_64-linux/Fedora 39. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From e56f32ed836c1ecc2b46497d1d7b9c7c08749521 Mon Sep 17 00:00:00
. What do you think?
On x86_66 Fedora 39 this regtests fine.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 9847eaa6aa96eead01ab26800812bc5aeb6443d2 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Tue, 11 Jun 2024 12:52:26 +0200
Subject: [PATCH 3/3] Add
on x86_64 Fedora 39. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From e3a7f07e7dfad7ab347f148d2d46b633c0bbdecc Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Thu, 6 Jun 2024 14:01:13 +0200
Subject: [PATCH 1/3] Fortran: Set the vptr of a class typed
?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From f9018fa7d4dc752331e62963c9cf86ab01a1bfc5 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 7 Jun 2024 08:57:36 +0200
Subject: [PATCH 2/3] Use gfc_reset_vptr more consistently.
The vptr for a class type is set
understand that this is long way to go. Therefore I first like to ask about
the general perception of this idea. So I like to hear constructive criticism.
Could I explain it good enough? Do you think it is worth pursuing?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
question about me issue with doing gomp-fortran tests:
https://gcc.gnu.org/pipermail/fortran/2024-June/060542.html
Do you have any insight of what I am doing wrong?
Regards,
Andre
On Sat, 8 Jun 2024 21:52:42 +0200
Tobias Burnus wrote:
> Andre Vehreschild wrote:
> >> PS
ix ensures that:
> (i) These variables are placed correctly in the tlink chain, respecting
> inter-dependencies; and (ii) The dependent initializations are placed at
> the end of the wrapped block init chain. The details appear in the
> comments in the patch. It is entirely possible that a less clunky fix
> exists but I failed to find it.
>
> OK for mainline?
>
> Regards
>
> Paul
--
Andre Vehreschild * Email: vehre ad gmx dot de
This sounds to me like another application for a try-finally, but that is just
a first shot w/o any deep thought on the aspects. If you like a rubber ducking
feel free to contact me. Sometimes talking about it helps...
Thanks again and regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
again for the review.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
only when the libs are not found?
> PS: Welcome back to the gfortran effort.
Thanks, I hope to produce a constant stream of patches in the next year or even
longer.
Thank you for your time. If you have any other idea that I could test, please
let me know.
Regards,
Andre
--
An
,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 367e8be8945a32dcb24c4bfb9558abf687a53fe0 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Thu, 27 Jul 2023 14:51:34 +0200
Subject: [PATCH] Add finalizer creation to array constructor for functions of
derived type.
PR fortran/90068
,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From e79072de7279cc6863914588e4a0457f0c3493fd Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Wed, 19 Jul 2023 11:57:43 +0200
Subject: [PATCH] Fix returned type to be allocatable for user-functions.
The returned type of user
t;" } {
set lang_source_re {^.*\.[fF](|90|95|03|08)$}
This is just a first shot. With the patch the test compile and run ok. But now
my question: What am I doing wrong? I am working on gcc-master with only a few
commits behind. Is testing libgomp-fortran fine for everyone else?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
some light. Thanks you very much for
that.
Regards,
Andre
On Tue, 28 May 2024 21:45:56 +0200
Harald Anlauf wrote:
> Hi Andre,
>
> On 5/28/24 14:10, Andre Vehreschild wrote:
> > Hi all,
> >
> > the attached patch fixes a memory leak with unlimited polymorphic
by the Souvereign Tech Fund. Yes, the funding has been
granted and Nicolas, Mikael and me will be working on some Fortran topics in
the next 12-18 months.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From edd6c94b802732b0dd742ef9eca4d74aaaf6d91b Mon Sep 17 00:00:00 2001
From: Andre
TREE_CODE (expr) == REALPART_EXPR)
> > {
> > @@ -1170,6 +1186,7 @@ build_access_from_expr_1 (tree expr, gimple *stmt,
> > bool write) case COMPONENT_REF:
> > case ARRAY_REF:
> > case ARRAY_RANGE_REF:
> > +case BIT_FIELD_REF:
> >ret = create_access (expr, stmt, write);
> >break;
> >
> > @@ -1549,6 +1566,7 @@ make_fancy_name_1 (tree expr)
> >obstack_grow (_obstack, buffer, strlen (buffer));
> >break;
> >
> > +case BIT_FIELD_REF:
> > case ADDR_EXPR:
> >make_fancy_name_1 (TREE_OPERAND (expr, 0));
> >break;
> > @@ -1564,7 +1582,6 @@ make_fancy_name_1 (tree expr)
> > }
> >break;
> >
> > -case BIT_FIELD_REF:
> > case REALPART_EXPR:
> > case IMAGPART_EXPR:
> >gcc_unreachable (); /* we treat these as scalars. */
> > @@ -3769,7 +3786,8 @@ sra_modify_expr (tree *expr, gimple_stmt_iterator
> > *gsi, bool write) tree type, bfr, orig_expr;
> >bool partial_cplx_access = false;
> >
> > - if (TREE_CODE (*expr) == BIT_FIELD_REF)
> > + if (TREE_CODE (*expr) == BIT_FIELD_REF
> > + && (write || !sra_handled_bf_read_p (*expr)))
> > {
> >bfr = *expr;
> >expr = _OPERAND (*expr, 0);
> >
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
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 backport
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 a
> &g
dre,
>
> 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 Fortran
> wro
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
gfc_free_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 regtest
7 gfc_parse_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 variant
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?
Regards,
Andre
Andre
-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
:-) 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
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:
> >
>
ho (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 images sup
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
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
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,
> >
ial 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
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
(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
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
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
ojects. 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
essible 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
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
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 initially
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:27:26 +010
riptor_data_set (, 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
>
> T
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, whic
.
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
in 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
_CO_SUM:
> 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:
> >
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 m
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
--
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
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
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.
> >
> > C
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
> >> issue wi
--
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
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 reviewing
ss 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!
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 Vehreschild via
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.c
@@
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
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 cc9d
D 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 interested. If you know others who might
> &
88 matches
Mail list logo
