..., 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
t, here it is.
>
> Best regards
>
> Thomas
--
Andre Vehreschild * Email: vehre ad gmx dot de
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
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
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
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
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
?
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
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
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
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
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
.
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
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
: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
nt’
> test_reduce.f90:23:2: note: ‘_gfortran_reduce_scalar’ was previously
> declared here
> test_reduce.f90:23:2: note: code may be misoptimized unless
> ‘-fno-strict-aliasing’ is used
> /usr/bin/ld: warning: /tmp/ccfEUYXA.ltrans0.ltrans.o: requires executable
> stack (because the .note.GNU-stack section is executable)
>
> The last one is unavoidable because of the use of the wrapper for
> 'operation' that allows type agnostic use of pointer arithmetic in the
> library functions. I am working on the type mismatch, which occurs when
> different wrapper types appear in the same namespace.
>
> Clearly there is a fair amount to do: clear the commented out
> sections/lines, testcases and documentation.
>
> Paul
--
Andre Vehreschild * Email: vehre ad gmx dot de
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
!
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
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
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
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
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
for the patch!
>
> Best regards
>
> Thomas
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
.
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
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
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:
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,
> >
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
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 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
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:
x86_64-pc-linux-gnu. ON for mainline?
>
> Thanks,
> Harald
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
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).
>
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:
> >
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.
> >
> >
:
* gfortran.dg/coarray/send_char_array_1.f90: Extend test to
catch more cases.
* gfortran.dg/coarray_42.f90: Invert tests use, because no
longer a send is needed when local memory in a coarray is
allocated.
--
Andre Vehreschild * Email: vehre ad gmx dot de
From
/coarray/get_with_scalar_fn.f90: New test.
--
Andre Vehreschild * Email: vehre ad gmx dot de
From b49b88f98d6cb63058c480e8646603f4dd82f83a Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Wed, 22 Jan 2025 13:36:21 +0100
Subject: [PATCH 3/7] Fortran: Allow to use non-pure/non-elemental
.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/coarray_allocated.f90: Adapt to new method
of checking on remote image.
* gfortran.dg/coarray_lib_alloc_4.f90: Same.
--
Andre Vehreschild * Email: vehre ad gmx dot de
From ca929ce62d0f07b274113a20a5900d525526d25e Mon Sep 17 00:00
(_gfortran_caf_finalize): Free memory preventing
leaks.
(_gfortran_caf_get_by_ct): Fix constness.
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 2d20eba3b976ae368167620a3a3846b81c0a213d Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Wed, 8 Jan 2025 12:33:27 +0100
Subject: [PATCH 1/7
/coarray_lib_comm_1.f90: Fix up scan_trees.
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 86dd7d61b13942f5f198a21aa22b3eb46fa658b1 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 7 Feb 2025 11:25:31 +0100
Subject: [PATCH 6/7] Fortran: Add transfer_between_remotes [PR107635]
Add the
64-pc-linux-gnu /F41. No
issues where detected. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
renamed ABI
function.
* gfortran.dg/coarray_stat_function.f90: Same.
* gfortran.dg/coindexed_1.f90: Same.
--
Andre Vehreschild * Email: vehre ad gmx dot de
From abed47e1c0a28eff5b8c93e60b037d2bd7fd8999 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Wed, 8 Jan 2025 12:33
t; called "interp".
> >
> > Comments? Suggestions for a different name? Should I just go ahead
> > and create it?
> >
> > Best regards
> >
> > Thomas
>
> Your suggestion is reasonable and it happens often enough to be useful.
>
Hi Paul,
looks fine to me.
Thanks for the patch,
Andre
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 178 3637538 * ve...@gmx.de
Am 6. Februar 2025 16:49:18 schrieb Paul Richard Thomas
:
This regression must have been generated during my ASSOCIATE campaign; I am
not sure when
t
> it will have to be reworked in 16. However, I am perfectly prepared to do
> the backport, which should keep at least two customers happy :-) Thoughts?
>
> Regards
>
> Paul
--
Andre Vehreschild * Email: vehre ad gmx dot de
bfortran/118571
>
> libgfortran/ChangeLog:
>
> * io/write.c (write_utf8_char4): Adjust the src_len to the
> format width w_len when greater than zero.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/utf8_3.f03: New test.
--
Andre Vehreschild * Email: vehre ad gmx dot de
LOCAL_INIT are not yet supported for ‘*do
> concurrent*’ constructs at *(1)*
>
>
> % gfortran --version
>
> GNU Fortran (GCC) 15.0.1 20250119 (experimental)
>
> Copyright (C) 2025 Free Software Foundation, Inc.
>
> This is free software; see the source for copying conditions. There is NO
>
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Andre Vehreschild * Email: vehre ad gmx dot de
terface. Look for the formal symbol by name in the containing
> proc and use its backend decl.
> * trans-expr.cc (gfc_apply_interface_mapping_to_expr): For the
> same reason, match the name, rather than the symbol address to
> perform the mapping.
>
> gcc/testsuite/
> PR fortran/
uild & regtested on x86-64-gnu-linux.
> OK? Other thoughts?
>
> Tobias
>
> PS: The issue is long standing but since a recent GCC 15
> commit (cf. PR), the issue is now triggered and causes an ICE
> for the testcase from the PR.
--
Andre Vehreschild * Email: vehre ad gmx dot de
tran-env.def"
> - create_intrinsic_function (symbol[i].name, symbol[i].id,
> mod,
> - INTMOD_ISO_FORTRAN_ENV, false,
> - NULL);
> - break;
> + create_intrinsic_function (symbol[i].name, symbol[i].id, mod
c_prototypes): Adjust prototype.
> * parse.cc (gfc_parse_file): Adjust call to gfc_dump_c_prototypes.
>
>
> Regression-tested. As for testcases... as the dump is to
> standard output, I don't know how to do that. If anybody
> has an idea, please let me know.
>
> OK for trunk?
>
> Best regards
>
> Thomas
>
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Hi Mikael,
merged only patch #2 as gcc-15-6729-gd1071402055.
Thanks for the ok and regards,
Andre
On Wed, 8 Jan 2025 22:46:15 +0100
Mikael Morin wrote:
> Le 08/01/2025 à 18:23, Andre Vehreschild a écrit :
> >
> > First of all the recursive attr must not be set on vty
2025 22:41:13 +0100
Mikael Morin wrote:
> Le 08/01/2025 à 18:37, Jakub Jelinek a écrit :
> > On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote:
> >> gcc/fortran/ChangeLog:
> >>
> >>PR fortran/118337
> >>* module.cc (use_iso_for
ing it yourself.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards and many thanks to all your valued input and patches,
Andre
On Wed, 8 Jan 2025 16:34:18 +0100
Jakub Jelinek wrote:
> On Wed, Jan 08, 2025 at 04:09:36PM +0100, Andre Vehreschild wrote:
> > One
fail anymore.
Now regtesting.
- Andre
On Wed, 8 Jan 2025 15:59:43 +0100
Jakub Jelinek wrote:
> On Wed, Jan 08, 2025 at 03:48:46PM +0100, Andre Vehreschild wrote:
> > Hi,
> >
> > I have added this small patch (attached). Unfortunately I got regressions
> >
> >
ne ok for trunk (that is one I've fully tested already)
> and the second one too if it passes bootstrap/regtest?
>
> Jakub
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 10e43b4c5953a30a2fb6c89dc815290484f29d54 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date:
et_uint_kind_from_width_isofortranenv (64),
> GFC_STD_UNSIGNED) +
>
> /* The arguments to NAMED_KINDARRAY are:
> -- an internal name
> @@ -154,6 +138,26 @@ NAMED_DERIVED_TYPE (ISOFORTRAN_TEAM_TYPE
> ? get_int_kind_from_node (ptr_type_node)
> : gfc_default_integer_kind, GFC_STD_F2018)
>
> +NAMED_INTCST (ISOFORTRANENV_LOGICAL8, "logical8", \
> + gfc_get_int_kind_from_width_isofortranenv (8), GFC_STD_F2023)
> +NAMED_INTCST (ISOFORTRANENV_LOGICAL16, "logical16", \
> + gfc_get_int_kind_from_width_isofortranenv (16), GFC_STD_F2023)
> +NAMED_INTCST (ISOFORTRANENV_LOGICAL32, "logical32", \
> + gfc_get_int_kind_from_width_isofortranenv (32), GFC_STD_F2023)
> +NAMED_INTCST (ISOFORTRANENV_LOGICAL64, "logical64", \
> + gfc_get_int_kind_from_width_isofortranenv (64), GFC_STD_F2023)
> +NAMED_INTCST (ISOFORTRANENV_REAL16, "real16", \
> + gfc_get_real_kind_from_width_isofortranenv (16), GFC_STD_F2023)
> +
> +NAMED_UINTCST (ISOFORTRANENV_UINT8, "uint8", \
> +gfc_get_uint_kind_from_width_isofortranenv (8),
> GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT16, "uint16", \
> +gfc_get_uint_kind_from_width_isofortranenv (16),
> GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT32, "uint32", \
> +gfc_get_uint_kind_from_width_isofortranenv (32),
> GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT64, "uint64", \
> +gfc_get_uint_kind_from_width_isofortranenv (64),
> GFC_STD_UNSIGNED) +
> #undef NAMED_INTCST
> #undef NAMED_UINTCST
> #undef NAMED_KINDARRAY
>
> Jakub
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
x27;t know it, don't bother.
- Andre
On Wed, 8 Jan 2025 12:05:47 +0100
Mikael Morin wrote:
> Hello,
>
> Le 08/01/2025 à 11:34, Andre Vehreschild a écrit :
> >
> > The flag is used now to indicate, that a type can (indirectly) reference
> > itself. Not having t
wrote:
> On Wed, Jan 08, 2025 at 11:53:53AM +0100, Andre Vehreschild wrote:
> > Well, thinking about it, it smells like a side-effect of the 116669 fix. A
> > type getting the recursive marker enforces the generation of the vtype for
> > it. I don't see yet, why the iso_c_
ed, 8 Jan 2025 11:42:28 +0100
Jakub Jelinek wrote:
> On Wed, Jan 08, 2025 at 11:34:35AM +0100, Andre Vehreschild wrote:
> > marking the vtypes as recursive is odd, but should not be taken as any
> > incompatibility marker. Pre version 15 gfortran does not check the recursive
&
IGNED) -NAMED_UINTCST (ISOFORTRANENV_UINT64, "uint64", \
> -gfc_get_uint_kind_from_width_isofortranenv (64),
> GFC_STD_UNSIGNED) +
>
> /* The arguments to NAMED_KINDARRAY are:
> -- an internal name
> @@ -154,6 +138,26 @@ NAMED_DERIVED_TYPE (ISOFORTRAN_TEAM_TYPE
> ? get_int_kind_from_node (ptr_type_node)
> : gfc_default_integer_kind, GFC_STD_F2018)
>
> +NAMED_INTCST (ISOFORTRANENV_LOGICAL8, "logical8", \
> + gfc_get_int_kind_from_width_isofortranenv (8), GFC_STD_F2023)
> +NAMED_INTCST (ISOFORTRANENV_LOGICAL16, "logical16", \
> + gfc_get_int_kind_from_width_isofortranenv (16), GFC_STD_F2023)
> +NAMED_INTCST (ISOFORTRANENV_LOGICAL32, "logical32", \
> + gfc_get_int_kind_from_width_isofortranenv (32), GFC_STD_F2023)
> +NAMED_INTCST (ISOFORTRANENV_LOGICAL64, "logical64", \
> + gfc_get_int_kind_from_width_isofortranenv (64), GFC_STD_F2023)
> +NAMED_INTCST (ISOFORTRANENV_REAL16, "real16", \
> + gfc_get_real_kind_from_width_isofortranenv (16), GFC_STD_F2023)
> +
> +NAMED_UINTCST (ISOFORTRANENV_UINT8, "uint8", \
> +gfc_get_uint_kind_from_width_isofortranenv (8),
> GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT16, "uint16", \
> +gfc_get_uint_kind_from_width_isofortranenv (16),
> GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT32, "uint32", \
> +gfc_get_uint_kind_from_width_isofortranenv (32),
> GFC_STD_UNSIGNED) +NAMED_UINTCST (ISOFORTRANENV_UINT64, "uint64", \
> +gfc_get_uint_kind_from_width_isofortranenv (64),
> GFC_STD_UNSIGNED) +
> #undef NAMED_INTCST
> #undef NAMED_UINTCST
> #undef NAMED_KINDARRAY
>
> Jakub
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
elf is that the Ada FE doesn't tell
> Ada version at all - there is just "GNU Ada" and dwarf2out.cc right now
> implies it is Ada 95 for DWARF3 and Ada 83 otherwise.
> And in the Fortran case, while the FE provides a version, it only
> does so for Fortran 2003 and 2008 (
Hi Jerry,
thanks again for the review. Pushed as gcc-15-6618-g25b380dc63c.
Regards,
Andre
On Mon, 6 Jan 2025 09:15:39 -0800
Jerry D wrote:
> On 1/6/25 2:08 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > attached patch has been rebased to latest trunk. Just ping
Hi Jerry,
thanks for the review. Pushed as gcc-15-6615-gd8970909490
with the tweak ;-)
Have a good year and thanks again,
Andre
On Mon, 6 Jan 2025 09:13:27 -0800
Jerry D wrote:
> On 1/6/25 6:21 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > during looking for
,
Andre
On Mon, 6 Jan 2025 11:06:46 +0100
Andre Vehreschild wrote:
> Hi all,
>
> pinging attached rebased patch.
>
> Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> - Andre
>
> On Thu, 12 Dec 2024 14:50:13 +0100
> Andre Vehreschild wrote:
>
&
Hi all,
attached patch has been rebased to latest trunk. Just pinging!
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
- Andre
On Fri, 13 Dec 2024 12:10:58 +0100
Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes deep-copying (or rather its former abs
1 - 100 of 303 matches
Mail list logo
