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 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
Dear all,
finally here comes the second part of runtime checks for the bit
manipulation intrinsics, this time MVBITS. This turned out to be
more elaborate than the treatment of simple function calls.
I chose the path to inline expand MVBITS, which enables additional
optimization opportunities in
Dear all,
my fix for PR fortran/96711 adds a testcase that failed on powerpc64-*-*
as well as sparc*-sun-solaris2.11. This is a consequence of the, say,
mess, on x86, where we have real kinds 4,8,10,16, with kind=10 being long
double and kind=16 being represented as float128, while on sparc real(
Dear Tobias,
I can see that you want a proper fix.
However, after having looked at all these comments about the powerpc
situation, I do not really think I'd want to ever touch that stuff.
It's clearly beyond my capabilities and ressources.
I do feel responsible for the regression introduced by m
As stated in the PR, the Fortran 2018 standard removed the restriction
prohibiting ELEMENTAL RECURSIVE procedures. Adjust the relevant check.
Regtested on x86_64-pc-linux-gnu.
OK for master?
Thanks,
Harald
PR fortran/97036 - [F2018] Allow ELEMENTAL RECURSIVE procedure prefix
gcc/fortran/Chan
*ping*
> Gesendet: Sonntag, 13. September 2020 um 23:24 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Cc: "Paul Richard Thomas"
> Betreff: [PATCH] PR fortran/90903 [part2] Add runtime checking for the MVBITS
> intrins
The generation of the library call for the MINLOC/MAXLOC intrinsic
mishandled the optional KIND argument and resulted in a bad
argument list passed to the library function. The fix is obvious.
Regtested on x86_64-pc-linux-gnu.
OK for master? As it technically wrong code, OK for backports?
Than
Slightly rewritten version of the patch, with the removal of the KIND
argument from the argument list factored out:
> The generation of the library call for the MINLOC/MAXLOC intrinsic
> mishandled the optional KIND argument and resulted in a bad
> argument list passed to the library function. Th
Hi FX,
> While this is fresh in your memory, could I suggest you have a look at this
> FINDLOC issue, which seems possibly related:
> https://gcc.gnu.org/pipermail/fortran/2020-September/055016.html
> and further messages from Thomas Koenig?
I briefly checked this, but the issue with FINDLOC see
Dear all,
the present PR turned out to be fixable rather easily, once Paul had the
idea to add another attempt of simplification of elemental intrinsics
for array-valued arguments. There was some fallout which required only
small adjustments, see commit message below.
Regtested cleanly on x86_64
PR libfortran/97063 - Wrong result for vector (step size is negative) * matrix
Dear all,
when matrix-multiplying rank-1 times rank-2 arrays, a wrong result was
produced when a negative stride was used for the rank-1 array. In that
case special code for rank-2 times rank-2 was erroneously executed
e
provided.
OK for trunk?
Thanks,
Harald
2019-11-11 Harald Anlauf
PR fortran/81651
* module.c (gzopen_included_file, gzopen_included_file_1)
(gzopen_intrinsic_module, bad_module, gfc_use_module): Use fully
qualified module path for error reporting.
In
On 11/11/19 23:37, Janne Blomqvist wrote:
> On Mon, Nov 11, 2019 at 11:54 PM Harald Anlauf wrote:
>>
>> Dear all,
>>
>> the attached patch prints the fully qualified path if an error occurs
>> during module read. E.g., instead of a less helpful error message,
&
Dear all,
here is a first version to check the status of ALLOCATABLE and POINTER
arguments to the SIZE intrinsic at runtime.
What it does not yet cover is situations like
complex, allocatable :: z(:)
print *, size (z% re)
Feedback, such as comments for improvement, are welcome.
As is, the
Hi Thomas,
thanks for the comments.
> It feels a bit strange to have a check for an allocatable
> behind -fcheck=pointer, but I'm not sure that introducing
> a special check option would really be worth it.
Yes, I thought about that. There's already a discrepancy between
the GFC_RTCHECK_* in li
ng PR91641.
Regtested on x86_64-pc-linux-gnu.
OK for trunk and 9 ?
Thanks,
Harald
2019-12-10 Harald Anlauf
PR fortran/92898
* check.c (gfc_check_is_contiguous): Adjust check to handle NULL()
argument without an actual argument.
2019-12-10 Harald Anlauf
Hi Thomas,
> Gesendet: Dienstag, 10. Dezember 2019 um 23:34 Uhr
> Von: "Thomas Koenig"
> An: "Harald Anlauf" , gfortran ,
> gcc-patches
> Betreff: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in
> gfc_check_is_contiguous, at fortran/check.c:7
Hi Tobias,
> Gesendet: Donnerstag, 12. Dezember 2019 um 09:01 Uhr
> Von: "Tobias Burnus"
> An: "Harald Anlauf" , "Thomas Koenig"
> Cc: gfortran , gcc-patches
> Betreff: Re: Aw: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in
> gfc_che
t;pointer target shall not be NULL" }
+ z(2:1) => null() ! { dg-error "pointer target shall not be NULL" }
+end
2019-12-18 Harald Anlauf
PR fortran/92898
* trans-expr.c (gfc_trans_pointer_assignment): Reject bounds
remapping if pointer target is NULL
r error message, we'd need to know that we come here from
a NULLIFY statement. Can you file a PR?
Thanks,
Harald
> On 12/18/19 5:07 PM, Harald Anlauf wrote:
>> The patch is self-explaining and practically obvious: pointer bounds
>> remapping to NULL is not allowed, thus we shal
NULLIFY vs. pointer assignment (PR70853)
+program p
+ integer, pointer :: x(:)
+ type t
+ integer, pointer :: y(:)
+ end type t
+ type(t) :: z
+ nullify (x(1:2)) ! { dg-error "does not allow bounds remapping" }
+ nullify (z%y(:)) ! { dg-error "does not allow bounds remap
> Gesendet: Samstag, 21. Dezember 2019 um 17:16 Uhr
> Von: "Thomas Koenig"
> An: "Harald Anlauf" , fortran ,
> gcc-patches
> Betreff: Re: [Patch] PR92990 - fix error message for invalid argument of
> NULLIFY
>
> Am 20.12.19 um 22:33 schrieb Harald An
by Thomas König.
Thanks,
Harald
2019-12-21 Harald Anlauf
PR fortran/91661
* gfortran.dg/pr91661.f90: New test.
Index: gcc/testsuite/gfortran.dg/pr91661.f90
===
--- gcc/testsuite/gfortran.dg/pr91661.f90 (nicht ex
ase?
With these points addressed, your patch is OK from my side.
Thanks for the patch and your endurance!
Harald
Cheers
Paul
On Mon, 8 Jan 2024 at 21:53, Harald Anlauf wrote:
Hi Paul,
your patch looks already very impressive!
Regarding the patch as is, I am still trying to grok it, even wi
. OK for mainline?
Other comments?
Thanks,
Harald
From d9b87bea6af77fbc794e1f21cfecb0468c68cb72 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 5 Mar 2024 21:54:26 +0100
Subject: [PATCH] Fortran: error recovery while simplifying expressions
[PR103707,PR106987]
When an exception is e
Hi Jerry,
I think there is the risk of buffer overrun in the following places:
+ char message[IOMSG_LEN];
+ child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg)
+ 1;
free_line (dtp);
snprintf (message, child_iomsg_len, child_iomsg);
Hi Jerry,
on further thought, do we sanitize 'child_iomsg'?
We pass it to snprintf as format.
Wouldn't a strncpy be sufficient?
Harald
On 3/5/24 22:37, Harald Anlauf wrote:
Hi Jerry,
I think there is the risk of buffer overrun in the following places:
+ char me
:51, Paul Richard Thomas wrote:
Hi Harald,
This all looks good to me. OK for mainline and, according to intestinal
fortitude on your part, earlier branches.
Thanks
Paul
On Tue, 5 Mar 2024 at 21:24, Harald Anlauf wrote:
Dear all,
error recovery on arithmetic errors during simplification has
6/24 05:06, Jerry D wrote:
On 3/5/24 1:51 PM, Harald Anlauf wrote:
Hi Jerry,
on further thought, do we sanitize 'child_iomsg'?
We pass it to snprintf as format.
Wouldn't a strncpy be sufficient?
Harald
Just to be safe I will bump char message[IOMSG_LEN] to char
message[IOMSG_L
of dimension 1 below lower bound of 1
From cdf3b197beed0ce1649661b2132643b54cbade8d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 10 Mar 2024 22:14:30 +0100
Subject: [PATCH] Fortran: use name of array component in runtime error message
[PR30802]
gcc/fortran/ChangeLog:
PR fortran
a9be17cf987b796c49684cde2f20dac3839c736c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 11 Mar 2024 22:05:51 +0100
Subject: [PATCH] Fortran: handle procedure pointer component in DT array
[PR110826]
gcc/fortran/ChangeLog:
PR fortran/110826
* array.cc (gfc_array_dimen_size): When
Hi Paul,
On 3/12/24 15:54, Paul Richard Thomas wrote:
Hi All,
This is the last posting of this patch before I push it. Harald is OK with
it on the grounds that the inferred_type flag guards the whole lot,
except for the chunks in trans-stmt.cc.
In spite of Harald's off-list admonition not to t
From 8f535b19bd0cb6a7c99ac9ba4c07778f86698a1c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 12 Mar 2024 22:58:39 +0100
Subject: [PATCH] Fortran: fix IS_CONTIGUOUS for polymorphic dummy arguments
[PR114001]
gcc/fortran/ChangeLog:
PR fortran/114001
* expr.cc (gfc_is_simply_contiguous): Adjust log
Hi Mikael,
On 3/15/24 17:31, Mikael Morin wrote:
Le 10/03/2024 à 22:31, Harald Anlauf a écrit :
Dear all,
after playing for some time with NAG and Intel, and an off-list
discussion with Jerry, I am getting more and more convinced that
simpler runtime error messages (also simpler to parse by a
assumed-rank dummy, see
PR114355. The corresponding test is commented in the testcase.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
On 2/6/22 22:04, Harald Anlauf wrote:
Hi Mikael,
Am 04.02.22 um 11:45 schrieb Mikael Morin:
Hello,
Le 29/01/2022 à 22:41, Harald Anlauf via
Hi Mikael,
thanks for the patch!
Regarding the first part of the patch, I think that fixing bad testcases
can be done at any time. Retaining identified, broken testcases means
that one may hit bogus regressions, hindering progress.
The second part of the patch looks at first glance fine to me.
Hi Mikael,
On 3/17/24 22:04, Mikael Morin wrote:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 3673fa40720..a7717a8107e 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -7526,6 +7526,17 @@ gfc_get_dataptr_offset (stmtblock_t *block,
tree pa
backport to open
branches.
Thanks,
Harald
From 3be2b8f475f22c531d6cef1b041c0573b3ea5133 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 18 Mar 2024 19:36:59 +0100
Subject: [PATCH] Fortran: error recovery in frontend optimization [PR103715]
gcc/fortran/ChangeLog:
PR fortran/103715
*
Hi Mikael, all,
here's now the third version of the patch that implements the following
scheme:
On 3/15/24 20:29, Mikael Morin wrote:
Le 15/03/2024 à 18:26, Harald Anlauf a écrit :
OK, that sounds interesting. To clarify the options:
- for ordinary array x it would stay 'x'
Hi Mikael,
this looks all good to me. I wouldn't mind the minor side-effects of
better error recovery, as you are (successfully) trying hard to keep
the namespaces sane. So OK for mainline.
Thanks for the patch!
Harald
On 3/21/24 17:27, Mikael Morin wrote:
Hello,
here is a fix for an ICE
d NAG.
Regtested on x86_64-pc-linux-gnu.
I intend to commit soon unless there are objections.
Thanks,
Harald
From e92244c5539a537cff338b781d15acd58d4c86f1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 22 Mar 2024 18:17:15 +0100
Subject: [PATCH] Fortran: no size check passing NULL() without
Hi Jerry,
Am 26.03.24 um 04:18 schrieb Jerry D:
Hi all,
There has been a bit of discussio on which way to go on this.
I took a look today and this trivial patch gives the behavior concluded
on Fortran Discourse. See the bugzilla for all the relevant information.
Regresion tested on x86-64.
like to backport.
Thanks,
Harald
P.S.: while trying to extend coverage of conforming code, I had
much fun also with other compilers (e.g. NAG panicking...)
From d5fda38243a22e1aef4367653d92521e53f2000d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 27 Mar 2024 21:18:04 +0100
Subject
is beyond the current stage.
Regtested on x86_64-pc-linux-gnu.
I intend to commit soon unless there are objections.
Thanks,
Harald
From b3970a30679959eed159dffa816899e4430e9da5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 28 Mar 2024 22:34:40 +0100
Subject: [PATCH] Fortran: fix NULL
Hi Paul,
Am 28.03.24 um 16:39 schrieb Paul Richard Thomas:
Hi All,
The attached patch has two elements:
(i) A fix for gimplifier ICEs with derived type having no components. The
reporter himself suggested (thanks Kirill!):
- if (derived && derived->attr.zero_comp)
+ if (derived && (derived-
Hi Paul,
I had only a quick glance at your patch. I guess you unintentionally
forgot to remove those parts that you already committed for PR110987,
along with the finalize-testcases.
I am still trying to find the precise paragraph in the standard
you refer to regarding INTENT(OUT) and default i
Hi Paul!
Am 31.03.24 um 14:08 schrieb Paul Richard Thomas:
Hi Harald,
I had only a quick glance at your patch. I guess you unintentionally
forgot to remove those parts that you already committed for PR110987,
along with the finalize-testcases.
Guilty as charged. I guess I got out of the w
Hi Paul,
On 3/31/24 15:01, Paul Richard Thomas wrote:
This regression has a relatively simple fix. The passing of a subroutine
procedure pointer component to a dummy variable was being missed
completely. The error has been added. Conversely, an error was generated
for a procedure pointer variabl
sed a check preventing an ICE-on-invalid
when a function returning a pointer was passed.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 6f412a6399a7e125db835584d3d2489a52150c27 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 8 Apr 2024 21:43:24 +0200
Subject: [
n extension of the corresponding testcase.
Otherwise, OK.
FX
Thanks for the review!
If there are no further comments, I will commit tomorrow.
Thanks,
Harald
From 5983a07f11c88d920241141732fa742735cdb8ea Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 9 Apr 2024 23:07:59 +0200
Subject
Hi Paul!
On 4/10/24 10:25, Paul Richard Thomas wrote:
Hi All,
This patch corrects incorrect results from assignment of unlimited
polymorphic function results both in assignment statements and allocation
with source.
The first chunk in trans-array.cc ensures that the array dtype is set to
the s
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
Hi Jerry,
On 2/22/24 20:11, Jerry D wrote:
Hi all,
The attached fix adds a check for an error condition from a UDDTIO
procedure in the case where there is no actual underlying error, but the
user defines an error by setting the iostat variable manually before
returning to the parent READ.
the
,
Harald
From 75724b6b42a1c46383d8e6deedbfb8d2ebd0fa12 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 27 Feb 2024 21:51:53 +0100
Subject: [PATCH] Fortran testsuite: fix invalid Fortran in testcase
gcc/testsuite/ChangeLog:
* gfortran.dg/pr101026.f: Let variables used in specification
WSL 2, with Ubuntu 20.04 distro.
Is this okay to push to the trunk?
Thanks,
Alexander Westbrooks
On Sun, Feb 11, 2024 at 2:11 PM Harald Anlauf wrote:
Hi Alex,
I've been unable to apply your patch to my local trunk, likely due to
whitespace issues my newsreader handles differ
From ce7199b16872b3014be68744329a8f19ddd64b05 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 29 Feb 2024 21:43:53 +0100
Subject: [PATCH] Fortran: improve checks of NULL without MOLD as actual
argument [PR104819]
gcc/fortran/ChangeLog:
PR fortran/104819
* check.cc (gfc_check_null): Handle nested
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
1 - 100 of 1028 matches
Mail list logo
