Hi Mikael,
On 5/24/24 20:17, Mikael Morin wrote:
Le 23/05/2024 à 21:15, Harald Anlauf a écrit :
Hi Mikael,
On 5/23/24 09:49, Mikael Morin wrote:
Le 13/05/2024 à 09:25, Mikael Morin a écrit :
Le 10/05/2024 à 21:56, Harald Anlauf a écrit :
Am 10.05.24 um 21:48 schrieb Harald Anlauf:
Hi
Hi Mikael,
On 5/23/24 09:49, Mikael Morin wrote:
Le 13/05/2024 à 09:25, Mikael Morin a écrit :
Le 10/05/2024 à 21:56, Harald Anlauf a écrit :
Am 10.05.24 um 21:48 schrieb Harald Anlauf:
Hi Mikael,
Am 10.05.24 um 11:45 schrieb Mikael Morin:
Le 09/05/2024 à 22:30, Harald Anlauf a écrit
Hi Paul,
Am 20.05.24 um 11:06 schrieb Paul Richard Thomas:
Hi All,
I don't think that this PR is really a regression although the fact that it
is marked as such brought it to my attention :-)
The fix turned out to be remarkably simple. It was found after going down a
silly number of rabbit
Am 13.05.24 um 22:27 schrieb Harald Anlauf:
Dear all,
the attached patch does two things:
- it fixes a bogus array bounds check when deep-copying a class component
of a derived type and the class component has rank > 1, the reason being
that the previous code compared the full s
Hi Paul!
Am 15.05.24 um 19:07 schrieb Paul Richard Thomas:
Hi All,
I have been around several circuits with a patch for this regression. I
posted one in Bugzilla but rejected it because it was not direct enough.
This one, however, is more to my liking and fixes another bug lurking in
the
ter a decent delay.
Thanks,
Harald
From e187285dfd83da2f69cfd50854c701744dc8acc5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 13 May 2024 22:06:33 +0200
Subject: [PATCH] Fortran: fix bounds check for assignment, class component
[PR86100]
gcc/fortran/ChangeLog:
PR fortran/86100
* tr
Hi Paul,
this looks all good now, and is OK for mainline as well as backporting!
***
While playing with the testcase, I found 3 remaining smaller issues that
are pre-existing, so they should not delay your present work. To make
it clear: these are not regressions.
When "maliciously"
13b6ac4ebd04f0703d92828c9268b0b216890b0d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 12 May 2024 21:48:03 +0200
Subject: [PATCH] Fortran: fix frontend memleak
gcc/fortran/ChangeLog:
* primary.cc (gfc_match_varspec): Replace 'ref' argument to
is_inquiry_ref() by NULL when the result is not needed to avoid
f
trans-array.cc(gfc_alloc_allocatable_for_assignment) or in the array part
of intrinsic_transfer, untouched by either patch, and is present in 13- and
14-branches.
I am onto it.
Cheers
Paul
On Wed, 8 May 2024 at 22:06, Harald Anlauf wrote:
Hi Paul,
this looks mostly good, but
Am 10.05.24 um 21:48 schrieb Harald Anlauf:
Hi Mikael,
Am 10.05.24 um 11:45 schrieb Mikael Morin:
Le 09/05/2024 à 22:30, Harald Anlauf a écrit :
I'll stop here...
Thanks. Go figure, I have no problem reproducing today.
It's PR99798 (and there is even a patch for it).
this patch has rotten
Hi Mikael,
Am 10.05.24 um 11:45 schrieb Mikael Morin:
Le 09/05/2024 à 22:30, Harald Anlauf a écrit :
I'll stop here...
Thanks. Go figure, I have no problem reproducing today.
It's PR99798 (and there is even a patch for it).
this patch has rotten a bit: the type of gfc_reluease_symbol
has
... Will also backport to 14-branch after a decent delay.
Thanks,
Harald
From 8bb31eb3d7f8ea6d21066380c36abf53f7b64156 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 10 May 2024 21:18:03 +0200
Subject: [PATCH] Fortran: fix dependency checks for inquiry refs [PR115039]
gcc/fortran/ChangeLog:
PR
Hi Mikael,
Am 09.05.24 um 21:51 schrieb Mikael Morin:
Hello,
Le 06/05/2024 à 21:33, Harald Anlauf a écrit :
Dear all,
I've been contemplating whether to submit the attached patch.
It addresses an ICE-on-invalid as reported in the PR, and also
fixes an accepts-invalid (see testcase), plus
anches.
I am onto it.
Cheers
Paul
On Wed, 8 May 2024 at 22:06, Harald Anlauf wrote:
Hi Paul,
this looks mostly good, but the new testcase transfer_class_4.f90
does exhibit a problem with your patch. Run it with valgrind,
or with -fcheck=bounds, or with -fsanitize=address, or add the
follow
Hi Paul,
this looks mostly good, but the new testcase transfer_class_4.f90
does exhibit a problem with your patch. Run it with valgrind,
or with -fcheck=bounds, or with -fsanitize=address, or add the
following around the final transfer:
print *, storage_size (star_a), storage_size (chr_a),
rom c55cb36a6ad00996b5efb33c0c5357fc5fa9919c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 6 May 2024 20:57:29 +0200
Subject: [PATCH] Fortran: improve attribute conflict checking [PR93635]
gcc/fortran/ChangeLog:
PR fortran/93635
* symbol.cc (gfc_check_conflict): Move some attribute conflict
checks that dep
21e7aa5f3ea44ca2fef8deb8788edffc04901b5c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 29 Apr 2024 19:52:52 +0200
Subject: [PATCH] Fortran: fix issues with class(*) assignment [PR114827]
gcc/fortran/ChangeLog:
PR fortran/114827
* trans-array.cc (gfc_alloc_allocatable_for_assignment): Take
;-)
What do you think?
Thanks,
Harald
Thanks
Paul
PS The fall-out pr114874 is so peculiar that I am dropping everything to
find the source.
On Mon, 29 Apr 2024 at 19:39, Harald Anlauf wrote:
Dear all,
the attached patch fixes issues with assignments of unlimited polymorphic
to backport this to active branches where appropriate,
starting with 14 after it reopens after release. Is this OK?
Thanks,
Harald
From 3b73471b570898e5a5085422da48d5bf118edff1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 29 Apr 2024 19:52:52 +0200
Subject: [PATCH] Fortran: fix issues
Hi Paul,
On 4/24/24 18:26, Paul Richard Thomas wrote:
Hi there,
This regression turned out to be low hanging fruit, although it has taken
four years to reach it :-(
The ChangeLog says it all. OK for mainline and backporting after a suitable
delay?
yes to both.
Thanks for "picking" this
Hi Paul!
On 4/20/24 09:54, Paul Richard Thomas wrote:
subroutine sub
implicit none
real, external :: x
real :: y(10)
integer :: kk
print *, [real(x(k))]
! print *, [real(y(k))]
end
This is another problem, somewhere upstream from resolve.cc, which I have
just
Hi Paul,
the patch is OK, but I had to manually fix it. I wonder how you managed
to produce:
diff --git a/gcc/testsuite/gfortran.dg/pr93484.f90
b/gcc/testsuite/gfortran.dg/pr93484.f90
new file mode 100644
index 000..4dcad47e8da
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103471.f90
b9ece695a178319e35cd9f36cc731855302dd57f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 13 Apr 2024 19:09:24 +0200
Subject: [PATCH] Fortran: ALLOCATE of fixed-length CHARACTER with SOURCE/MOLD
[PR113793]
F2008 requires for ALLOCATE with SOURCE= or MOLD= specifier that the kind
type parameters of allocate-object and source
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
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: [PATCH] Fortran: fix argument
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: [PATCH
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
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
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
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 &&
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
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
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.
.
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 MOLD
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
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'
- when z
port 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
* fron
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
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
to an 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,
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
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 logic so
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
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
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/30802
* trans-array.cc (trans_array_bound_check): Find name of component
to use
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_LEN + 1]
This i
: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
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 message[IOMSG_LEN
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);
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 enc
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 with
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 NULL
s 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 differently from your site.
I see it inline instead of a
,
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
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.
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 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 your
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!
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 code
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
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
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
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
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
-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 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
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) = 'bcdefghijk
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
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
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 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
: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
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
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
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 i did
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 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
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
there 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 bounds
for 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
is 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
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 elemental
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
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 21:23
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
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
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 of optional
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
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
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
1 - 100 of 862 matches
Mail list logo
