94b2e6cb1cc4feb122bf77f19a657c97bffa9b42 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 19 Jan 2024 21:20:44 +0100
Subject: [PATCH] Fortran: fix wrong array bounds check [PR113471]
gcc/fortran/ChangeLog:
PR fortran/113471
* trans-array.cc (array_bound_check_elemental): Array bounds check
shall apply
2001
From: Harald Anlauf
Date: Sat, 13 Jan 2024 22:00:21 +0100
Subject: [PATCH] Fortran: intrinsic ISHFTC and missing optional argument SIZE
[PR67277]
gcc/fortran/ChangeLog:
PR fortran/67277
* trans-intrinsic.cc (gfc_conv_intrinsic_ishftc): Handle optional
dummy argument for SIZE passed
Hi Bernhard,
On 1/12/24 10:44, Bernhard Reutner-Fischer wrote:
On Wed, 10 Jan 2024 23:24:22 +0100
Harald Anlauf wrote:
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 82f388c05f8..88502c1e3f0 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2926,6
to
the first loop control variable (for the case of loop nests),
which translates into the innermost loop in gcc's representation.
Regtested on x86_64-pc-linux-gnu.
OK for mainline?
Comments?
Thanks,
Harald
From 0df60f02c399a6bf65850ecd5719b25b3de6676f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Hi Paul,
your patch looks already very impressive!
Regarding the patch as is, I am still trying to grok it, even with your
explanations at hand...
While the testcase works as advertised, I noticed that it exhibits a
runtime memleak that occurs for (likely) each case where the associate
target
().
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 49f5c89f6bdddbb225ca70f8df78a75252b0b2d5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 7 Jan 2024 22:24:25 +0100
Subject: [PATCH] Fortran: SIZE optional DIM argument having OPTIONAL+VALUE
attributes [PR113245
Hi Jerry!
On 1/7/24 19:40, Jerry D wrote:
Committed as simple and obvious. Initial patch thanks to Steve.
When using git gcc-commit-mklog how does one add in the coauthor?
% git help gcc-commit-mklog
...
--co CO Add Co-Authored-By trailer (comma separated)
However, I usually
- and common - gfc_charlen_int_kind. It's almost trivial
now.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 18f212aaca8a13fbd2f40cc7636b1a20185cc01e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 5 Jan 2024 22:24:25 +0100
Subject: [PATCH] Fortran: bogus warnings
ress the underlying issues
of pr55978).
Thanks,
Harald
From 93c96e3ad0024a397115aa17bf29c7efc6b535a1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 3 Jan 2024 20:21:00 +0100
Subject: [PATCH] Fortran: fix FE memleak
gcc/fortran/ChangeLog:
* trans-types.cc (gfc_get_nodesc_array_type): Clear used
Am 02.01.24 um 20:37 schrieb Steve Kargl:
On Tue, Jan 02, 2024 at 08:31:15PM +0100, Harald Anlauf wrote:
we might want to update changes.html to reflect this. How about:
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 403feb06..9b16f5e3 100644
--- a/htdocs/gcc-14
, preprocessed files
with the .fii extension will be generated from
free-form source files such as .F90 and
Cheers,
Harald
Am 17.11.23 um 12:38 schrieb Tobias Burnus:
Hi Harald, hi all,
On 16.11.23 20:30, Harald Anlauf wrote:
On 11/16/23 14:01, Tobias Burnus wrote:
This adds -std
Hi Thomas!
Am 30.12.23 um 12:08 schrieb Thomas Koenig:
Replying to myself...
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
wording?
Or maybe this is better:
diff --git
Hi Rimvydas!
Am 28.12.23 um 08:09 schrieb Rimvydas Jasinskas:
On Wed, Dec 27, 2023 at 10:34 PM Harald Anlauf wrote:
The patch is almost fine, except for a strange wording here:
+@smallexample
+gfortran -save-temps -c foo.F90
+@end smallexample
+
+preprocesses to in @file{foo.fii}, compiles
Hi Rimvydas!
Am 24.12.23 um 02:33 schrieb Rimvydas Jasinskas:
Documentation part.
The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings.
The patch is almost fine, except for a strange wording here:
+@smallexample
+gfortran -save-temps -c foo.F90
+@end smallexample
+
Am 20.12.23 um 05:32 schrieb Rimvydas Jasinskas:
Dear all,
In the spirit of c/c++ using the .i/.ii extensions for intermediates,
use the .fi/.fii intermediate extensions for gfortran fixed/free form
sources when -save-temps is invoked to avoid various issues.
I checked with Jerry on
From 1850bb6cbae7229e2c26e66a0a621817339f85e9 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 18 Dec 2023 18:59:02 +0100
Subject: [PATCH] Fortran: update DATE_AND_TIME intrinsic for Fortran 2018
[PR96580]
Fortran 2018 allows a non-default integer kind for its VALUES argument if
it has
From: Harald Anlauf
Date: Sat, 16 Dec 2023 19:14:55 +0100
Subject: [PATCH] Fortran: fix argument passing to CONTIGUOUS,TARGET dummy
[PR97592]
gcc/fortran/ChangeLog:
PR fortran/97592
* trans-expr.cc (gfc_conv_procedure_call): For a contiguous dummy
with the TARGET attribute, the effective
where MOLD is a pointer. I think it is wrong here.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From c73b248ec16388ed1ce109fce8a468a87e367085 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 8 Dec 2023 11:11:08 +0100
Subject: [PATCH] Fortran: allow NULL() for POINTER
tested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 15810999b2f5cb4d8fbd69cb488c9b0c58e6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 6 Dec 2023 20:42:27 +0100
Subject: [PATCH] Fortran: function returning contiguous class array [PR105543]
gcc/fortran/ChangeLog:
PR f
Hi Paul,
On 12/6/23 17:09, Paul Richard Thomas wrote:
Dear All,
This patch was rescued from my ill-fated and long winded attempt to provide
a fix-up for function selector references, where the function is parsed
after the procedure containing the associate/select type construct (PRs
89645 and
arguments that mishandled this. This revealed a few cases
in the testsuite that were matching the wrong patterns...
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From aa25d35cb866f7f333b656938224866a70b93a69 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 4 Dec 2023 22
?
Thanks,
Harald
On 11/28/23 20:56, Harald Anlauf wrote:
Hi FX,
On 11/28/23 18:07, FX Coudert wrote:
Hi Harald,
The patch looks OK to me. Probably wait a bit for another opinion,
since I’m not that active and I may have missed something.
Thanks,
FX
thanks for having a look.
In the meantime I
Hi Mikael,
On 12/1/23 21:24, Mikael Morin wrote:
Hello,
Le 30/11/2023 à 22:06, Harald Anlauf a écrit :
the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked
is a different issue.)
Thanks,
Harald
From 38433016def0337a72cb0ef0029cd2c05d702282 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 30 Nov 2023 21:53:21 +0100
Subject: [PATCH] Fortran: copy-out for possibly missing OPTIONAL CLASS
arguments [PR112772]
gcc/fortran/ChangeLog:
PR fortran
regressions
and thus needs more work.)
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 023dc4691c73ed594d5c1085f1aab897ca4a7153 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 29 Nov 2023 21:47:24 +0100
Subject: [PATCH] Fortran: fix TARGET attribute
ald
From 63879942b491e23eefc6da4d80c5492434e42ec8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 28 Nov 2023 20:19:14 +0100
Subject: [PATCH] Fortran: deferred-length character optional dummy arguments
[PR93762,PR100651]
gcc/fortran/ChangeLog:
PR fortran/93762
PR fortran/100651
* trans-expr.cc (gfc_conv_miss
.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As the fix is local and affects only deferred-length character,
would it be ok to backport to 13-branch?
Thanks,
Harald
From 8ce1c8e7d0390361a1507000b7abbf6509b2fee9 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 27 Nov 2023 20:19:11 +0100
on x86_64-pc-linux-gnu. OK for mainline?
The PR is marked as a regression (the warning appeared in gcc-9).
It looks simple enough for backporting, or does anybody see any
risk here?
Thanks,
Harald
From a962ab0417f5ff2efd51e710ae370d9f4a4b9f1a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 23
are no further comments, I will commit once I am able to
fully build again with --disable-bootstrap and -march=native ...
Thanks,
Harald
From 56386f4f332cf8970a424ba67678335fa6186e4c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 22 Nov 2023 20:57:59 +0100
Subject: [PATCH] Fortran: r
is there or not.
Now these testcases are { dg-do run }. Therefore I would like to
fix these testcases, independent of the work on fixing pr104819.
Comments?
Thanks,
Harald
From cbb0c61f9d6f06667666a33da6e6ce3213a92248 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 22 Nov 2023 21:45:46 +0100
Subject
Hi Steve,
On 11/22/23 19:03, Steve Kargl wrote:
On Wed, Nov 22, 2023 at 10:36:00AM +0100, Mikael Morin wrote:
OK with this fixed (and the previous comments as you wish), if Steve has no
more comments.
No further comments. Thanks for your patients, Harald.
As side note, I found John
Uhh, it happened again. Attached a wrong patch.
Only looked at the -v3 ... My bad.
Sorry!
Harald
On 11/21/23 22:54, Harald Anlauf wrote:
Hi Mikael, Steve,
On 11/21/23 12:33, Mikael Morin wrote:
Harald, you mentioned the lack of GFC_STD_F2023_DEL feature group in
your first message, but I
Hi Mikael, Steve,
On 11/21/23 12:33, Mikael Morin wrote:
Harald, you mentioned the lack of GFC_STD_F2023_DEL feature group in
your first message, but I don't quite understand why you didn't add one.
It seems to me the most natural way to do this.
thanks for insisting on this variant.
In my
Hi Steve,
On 11/19/23 01:04, Steve Kargl wrote:
On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Not in its current form.
{
+ int first_int_kind = -1;
+ bool f2023 = ((gfc_option.allow_std & GFC_STD_F2023)
for mainline?
Thanks,
Harald
From 44814d9436b2e0be14b76b137602e40f3fdaf805 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 18 Nov 2023 22:51:35 +0100
Subject: [PATCH] Fortran: restrictions on integer arguments to SYSTEM_CLOCK
[PR112609]
Fortran 2023 added restrictions on integer arguments
Hi Tobias,
On 11/17/23 12:38, Tobias Burnus wrote:
Hi Harald, hi all,
On 16.11.23 20:30, Harald Anlauf wrote:
According to the standard one can have 99 lines with only
"&" and then an ";", but then only 100 lines with 1 characters.
I believe a single '&am
Hi Tobias,
On 11/16/23 14:01, Tobias Burnus wrote:
This adds -std=f2023, which is mostly a prep patch for future changes.
However, Fortran 2023, https://j3-fortran.org/doc/year/23/23-007r1.pdf
changes two things which is taken
care in this patch:
(A) In "6.3.2.1 Free form line length":
Hi Paul,
this is OK.
Thanks for the patch!
Harald
Am 11.11.23 um 11:15 schrieb Paul Richard Thomas:
Hi All,
Evidently -w causes gfc_option.allow_std to be set to default, which allows
anything and everything to happen, including these f2003/8 finalizations.
The fix is trivial.
Regtests
Hi Mikael,
this is OK.
Thanks for the patches!
Harald
On 11/7/23 11:24, Mikael Morin wrote:
Hello,
Harald's review of the previous version [1] of these patches spotted a possible
misbehaving case in one patch, and a latent bug in the area of the second
patch.
So here is the second try,
Hi Mikael,
Am 06.11.23 um 20:19 schrieb Mikael Morin:
This change to the testcase:
diff --git a/gcc/testsuite/gfortran.dg/bound_11.f90
b/gcc/testsuite/gfortran.dg/bound_11.f90
index 170eba4ddfd..2e96f843476 100644
--- a/gcc/testsuite/gfortran.dg/bound_11.f90
+++
Hi Mikael,
Am 06.11.23 um 12:43 schrieb Mikael Morin:
Remove the forced overwrite of the first dimension of the result array
descriptor to set it to zero extent, in the function templates for
transformational functions doing an array reduction along a dimension. This
overwrite, which happened
Hi Mikael,
Am 06.11.23 um 12:43 schrieb Mikael Morin:
Remove the early return present in function templates for transformational
functions doing a (masked) reduction of an array along a dimension.
This early return, which triggered if the extent in the reduction dimension
was zero, was wrong
on x86_64-pc-linux-gnu. OK for mainline?
Would it be OK to backport this fix to 13-branch?
Thanks,
Harald
From 1ca323b8d58846d0890a8595ba9fc7bc7eee8fdd Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 3 Nov 2023 19:41:54 +0100
Subject: [PATCH] Fortran: fix issue with multiple references
* interface.cc (upoly_ok): Defined operators using unlimited
polymorphic formal arguments must not override the intrinsic
operator use.
gcc/testsuite/
PR fortran/98498
* gfortran.dg/interface_50.f90: New test.
On Wed, 1 Nov 2023 at 20:12, Harald Anlauf wrote:
Hi Paul,
Am 01.11.23 um 19:02 schrieb
for mainline?
Thanks,
Harald
From 6927612d97a8e7360e651bb081745fc7659a4c4b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 1 Nov 2023 22:55:36 +0100
Subject: [PATCH] Fortran: passing of allocatable/pointer arguments to
OPTIONAL+VALUE [PR92887]
gcc/fortran/ChangeLog:
PR fortran/92887
Hi Paul,
Am 01.11.23 um 19:02 schrieb Paul Richard Thomas:
The interpretation request came in a long time ago but I only just got
around to implementing it.
The updated text from the standard is in the comment. Now I am writing
this, I think that I should perhaps use switch(op)/case rather
Hi Paul,
code->expr1->symtree->n.sym->ts = code->expr2->ts;
+ /* Sometimes the selector expression is given the typespec of the
+'_data' field, which is logical enough but inappropraite here. */
s/inappropraite/inappropriate/
+ if (code->expr2->ts.type
?
Thanks,
Harald
From 9d591a73f070e6090b7c59dca928b84b1c261d92 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 26 Oct 2023 22:32:35 +0200
Subject: [PATCH] Fortran: diagnostics of MODULE PROCEDURE declaration
conflicts [PR104649]
gcc/fortran/ChangeLog:
PR fortran/104649
* decl.cc
Hi Paul,
this looks all good to me.
It is great that you added the handling of nested parentheses to the
resolution, as that appears to be needed also in other situations.
Thanks for the patch!
Harald
On 10/26/23 19:14, Paul Richard Thomas wrote:
Hi All,
The attached patch fixes the
Dear all,
Tobias argued in the PR that the testcase should actually be valid.
Therefore withdrawing the patch.
Sorry for expecting this to be a low-hanging fruit...
Harald
On 10/24/23 22:23, rep.dot@gmail.com wrote:
On 24 October 2023 21:25:01 CEST, Harald Anlauf wrote:
Dear all
2b5ed32cacfe84dc4df74b4dccf16ac830d9eb98 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 24 Oct 2023 21:18:02 +0200
Subject: [PATCH] Fortran/OpenMP: event handle in task detach cannot be a
coarray [PR104131]
gcc/fortran/ChangeLog:
PR fortran/104131
* openmp.cc (resolve_omp_clauses): Add check that event handle
Hi Tobias,
On 10/17/23 19:36, Tobias Burnus wrote:
Hi Harald,
On 17.10.23 19:02, Harald Anlauf wrote:
your latest patch - which you already pushed - removes the
intrinsic declaration of signal.
Only to 'signal' or also to 'sleep'? I have now added both in the attach
patch.
you are right
,
On 16.10.23 20:31, Harald Anlauf wrote:
Hi Tobias,
Am 16.10.23 um 19:11 schrieb Tobias Burnus:
OK for mainline?
I think the patch qualifies as obvious.
While at it, you might consider removing the comment a few lines below
the place you are changing,
@c TODO: What should the interface
ine?
As this fixes a regression since 8-release, I plan to backport
to all active branches.
Thanks,
Harald
From 43ec8b856a67a1b70744e5c0d50ea7fa2dd9a8ee Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 16 Oct 2023 21:02:20 +0200
Subject: [PATCH] Fortran: out of bounds access with nested implied-do
Hi Tobias,
Am 16.10.23 um 19:11 schrieb Tobias Burnus:
Yesterday, someone was confused because the signal handler did not work.
It turned out that the created Fortran procedure used as handler used
pass by reference - and 'signal' passed the it by value.
This patch adds the 'passed by value'
Dear All,
sorry for attaching the wrong patch - this time it is the correct one!
Harald
On 10/11/23 21:39, Harald Anlauf wrote:
Dear All,
the attached trivial patch fixes (= catches) a forgotten corner-case
in the detection of a name conflict between an internal procedure and
a local
on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 75dc455f21cea07e64b422c9994ab8879df388de Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 6 Oct 2023 22:21:56 +0200
Subject: [PATCH] fortran: fix handling of options -ffpe-trap and -ffpe-summary
[PR110957]
gcc/fortran/ChangeLog
Hi Paul,
the patch is fine, but I forgot the mention that the testcase needs fixing:
Instead of
! {dg-do compile }
you'll likely want
! { dg-do run }
(Note the space before the dg-command.)
Cheers,
Harald
On 10/11/23 21:06, Harald Anlauf wrote:
Hi Paul,
On 10/11/23 10:48, Paul Richard
Hi Paul,
On 10/11/23 10:48, Paul Richard Thomas wrote:
Hi All,
The title line of the PR should have been changed a long time since. As
noted in comment 5, the original problem was fixed in 10.5.
This patch fixes the problem described in comments 4 and 6, where the
hidden string length
missing something?
Any further opinions or insights?
Thanks,
Harald
From 75dc455f21cea07e64b422c9994ab8879df388de Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 6 Oct 2023 22:21:56 +0200
Subject: [PATCH] fortran: fix handling of options -ffpe-trap and -ffpe-summary
[PR110957]
gcc
.
Thanks,
Harald
From 0027c58c172889bdb5c09ecea0faf3c48624dc21 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 22 Sep 2023 21:06:00 +0200
Subject: [PATCH] fortran: error recovery on duplicate declaration of class
variable [PR95710]
gcc/fortran/ChangeLog:
PR fortran/95710
* class.cc
Hi Paul,
On 9/20/23 09:03, Paul Richard Thomas wrote:
Hi All,
This is a straightforward patch that is adequately explained by the ChangeLog.
Regtests fine - OK for trunk?
this looks good to me. OK for trunk.
As it is an almost obvious fix for sort of wrong code, I'd consider
it
9d8133 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 18 Sep 2023 22:11:40 +0200
Subject: [PATCH] fortran: fix checking of CHARACTER lengths in array
constructors [PR70231]
gcc/fortran/ChangeLog:
PR fortran/70231
* trans-array.cc (trans_array_constructor): In absence of a typespec,
over from playing, since I thought
the outlined function could be used more than once.
I've removed those lines before pushing.
Thanks for the review!
Harald
Apart from that, it looks good to me. OK for mainline.
Thanks for the patch.
Paul
On Thu, 14 Sept 2023 at 21:22, Harald Anlauf via For
more similar cases.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From bb2a765f56b440c8d086329f55c8ff0eaee2b97d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 14 Sep 2023 22:08:26 +0200
Subject: [PATCH] Fortran: improve bounds-checking for array sections [PR30802
Hi Mikael,
On 9/11/23 14:38, Mikael Morin via Gcc-patches wrote:
Hello,
this fixes a memory management issue in the fortran frontend.
I have included the (reduced) testcase from the PR, even if it wasn't failing
here on x86_64 with the test harness.
Tested on x86_64-pc-linux-gnu and manually
Am 08.09.23 um 12:04 schrieb Mikael Morin via Gcc-patches:
Hello,
this avoids some redundant work in the symbol deletion code, which is
used a lot by the parser to cancel statements that fail to match in the
end.
I haven't tried to measure the performance effect, if any, on a pathological
Hi Mikael,
On 9/1/23 10:41, Mikael Morin via Gcc-patches wrote:
Le 31/08/2023 à 22:42, Harald Anlauf via Fortran a écrit :
Dear all,
gfortran's array bounds-checking code does a mostly reasonable
job for array sections in expressions and assignments, but
forgot the case that (rank-1
. OK for mainline?
Thanks,
Harald
From 944a35909e8eeb79c92e398ae3f27e94708584e6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 31 Aug 2023 22:19:58 +0200
Subject: [PATCH] Fortran: runtime bounds-checking in presence of array
constructors [PR31059]
gcc/fortran/ChangeLog:
PR fortran
Hi Mikael,
On 8/27/23 21:22, Mikael Morin via Gcc-patches wrote:
Hello,
this fixes an old error-recovery bug.
Tested on x86_64-pc-linux-gnu.
OK for master?
I have only a minor comment:
+/* Free the leading members of the gfc_interface linked list given in INTR
+ up to the END element
here). We now get a warning with -std=gnu, and an
error with -std=f.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
(The PR is over 15 years old, so no backport intended... ;-)
Thanks,
Harald
From 420804e7399dbc307a80f084cfb840444b8ebfe7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
From 829c0c06fe7ba2cf3e83508b95999b884b21236d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 23 Aug 2023 21:08:01 +0200
Subject: [PATCH] Fortran: improve diagnostic message for COMMON with automatic
object [PR32986]
gcc/fortran/ChangeLog:
PR fortran/32986
* resolve.cc
-hanging fruits.
There are also far more than 100 TODOs in gcc/fortran/*.cc ...
And with the usual PRs, there's enough work left for all kinds
of contributions.
Cheers,
Harald
Paul
On Mon, 21 Aug 2023 at 20:48, Harald Anlauf via Fortran
wrote:
Dear all,
the attached patch implements vector
96cc0333cdaa8459ef516ae8e74158cdb6302853 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 21 Aug 2023 21:23:57 +0200
Subject: [PATCH] Fortran: implement vector sections in DATA statements
[PR49588]
gcc/fortran/ChangeLog:
PR fortran/49588
* data.cc (gfc_advance_section): Derive next index
).
The patch was OK'ed in the PR by Mikael.
Pushed as r14-3254-g9ade70bb86c874 after partial regtesting on
x86_64-pc-linux-gnu.
Thanks,
Harald
From 9ade70bb86c8744f4416a48bb69cf4705f00905a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 16 Aug 2023 22:00:49 +0200
Subject: [PATCH
Hi Martin,
Am 14.08.23 um 19:39 schrieb Martin Jambor:
Hello,
this patch addresses an issue uncovered by the undefined behavior
sanitizer. In function resolve_structure_cons in resolve.cc there is
a test starting with:
if (cons->expr->ts.type == BT_CHARACTER && comp->ts.u.cl
Hi Mikael,
Am 09.08.23 um 22:21 schrieb Mikael Morin via Gcc-patches:
Hello,
I propose with this patchset a fix for the test value_9.f90 which has been
failing on 32 bits powerpc since it was added a few weeks back (see PR110360
and PR110419).
The problem is an argument type mismatch between
way the procedure decl is generated.
The attached patch fixes the caller and clarifies the behavior
in the documentation.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 199e09c9862f5afe7e583839bc1b108c741a7efb Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 27 Jul
I am going to get the brown bag for today... This is now the right
corrected patch.
Sorry for all the noise!
Harald
Am 26.07.23 um 21:17 schrieb Harald Anlauf via Gcc-patches:
Dear all,
the original submission missed the adjustments of the expected
patterns of 2 tests. This is corrected
Dear all,
the original submission missed the adjustments of the expected
patterns of 2 tests. This is corrected in the new attachments.
Am 26.07.23 um 21:10 schrieb Harald Anlauf via Gcc-patches:
Dear all,
the attached patch fixes an ICE-on-invalid after use of strings of
non-constant length
Dear all,
the attached patch fixes an ICE-on-invalid after use of strings of
non-constant length in DATA statements.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b5b13db48c169ef18a8b75739bd4f22f9fd5654e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 26 Jul
this at least to 13-branch, unless there
are major concerns.
Thanks,
Harald
From 88d2694eb1278b0ad0d542565e0542c39fe6b466 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 16 Jul 2023 22:17:27 +0200
Subject: [PATCH] Fortran: intrinsics and deferred-length character arguments
[PR95947,PR110658]
gcc
Hi Mikael,
Am 11.07.23 um 12:32 schrieb Mikael Morin via Gcc-patches:
Hello,
this is a followup to Harald's recent work [1] on the evaluation order
of arguments, when one of them is passed to an intent(out) allocatable
dummy and is deallocated before the call.
This extends Harald's fix to
Hi Andre,
I forgot to answer your other question:
Am 11.07.23 um 18:23 schrieb Andre Vehreschild via Gcc-patches:
I tried to use a pdt within a derived type as a component. Is that not allowed
by the standard? I know, I could hunt in the standard for it, but when someone
knows out of his head,
ut.
Regtests ok on x86_64-linux-gnu/F37.
Regards,
Andre
On Mon, 10 Jul 2023 20:55:29 +0200
Harald Anlauf wrote:
Hi Andre,
thanks for looking into this!
While it fixes the original PR, here is a minor extension of the
testcase that ICEs here with your patch:
program pr102003
type
rald
From 3b2c523ae31b68fc3b8363b458a55eec53a44365 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 11 Jul 2023 21:21:25 +0200
Subject: [PATCH] Fortran: formal symbol attributes for intrinsic procedures
[PR110288]
gcc/fortran/ChangeLog:
PR fortran/110288
* symbol.cc (gfc_copy_formal_args_i
Hi Andre,
thanks for looking into this!
While it fixes the original PR, here is a minor extension of the
testcase that ICEs here with your patch:
program pr102003
type pdt(n)
integer, len :: n = 8
character(len=n) :: c
end type pdt
type(pdt(42)) :: p
integer, parameter ::
Hi Paul,
thanks for taking this.
I have just a minor comment regards coding style:
+ if (tmp
+ && tmp->attr.generic
+ && (tmp = gfc_find_dt_in_generic (tmp)))
+ {
+ if (tmp->attr.flavor == FL_DERIVED)
Hi Mikael,
Am 08.07.23 um 14:07 schrieb Mikael Morin:
here is what I'm finally coming to. This patch fixes my example, but is
otherwise untested.
The patch has grown enough that I'm tempted to fix my example
separately, in its own commit.
alright. I've interpreted this as a green light for
.
Thanks,
Harald
From b6c4f70d2dac4863335874f0bd3486ea7db348d7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 7 Jul 2023 20:25:06 +0200
Subject: [PATCH] Fortran: simplification of FINDLOC for constant complex
arguments [PR110585]
gcc/fortran/ChangeLog:
PR fortran/110585
* arith.cc
Hi Mikael,
Am 07.07.23 um 14:21 schrieb Mikael Morin:
I'm attaching what I have (lightly) tested so far, which doesn't work.
It seems gfc_conv_class_to_class reevaluates part of the original
expression, which is not correct after deallocation.
this looks much more elegant than my attempt that
). I am at a loss now.
I am attaching the latest version of my patch to give you or
Paul or others the opportunity to see what is wrong or add the
missing pieces.
Thanks for your help so far.
Harald
From 989030fc04eacf97a034ab1f7ed85b932669f82d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date
eview", hoping that the experts (Paul, Mikael,
...) can tell if I am going down the wrong road.
I'll wrap up all pieces and resubmit when the dust settles.
We can then address the other findings later.
Harald
Am 04.07.23 um 15:35 schrieb Mikael Morin:
Le 03/07/2023 à 22:49, Harald Anla
Hi Mikael,
Am 03.07.23 um 13:46 schrieb Mikael Morin:
A few thing to double check below.
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 30946ba3f63..16e8f037cfc 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
(...)
@@ -6117,6 +6118,33 @@
is no temporary generated.
I haven't found the reason why and would like to defer this,
unless someone has a good suggestion.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 609ba636927811cddc74fb815cb18809c7d33565 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 2 Jul 2023 22:14
Hi Alex,
welcome to the gfortran community. It is great that you are trying
to get actively involved.
You already did quite a few things right: patches shall be sent to
the gcc-patches ML, but Fortran reviewers usually notice them only
where they are copied to the fortran ML.
There are some
8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 28 Jun 2023 22:16:18 +0200
Subject: [PATCH] Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument
[PR110360]
gcc/fortran/ChangeLog:
PR fortran/110360
* trans-expr.cc (gfc_conv_procedure_call): For non-constant
(alloc_scalar_allocatable_subcomponent): Obtain
size of intrinsic and character expressions.
(gfc_trans_subcomponent_assign): Expand assignment to class
components to include intrinsic and character expressions.
gcc/testsuite/
PR fortran/49213
* gfortran.dg/pr49213.f90 : New test
On Sat, 24 Jun 2023 at 20:50, Harald Anlauf
Hi Paul!
On 6/24/23 15:18, Paul Richard Thomas via Gcc-patches wrote:
I have included the adjustment to 'gfc_is_ptr_fcn' and eliminating the
extra blank line, introduced by my last patch. I played safe and went
exclusively for class functions with attr.class_pointer set on the
grounds that
where one has no direct access to, or is less
familiar with. Far better than a plain
FAIL: gfortran.dg/value_9.f90 -O1 execution test
* * *
Thanks,
Harald
From 3f97d10aa1ff5984d6fd657f246d3f251b254ff1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 24 Jun 2023 20:36:53 +0200
Subject
101 - 200 of 873 matches
Mail list logo