t.
Or am I 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
[PR11
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 componen
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 Ri
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
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
Hi Stanislav,
Am 15.10.23 um 15:18 schrieb Stanislav Maslovski:
Hi,
First of all, many thanks to everyone involved in developing and
maintaining gfortran!
I have been trying to use gfortran's function signal() to add a SIGINT
signal handler to my program. Gfortran's documentation for this func
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' t
his 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
,
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 o
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
pa
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 is
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,
the
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 origina
?
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,
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 ==
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 than
x-gnu. OK 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 for
* 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
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 of a
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 bec
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 b
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
+++ b/gcc/testsuite/gfortran.dg/bou
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, boots
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 fine
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":
Fortra
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
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 to
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)
Hi,
does anybody else have the same issue?
I usually build trunk with --disable-bootstrap, e.g. 14-trunk using
gcc-13, and rarely encounter problems. Some change between yesterday
and today (likely r14-5607-g2f8f7ee2db82a3, Initial support for AVX10.1)
leads to the following problem:
When build
As I could not find any way to proceed, I submitted my findings
as PR112643 and hope to get feedback.
Harald
> Gesendet: Montag, 20. November 2023 um 21:01 Uhr
> Von: "Harald Anlauf"
> An: "fortran"
> Betreff: Today's build of trunk with --disable-boots
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
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 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 Reid's
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
o 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: restriction
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
.
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
,
Harald
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_missi
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 of
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
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 the
?
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
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
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 9
ted 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
ases 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 PO
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
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 a
Dear all,
in Fortran 2018 a few intrinsics were extended and now support
additional optional arguments. See PR 85836 for the meta-bug,
and in particular:
96583 - get_environment_variable
96584 - get_command
96585 - get_command_argument
with an optional ERRMSG.
How are we going to deal with thi
Hi FX,
> Hi Harald,
>
> > If we do not want to break the existing ABI, so that we can
> > link gfortran-13 and gfortran-14+(?) compiled code, we need
> > to keep _gfortran_get_command_i4 & friends, and introduce
> > new library functions that are able to handle the new
> > requirements.
>
> I ha
Hi Steve,
> At one time, we kept track of things that would break
> libgfortran's ABI on the wiki. You can find the list
> at https://gcc.gnu.org/wiki/LibgfortranAbiCleanup.
> This could be old and moldy as I haven't checked in
> on ABI changes in a long time.
this looks indeed old and moldy...
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 Mattermost
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
+
+p
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 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 a/htdocs/gcc-14/change
, 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
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
dress 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
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
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
().
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 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 i
o
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: Har
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
7 00:00:00 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
From 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
Am 20.01.24 um 20:08 schrieb Jerry D:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance to review it?
Thanks,
Alexander Westbrooks
Inserting myself in here just a li
Am 20.01.24 um 21:37 schrieb Jerry D:
On 1/20/24 12:08 PM, Harald Anlauf wrote:
Am 20.01.24 um 20:08 schrieb Jerry D:
On 1/20/24 10:46 AM, Alexander Westbrooks wrote:
Hello and Happy New Year!
I wanted to follow up on this patch I made to address PR82943 for
GFortran. Has anyone had a chance
mented out with a pointer to the standard
(thanks, Mikael!).
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From f6a65138391c902d2782973665059d7d059a50d1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 20 Jan 2024 22:18:02 +0100
Subject: [PATCH] Fortran: passing o
Hi Mikael!
Am 21.01.24 um 11:50 schrieb Mikael Morin:
Hello,
Le 20/01/2024 à 22:58, Harald Anlauf a écrit :
Dear all,
here's the first part of an attempt to fix issues with optional
dummy arguments as actual arguments to optional dummies. This patch
rectifies the case of scalar dummies
ou just add a line saying:
Signed-off-by: Random J Developer
using your real name (sorry, no pseudonyms or anonymous contributions.) ..."
I think this would be sufficient.
On Sat, Jan 20, 2024 at 3:40 PM Harald Anlauf wrote:
Am 20.01.24 um 21:37 schrieb Jerry D:
On 1/20/24 12:0
tment of VALUE, hoping that the
monster loop in gfc_conv_procedure_call will become slightly
easier to overlook.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From bd97af4225bf596260610ea37241ee503842435e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 23 Jan 2024
Am 24.01.24 um 10:13 schrieb Janne Blomqvist:
On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote:
Now, if
the OS adds cospi() to libm and it's in libm's symbol map, then the
cospi() used by gfortran depends on the search order of the loaded
libraries.
We only include the fallback math function
Hi Mikael,
Am 24.01.24 um 19:46 schrieb Mikael Morin:
Le 23/01/2024 à 21:36, Harald Anlauf a écrit :
Dear all,
here's the second part of a series for the treatment of missing
optional arguments passed to optional dummies, now fixing the
case that the latter procedures are elem
compile-only, as it is only important to check the
strings used in the error messages.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 43c0185764ec878576ef2255d9df24fbb1961af4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 24 Jan 2024 22:28:31 +0100
Subject: [PATCH
mainline?
Thanks,
Harald
From a0509b34d52b32a2e3511daefcb7dc308c755931 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 25 Jan 2024 22:19:10 +0100
Subject: [PATCH] Fortran: NULL actual to optional dummy with VALUE attribute
[PR113377]
gcc/fortran/ChangeLog:
PR fortran/113377
* trans
e are comments.
Thanks,
Harald
From ce61de1b8a1bb3a22118e900376f380768f2ba59 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 27 Jan 2024 17:41:43 +0100
Subject: [PATCH] Fortran: fix bounds-checking errors for CLASS array dummies
[PR104908]
Commit r11-1235 addressed issues with boun
Hi Mikael,
Am 28.01.24 um 12:39 schrieb Mikael Morin:
Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
Dear all,
this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds
Am 28.01.24 um 22:43 schrieb Steve Kargl:
On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote:
Am 28.01.24 um 12:39 schrieb Mikael Morin:
Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
Dear all,
this patch is actually only a followup fix to generate the proper name
of an array
Am 29.01.24 um 18:25 schrieb Harald Anlauf:
I was talking about the generated format strings of runtime error
messages.
program p
implicit none
type t
real :: zzz(10) = 42
end type t
class(t), allocatable :: xx(:)
integer :: j
j = 0
allocate (t :: xx(1))
print
Am 29.01.24 um 21:45 schrieb Bernhard Reutner-Fischer:
On Wed, 17 Nov 2021 21:32:14 +0100
Harald Anlauf wrote:
Do you have testcases/reproducers demonstrating that the patch actually
fixes the issues you're describing?
I believe that marking artificial symbols as such is obvious and
Hi Jerry,
Am 30.01.24 um 19:15 schrieb Jerry D:
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float string.
while your patch addresses ENw.dE0 an
Jerry, Steve,
Am 03.02.24 um 04:24 schrieb Steve Kargl:
Jerry,
The patch looks good to me, but please give Harald a chance
to comment.
I just tested it a little, and it looked good.
We even get a runtime error on E0.0 now as required. :-)
Thanks for the patch!
Harald
:00:00 2001
From: Harald Anlauf
Date: Thu, 8 Feb 2024 21:51:38 +0100
Subject: [PATCH] Fortran: error recovery on arithmetic overflow on unary
operations [PR113799]
PR fortran/113799
gcc/fortran/ChangeLog:
* arith.cc (reduce_unary): Remember any overflow encountered during
reduction of unary
Hi Alex,
I've been unable to apply your patch to my local trunk, likely due to
whitespace issues my newsreader handles differently from your site.
I see it inline instead of attached.
A few general remarks:
Please follow the general recommendation regarding style if possible,
see https://www.gn
87d1b973a4d6a561dc3f3a0c4c10f76d155fa000 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 12 Feb 2024 21:39:09 +0100
Subject: [PATCH] Fortran: fix passing of optional dummies to bind(c)
procedures [PR113866]
PR fortran/113866
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): When
Hi Jerry.
Am 12.02.24 um 22:28 schrieb Jerry D:
The attached patch fixes this PR by properly adjusting some variables
When using stream io. See log below. New test case included.
Regression tested on x86_64.
OK for trunk and backport?
the patch looks good to me.
As it is simple and very loc
Hi Steve,
Am 13.02.24 um 18:21 schrieb Steve Kargl:
On Mon, Feb 12, 2024 at 09:57:08PM +0100, Harald Anlauf wrote:
Dear all,
the attached patch fixes a mis-handling of optional dummy arguments
passed to optional dummy arguments of procedures with the bind(c)
attribute. When those procedures
Am 13.02.24 um 19:13 schrieb Harald Anlauf:
indeed the new testcase just regressed due to commit
r14-8947-g6caec7d9ec37e6 ... :-(
Reduced testcase which fails on trunk:
program p
implicit none
integer, parameter :: n = 100, l = 10
character(l) :: a = 'a234567890', b(n) = &
Hi Peter,
thanks for your contribution to gfortran! You've found indeed
a solution for a potentially annoying bug.
Am 15.02.24 um 18:50 schrieb Peter Hill:
Dear all,
The attached patch fixes PR105658 by forcing an array temporary to be
created. This is required when passing an array component
-enabled.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 07fcdf7c9f9272d8e4752c23f04795d02d4ad440 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 16 Feb 2024 22:33:16 +0100
Subject: [PATCH] Fortran: deferred length of character variables shall not get
lost
Hi Jakub,
On 2/17/24 10:02, Jakub Jelinek wrote:
Hi!
The r14-870 changes broke xtb package tests (reduced testcase is the first
one below) and caused ICEs on a test derived from that (the second one).
[...]
thanks for your detailed analysis and for the patch, which puts
things in straight ord
Hi Peter,
On 2/19/24 16:19, Peter Hill wrote:
Hi Harald,
Thanks for your help, please see the updated and signed-off patch below.
great! This is fine, and I'll commit it tomorrow unless others
have further comments.
It also occurred to me that array temporaries aren't _required_ here
(for
On 2/19/24 16:19, Peter Hill wrote:
Hi Harald,
Thanks for your help, please see the updated and signed-off patch below.
Pushed: https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2
On 2/21/24 20:41, Jerry D wrote:
On 2/21/24 10:30 AM, Steve Kargl wrote:
I have attached a patch to PR114024, see
https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
The patch contains a new testcase and passes regression
testing on x86_64-*-freebsd. Could someone castr an eye
ov
On 2/21/24 22:00, Steve Kargl wrote:
Unfortunately, valgrind does not work on AMD FX-8350 cpu.
Do you mean valgrind does not work at all?
For gcc, you need to configure --enable-valgrind-annotations
to not get bogus warnings.
memleak vs ICE. I think I'll take one over the other.
Probably nee
Hi Steve!
On 2/22/24 01:52, Steve Kargl wrote:
On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
On 2/21/24 22:00, Steve Kargl wrote:
memleak vs ICE. I think I'll take one over the other.
Probably need to free
On 2/22/24 22:01, Steve Kargl wrote:
On Thu, Feb 22, 2024 at 09:22:37PM +0100, Harald Anlauf wrote:
On the positive side, it not only seems to fix the cases in question,
but also substring references etc., like the following:
If the above passes a regression test, then by all means we should
Hi Steve, all,
here's an updated patch with an enhanced testcase that also
checks MOLD= besides SOURCE=.
Regtested on x86_64-pc-linux-gnu. Is it OK for mainline?
Cheers,
Harald
On 2/22/24 22:32, Harald Anlauf wrote:
On 2/22/24 22:01, Steve Kargl wrote:
BTW, my patch and I suspect
after some delay?
Thanks,
Harald
From 7a16143448ee21b716b54a94f83f9ee477af1b63 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 25 Feb 2024 21:18:23 +0100
Subject: [PATCH] Fortran: do not evaluate polymorphic functions twice in
assignment [PR114012]
PR fortran/114012
gcc/fortran
1 - 100 of 781 matches
Mail list logo
