Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 22 Jun 2023 22:07:41 +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): Pass actual argument
to scalar
:
Committed as r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Thanks for the help and the review Harald. Thanks to Steve too for
picking up Neil Carlson's bugs.
Cheers
Paul
On Tue, 20 Jun 2023 at 22:57, Harald Anlauf wrote:
Hi Paul,
On 6/20/23 12:54, Paul Richard Thomas via Gcc-patches wrote
Hi Paul,
On 6/20/23 12:54, Paul Richard Thomas via Gcc-patches wrote:
Hi Harald,
Fixing the original testcase in this PR turned out to be slightly more
involved than I expected. However, it resulted in an open door to fix
some other PRs and the attached much larger patch.
This time, I did
Hi Paul,
On 6/17/23 11:14, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
The attached patch is amply described by the comments and the
changelog. It also includes the fix for the memory leak in decl.cc, as
promised some days ago.
OK for trunk?
I hate to say it, but you forgot to add
Hi Steve,
On 6/13/23 19:45, Steve Kargl via Gcc-patches wrote:
On Mon, Jun 12, 2023 at 11:12:45PM +0200, Harald Anlauf via Fortran wrote:
Dear all,
the attached - actually rather small - patch is the result of a
rather intensive session with Mikael in an attempt to fix the
situation that we
-branch in time for 13.2?
Thanks,
Harald
From 773b2aae412145d61638a0423c5891c4dfd0f945 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 12 Jun 2023 23:08:48 +0200
Subject: [PATCH] Fortran: fix passing of zero-sized array arguments to
procedures [PR86277]
gcc/fortran/ChangeLog:
PR fortran
Hi FX,
Am 06.06.23 um 21:29 schrieb FX Coudert via Gcc-patches:
Hi,
This is a repost of the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html
which never really got green light, but I stopped pushing because stage 1 was
closing and I was out of time.
I just
On 6/8/23 09:46, Mikael Morin wrote:
Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
Sure, but
Hi Paul!
On 6/7/23 18:10, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the
Hi FX,
On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
Hi,
I cannot see if there is proper support for kind=17 in your patch;
at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seriously
Hi FX,
On 6/6/23 15:19, FX via Gcc-patches wrote:
Hi,
This patch adds four IEEE functions from the Fortran 2018 standard:
IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, and IEEE_MAX_NUM_MAG.
Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 and 64-bit. OK to
commit?
FX
it would
On Fri, 2 Jun 2023 at 19:06, Harald Anlauf via Fortran
wrote:
Dear all,
I've committed that attached simple patch on behalf of Steve
after discussion in the PR and regtesting on x86_64-pc-linux-gnu.
It fixes a duplicate error message and an ICE.
Pushed as r14-1505
Hi Paul, all,
On 6/3/23 15:16, Paul Richard Thomas via Gcc-patches wrote:
Hi Thomas,
I want to get something approaching correct finalization to the
distros, which implies 12-branch at present. Hopefully I can do the
same with associate in a month or two's time.
IMHO it is not only distros,
Dear all,
I've committed that attached simple patch on behalf of Steve
after discussion in the PR and regtesting on x86_64-pc-linux-gnu.
It fixes a duplicate error message and an ICE.
Pushed as r14-1505-gfae09dfc0e6bf4cfe35d817558827aea78c6426f .
Thanks,
Harald
From
Hi Mikael,
Am 01.06.23 um 22:33 schrieb Mikael Morin:
Hello,
Le 01/06/2023 à 21:05, Harald Anlauf via Fortran a écrit :
Dear all,
we sometimes silently accept wrong declarations with unbalanced
parentheses, as the PR and testcases therein show.
It appears that the fix is obvious: use
have missed something not so
obvious.
The patch regtests cleanly on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From a30ff5af130c4d33c086fd136978d5f49cb8bde4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 1 Jun 2023 20:56:11 +0200
Subject: [PATCH] Fortran: force error on bad
for mainline?
Thanks,
Harald
From 738bdcce46bd760fcafd1eb56700c8824621266f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 24 May 2023 21:04:43 +0200
Subject: [PATCH] Fortran: reject bad DIM argument of SIZE intrinsic in
simplification [PR104350]
gcc/fortran/ChangeLog:
PR fortran/104350
From bfb708fdb6c313473a3054be710c630dcdebf69d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 21 May 2023 22:25:29 +0200
Subject: [PATCH] Fortran: checking and simplification of RESHAPE intrinsic
[PR103794]
gcc/fortran/ChangeLog:
PR fortran/103794
* check.cc (gfc_check_reshape): Expand
removes the comparison for size > 0 also has the bonus that
it fixes a minor memory leak for the size==0 case...
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 9d2995d2c1cf5708e3297fc7cffb5184d45a65cb Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 17 May 2023 20:39
and obvious, see attached patch.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 6406f19855a3b664597d75369f0935d3d31384dc Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 14 May 2023 21:53:51 +0200
Subject: [PATCH] Fortran: CLASS pointer function result in variable
On 5/9/23 20:29, Steve Kargl via Gcc-patches wrote:
On Tue, May 09, 2023 at 08:24:16PM +0200, Harald Anlauf wrote:
Hi Paul,
On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
this testcase checked
Hi Paul,
On 5/9/23 18:00, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
This problem caused the gimplifier failure because the reference chain
ending in an inquiry_len still retained a full array reference. This had
already been corrected for deferred character lengths but the fix extends
Hi Paul,
On 5/9/23 17:51, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
this testcase checked that finalizable derived types could not be specified
in a submodule. I have replaced the original test with a test of
Steve,
On 5/8/23 02:13, Steve Kargl via Gcc-patches wrote:
Harald,
Thanks for keeping us honest. I didn't check what other
separators might cause a problem.
After 2 decades of working on gfortran, I've come to conclusion
that -std=f2018 should be the default. When f2023 is ratified,
the
/right: tab 666 0
1-line: lf 666 0
2-line/left: lf 666 0
2-line/right: lf 666 0
1-line: ret 666 0
2-line/left: ret 666 0
2-line/right: ret 666 0
So ther
Hi Jerry, Steve,
I think I have to pour a little water into the wine.
The patch fixes the reported issue only for a comma after
the namelist name, but we still accept a few other illegal
characters, e.g. ';', because:
#define is_separator(c) (c == '/' || c == ',' || c == '\n' || c == ' ' \
Hi Mikael,
On 5/5/23 13:43, Mikael Morin wrote:
Hello,
Le 01/05/2023 à 18:29, Harald Anlauf via Fortran a écrit :
+/* Given two expressions, check that their rank is conformable, i.e.
either
+ both have the same rank or at least one is a scalar. */
+
+bool
+gfc_op_rank_conformable
is
sort of annoying. Would it be OK to backport to 13.2 after
some waiting?
Thanks,
Harald
From 50c8d3d4adeed1ecf44216075d1fb53a3ef0 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 1 May 2023 18:01:25 +0200
Subject: [PATCH] Fortran: overloading of intrinsic binary operators [PR109641
Hi Paul,
Am 22.04.23 um 10:32 schrieb Paul Richard Thomas via Gcc-patches:
Hi All,
As usual, I received a string of emails on retargeting for PRs for which I
was either responsible or was on the cc list. This time I decided to take a
look at them all, in order to reward the tireless efforts of
Hi Mikael,
Am 22.04.23 um 11:25 schrieb Mikael Morin:
Hello,
Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit :
Dear all,
Fortran 2018 added a clarification that the *result* of a function
whose result *variable* has the ALLOCATABLE attribute is a *value*
that itself does not have
).
The patch which implements a related check was co-authored with
Steve and regtested by him. Testcase verified against NAG.
OK for mainline (gcc-14)?
Thanks,
Harald & Steve
From 2cebc8f9e7b399b7747c9ad0392831de91851b5b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 20 Apr 2023 2
On 4/19/23 17:14, Bernhard Reutner-Fischer via Gcc-patches wrote:
On Wed, 19 Apr 2023 at 03:03, Jerry D via Fortran wrote:
On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch adjusts the scan-tree-dump patterns of the
reported testcases which likely were run
ran.dg/reshape_8.f90 I checked with a
failing gfortran-11 that the pattern is appropriate.
OK for mainline?
Thanks,
Harald
From ad7ea82929f65ef34a13dea5a0fe23d567f220e8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 18 Apr 2023 21:24:20 +0200
Subject: [PATCH] testsuite: fix scan-tree-du
Hi Steve,
On 4/14/23 21:33, Steve Kargl via Gcc-patches wrote:
On Fri, Apr 14, 2023 at 08:59:24PM +0200, Harald Anlauf via Fortran wrote:
the compile-time simplification of intrinsic SET_EXPONENT was
broken since the early days of gfortran for argument X < 1
(including negative X) and fo
Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 14 Apr 2023 20:45:19 +0200
Subject: [PATCH] Fortran: fix compile-time simplification of SET_EXPONENT
[PR109511]
gcc/fortran/ChangeLog:
PR fortran/109511
* simplify.cc (gfc_simplify_set_exponent): Fix implementation of
compile-time simplifi
e-time and runtime results and
is checked against Intel.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This is not a regression, but can lead to wrong code.
Would it be OK to backport to open branches?
Thanks,
Harald
From fa4cb42870df60debdbd51e2ddc6d6ab9e6a Mon Sep 17 00:00:00 2001
From:
at 20:26, Harald Anlauf wrote:
Hi Paul,
On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
I think that the changelog says it all. OK for mainline?
this looks almost fine, but still fails if one directly uses the
dummy argument as the ASSOCIATE target, as in:
pro
the commit message contains Unicode characters
that I got by using copy of the error message. I wonder
if "git gcc-verify" could have warned me ...)
Thanks,
Harald
From 43816633afd275a9057232a6ebfdc19e441f09ec Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 13 Apr 2023 22:42:23 +02
Hi Paul,
On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
I think that the changelog says it all. OK for mainline?
this looks almost fine, but still fails if one directly uses the
dummy argument as the ASSOCIATE target, as in:
program p
implicit none
character(4) ::
for this was straightforward.
I also fixed a potential buffer overflow for a generated
internal symbol.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 60e81b97cf3715347de30ed4fd579be54fdb1997 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 11 Apr 2023 21:44:20
Hi Jerry, all,
On 4/11/23 02:43, Jerry D via Gcc-patches wrote:
On 4/10/23 1:49 PM, Harald Anlauf via Fortran wrote:
Dear all,
when comparing formal and actual arguments of a procedure, there was no
check of rank for derived types from intrinsic module ISO_C_BINDING.
This could lead
.
The attached fix is simple and regtests cleanly on x86_64-pc-linux-gnu.
OK for mainline?
Thanks,
Harald
From d41aa0f60b53799a5d28743f168fbf312461f51f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 10 Apr 2023 22:39:52 +0200
Subject: [PATCH] Fortran: resolve correct generic with TYPE(C_PTR
build_zero_cst (TREE_TYPE (se.expr)));
+ gfc_add_block_to_block (pblock, );
+}
if (cl->backend_decl && VAR_P (cl->backend_decl))
gfc_add_modify (pblock, cl->backend_decl, se.expr);
Cheers
Paul
On Fri, 7 Apr 2023 at 20:28, Harald Anlauf wrote:
Hi Paul,
On 4/
that trim() was essential, so omitting it is likely not an option.
I think the best way is to proceed and to open a PR on the memory
leak rather than leaving pr92779 open. What do you think?
Cheers,
Harald
Thanks
Paul
On Fri, 7 Apr 2023 at 10:41, Harald Anlauf wrote:
Hi Paul,
I don't see
Hi Paul,
I don't see the new testcases. Is this an issue on my side,
or did you forget to attach them?
Thanks,
Harald
On 4/7/23 09:07, Paul Richard Thomas via Gcc-patches wrote:
Dear All,
Please find attached a slightly updated version of the patch with a
consolidated testcase. The three
Hi Paul,
On 4/7/23 09:02, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
Please find attached the patch to fix the dg directives and remove a lot of
trailing white space.
Unless there are any objections, I will commit as obvious over the weekend.
this is OK.
Thanks for the patch!
On 4/5/23 20:50, Harald Anlauf via Gcc-patches wrote:
can you have a look again at the logic in the hunk touching
trans-stmt.cc (gfc_trans_allocate)? I haven't checked in detail,
but it seems possible that you get a stale tmp in the
gfc_prepend_expr_to_block if (code
Hi Paul,
On 4/5/23 08:53, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
This is a first in my recent experience - a very old bug that produces too
many finalizations! It results from a bit of a fix up, where class objects
are allocated using the derived typespec, rather than a source or
Hi Bernhard,
there is neither context nor a related PR with a testcase showing
that this patch fixes issues seen there.
On 4/2/23 17:05, Bernhard Reutner-Fischer via Gcc-patches wrote:
From: Bernhard Reutner-Fischer
Cc: fort...@gcc.gnu.org
gcc/fortran/ChangeLog:
* array.cc
17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 3 Apr 2023 21:34:01 +0200
Subject: [PATCH] Fortran: reject module variable as character length in
PARAMETER [PR104349]
gcc/fortran/ChangeLog:
PR fortran/104349
* expr.cc (check_restricted): Adjust check for valid variables in
restricted
ar 2023 at 19:13, Harald Anlauf via Fortran
mailto:fort...@gcc.gnu.org]> wrote:Dear all,
I've committed the attached patch from the PR that removes
a dead code snippet, see discussion.
Regtested originally by Tobias, and reconfirmed on
x86_64-pc-linux-gnu.
Pushed as r13-6862-gb5fce899dbbd7
:00 2001
From: Harald Anlauf
Date: Sat, 25 Mar 2023 19:59:45 +0100
Subject: [PATCH] Fortran: remove dead code [PR104321]
gcc/fortran/ChangeLog:
PR fortran/104321
* trans-decl.cc (gfc_conv_cfi_to_gfc): Remove dead code.
---
gcc/fortran/trans-decl.cc | 3 ---
1 file changed, 3 deletions(-)
diff
833233a4aefc9981b671c1bda34676c20b76cc90 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 24 Mar 2023 22:07:37 +0100
Subject: [PATCH] Fortran: fix FE memleak with BOZ expressions.
gcc/fortran/ChangeLog:
* expr.cc (free_expr0): Free also BOZ strings as part of an expression.
---
gcc/fortran/expr.cc | 4
1 file changed
Dear all,
I've committed the attached simple patch after discussion with
Steve (see PR). We need to reject alternate return arguments
of FINAL subroutines.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
From 3e791f45ded89626bc1f9f8013728f6e035801b2 Mon Sep 17 00:00:00 2001
From: Harald
Hi Tobias,
Am 21.03.23 um 09:31 schrieb Tobias Burnus:
On 20.03.23 21:57, Harald Anlauf via Gcc-patches wrote:
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -9998,6 +9998,7 @@ gfc_match_modproc (void)
if ((gfc_state_stack->state != COMP_INTERFACE
&& gfc_state_s
Hi Thomas,
Am 20.03.23 um 08:14 schrieb Thomas Koenig via Gcc-patches:
so it the general problem is not restricted to -O3 and not
to current trunk, it depends on the details.
I doubt that the result from 9.4.0 was expected, but rather
nobody noticed. Or, bringing out the pseudo-RNG into a
9c59709fad91c99041a9cb770b98da17af01d260 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 20 Mar 2023 21:50:59 +0100
Subject: [PATCH] Fortran: reject MODULE PROCEDURE outside generic module
interface [PR99036]
gcc/fortran/ChangeLog:
PR fortran/99036
* decl.cc (gfc_match_modproc): Reject
:00:00 2001
From: Harald Anlauf
Date: Mon, 20 Mar 2023 20:55:00 +0100
Subject: [PATCH] Fortran: fix documentation of -fno-underscoring [PR109216]
gcc/fortran/ChangeLog:
PR fortran/109216
* invoke.texi: Correct documentation of how underscores are appended
to external names.
---
gcc/fortran
open branches.
(The issue was apparently introduced in r0-84566-gb6f63e898498e6
without noticing, so it is technically a regression.)
Thanks,
Harald
From 9391bd0eeef8e069d9e49f9aa277160b43aaf4f3 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 19 Mar 2023 21:29:46 +0100
Subject: [PATCH
Hi Thomas,
Am 19.03.23 um 08:34 schrieb Thomas Koenig via Gcc-patches:
Hi Harald,
Am 18.03.23 um 19:52 schrieb Thomas Koenig via Gcc-patches:
Hi Harald,
the Fortran standard requires an explicit procedure interface in
certain
situations, such as when they have a BIND(C) attribute
Hi Thomas,
Am 18.03.23 um 19:23 schrieb Thomas Koenig via Gcc-patches:
Hi,
Text says it all. OK for web pages?
Best regards
Thomas
Mention issues with integer owerflow for random number generators.
This mentions the issues with integer overflow and how to work
around them.
it's
Hi Thomas,
Am 18.03.23 um 19:52 schrieb Thomas Koenig via Gcc-patches:
Hi Harald,
the Fortran standard requires an explicit procedure interface in certain
situations, such as when they have a BIND(C) attribute (F2018:15.4.2.2).
The attached patch adds a check for this.
Regtested on
, so it might be backported
to all open branches.
Thanks,
Harald
From c48c670ff0ce4f0d2ffb1d43aca2ec1bed1fa2ef Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 17 Mar 2023 22:24:49 +0100
Subject: [PATCH] Fortran: procedures with BIND(C) attribute require explicit
interface [PR85877]
gcc
Hi Tobias,
Am 15.03.23 um 10:10 schrieb Tobias Burnus:
Hi Harald,
On 14.03.23 20:38, Harald Anlauf wrote:
The testcase covers only non-coarray cases, as playing with
coarray variants hit pre-exisiting issues in gfortran that
are very likely unrelated to the interface checks.
I concur
in gfortran that
are very likely unrelated to the interface checks. I consider
this rather as post 13-release stuff.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 4453686ae4e70c14a0898c6687db912fa84ece9f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 14 Mar 2023 20
Dear all,
I've committed the attached patch to mainline as obvious after
regtesting on x86_64-pc-linux-gnu.
https://gcc.gnu.org/g:2cf5f485e0351bb1faf46196a99e524688f3966e
commit r13-6605-g2cf5f485e0351bb1faf46196a99e524688f3966e
Author: Harald Anlauf
Date: Sat Mar 11 15:37:37 2023 +0100
.
Thanks,
Harald
From ef96d7d360c088d68e3b405401bdb8b589d562f2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 9 Mar 2023 18:59:08 +0100
Subject: [PATCH] Fortran: fix ICE with bind(c) in block data [PR104332]
gcc/fortran/ChangeLog:
PR fortran/104332
* resolve.cc (resolve_symbol): Avoid
Hi Mikael,
Am 04.03.23 um 23:29 schrieb Mikael Morin:
Le 04/03/2023 à 22:20, Harald Anlauf a écrit :
Hi Mikael,
Am 04.03.23 um 18:09 schrieb Mikael Morin:
There was a comment about the old_symbol thing at the end of my previous
message:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March
Hi Mikael,
Am 04.03.23 um 18:09 schrieb Mikael Morin:
There was a comment about the old_symbol thing at the end of my previous
message:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613354.html
I think Tobias might be the better person to answer this.
But when playing with variations
Sorry, attached the wrong patch.
Here's the correct one.
Harald
Am 04.03.23 um 17:02 schrieb Harald Anlauf via Gcc-patches:
The attached revised version uses the above proven changes,
and extends the new testcase class_74.f90 by variations of
the failures remaining with version 1 so
Regtested again on x86_64-pc-linux-gnu.
Any further comments?
Thanks for your very helpful review!
Harald
From 70cba7da18023282546b9a5d80e976fc3744d732 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 5 Oct 2022 22:25:14 +0200
Subject: [PATCH] Fortran: reject procedures and procedure pointers a
Regtested again on x86_64-pc-linux-gnu.
Any further comments?
Thanks for your very helpful review!
Harald
From 70cba7da18023282546b9a5d80e976fc3744d732 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 5 Oct 2022 22:25:14 +0200
Subject: [PATCH] Fortran: reject procedures and proced
Hi Steve,
Am 03.03.23 um 20:57 schrieb Steve Kargl via Gcc-patches:
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
- if (attr->class_ok)
-/* Class container has already been built. */
+ /* Class container has already been built with same name. */
+ if (a
duplicates at some level.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 4600577e3ecceb2525618685f47c8a979cf9d244 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 2 Mar 2023 22:37:14 +0100
Subject: [PATCH] Fortran: fix CLASS attribute handling [PR106856]
gcc/fortran
.
Attached patch fixes this and regtests on x86_64-pc-linux-gnu.
OK for mainline?
This issue has been there for ages. Shall this be backported
or left in release branches as is?
Thanks,
Harald
From 6844c5ecb271e091a8c913903a79eac932cf5f76 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon
Hi Jerry,
regarding PACK: since this is a bogus warning as the compiler does
not realize that dim >= 1, wouldn't a
gcc_assert (dim >= 1);
in the right place achieve the same effect, since the first argument
must be an array?
(It's different for SPREAD, though, where SOURCE may be scalar).
.
Pushed to mainline as r13-6344-g03c60e525bea13 .
Thanks,
Harald
From 03c60e525bea13c15edd2f64cd582f168fe80bfb Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 25 Feb 2023 19:05:38 +0100
Subject: [PATCH] Fortran: fix memory leak with real to integer conversion
warning
gcc/fortran
Hi Mikael,
Am 25.02.23 um 17:35 schrieb Mikael Morin:
Hello,
Harald found a testcase with memory still leaking despite my previous
patch for PR108923.
That patch was fixing a leak caused by absence of memory release, the
attached patch fixes a leak caused by pointer overwrite.
I haven't
Hi Rimvydas,
Am 24.02.23 um 06:16 schrieb Rimvydas Jasinskas via Gcc-patches:
On Thu, Feb 23, 2023 at 10:53 PM Harald Anlauf wrote:
the patch is mostly fine, but there is a minor style issue:
+ if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+ gfc_error ("Sy
Hi Tobias,
Am 24.02.23 um 12:31 schrieb Tobias Burnus:
(B) The attached patch:
With 'intent(out)' there is no reason to do the conversions. While for
nullified
pointers the bounds-conversion loop is skipped, it may still be executed
for undefined
pointers. (Which is usually harmless.) In
-g45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3
Author: Harald Anlauf
Date: Fri Feb 24 19:56:32 2023 +0100
Thanks,
Harald
From 45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 24 Feb 2023 19:56:32 +0100
Subject: [PATCH] Fortran: frontend passes do_subscript leaks gmp memory
[PR108924
reasonable.
Thanks,
Harald
From 0a392415cb5d5486e3e660880c81d6fdbbb47285 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 21 Feb 2023 22:06:33 +0100
Subject: [PATCH] Fortran: reject invalid CHARACTER length of derived type
components [PR96024]
gcc/fortran/ChangeLog:
PR fortran/96024
:6c1b825b3d6499dfeacf7c79dcf4b56a393ac204
commit r13-6265-g6c1b825b3d6499dfeacf7c79dcf4b56a393ac204
Author: Harald Anlauf
Date: Mon Feb 20 21:28:09 2023 +0100
OK either way.
The PR is marked as a 10/11/12/13 regression, so I would
like to backport this as far as it seems reasonable.
Also OK.
Thanks
for mainline?
The PR is marked as a 10/11/12/13 regression, so I would
like to backport this as far as it seems reasonable.
Thanks,
Harald
From f581f63e206b54278c27a5c888c2566cb5077f11 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 20 Feb 2023 21:28:09 +0100
Subject: [PATCH] Fortran
Dear all,
I've committed the attached obvious and trivial patch for another
NULL pointer dereference on behalf of Steve and after regtesting on
x86_64-pc-linux-gnu as r13-6067-gc75cbeba81e5b4737a9ab7dd28cce650965535a9
Thanks,
Harald
From c75cbeba81e5b4737a9ab7dd28cce650965535a9 Mon Sep 17
Dear all,
I've committed the attached obvious and trivial patch for a NULL
pointer dereference on behalf of Steve and after regtesting on
x86_64-pc-linux-gnu as r13-6066-ga418129273725fd02e881e6fb5e0877287a1356c
Thanks,
Harald
From a418129273725fd02e881e6fb5e0877287a1356c Mon Sep 17 00:00:00
Hi Thomas,
On 2/14/23 10:35, Thomas Schwinge wrote:
Hi!
On 2023-02-13T18:50:23+0100, Harald Anlauf via Gcc-patches
wrote:
Pushed as:
commit 086a1df4374962787db37c1f0d1bd9beb828f9e3
On 2/12/23 22:28, Harald Anlauf via Gcc-patches wrote:
There is one thing I cannot test, which
2ce7e2a83e18a27fe9c659f8667fc24f0df4ea9a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 13 Feb 2023 22:02:44 +0100
Subject: [PATCH] Fortran: error recovery after invalid use of CLASS variable
[PR103475]
gcc/fortran/ChangeLog:
PR fortran/103475
* primary.cc (gfc_expr_attr): Avoid NULL pointer dereference
Pushed as:
commit 086a1df4374962787db37c1f0d1bd9beb828f9e3
Thanks,
Harald
On 2/12/23 22:28, Harald Anlauf via Gcc-patches wrote:
Hi Rimvydas,
Gesendet: Sonntag, 12. Februar 2023 um 07:59 Uhr
Von: "Rimvydas Jasinskas"
An: "Harald Anlauf"
Cc: "fortran"
Bet
Hi Rimvydas,
> Gesendet: Sonntag, 12. Februar 2023 um 07:59 Uhr
> Von: "Rimvydas Jasinskas"
> An: "Harald Anlauf"
> Cc: "fortran"
> Betreff: Re: Support for NOINLINE attribute
>
> On Sat, Feb 11, 2023 at 11:26 PM Harald Anlauf wrote:
&
a618b45ac41cf480f54c4fa4014aed6218931290 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 9 Feb 2023 21:16:14 +0100
Subject: [PATCH] Fortran: catch invalid kind in character conversion
[PR69636,PR103779]
gcc/fortran/ChangeLog:
PR fortran/69636
PR fortran/103779
* intrinsic.cc
Dear all,
the attached trivial patch by Steve fixes a NULL pointer dereference
that occurs when an error shall be emitted for a global entity that
conflicts with a symbol appearing in a COMMON block, but the symbol's
location is not set. This may happen e.g. in the testcase in the PR,
where the
Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 6 Feb 2023 20:59:51 +0100
Subject: [PATCH] Fortran: ASSOCIATE variables should not be TREE_STATIC
[PR95107]
gcc/fortran/ChangeLog:
PR fortran/95107
* trans-decl.cc (gfc_finish_var_decl): With -fno-automatic, do not
make ASSOCIATE
Early gentle ping.
Am 30.01.23 um 22:55 schrieb Harald Anlauf via Gcc-patches:
Dear Fortranners,
the subject says it all: in some cases we emit redundant integer division
truncation warnings (2 or 4), where just one would have been sufficient.
This is solved by using gfc_warning instead
Hi Ben,
Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:
Hi,
This patch series adds initial support for ISO C++'s [P1689R5][], a
format for describing C++ module requirements and provisions based on
the source code. This is required because compiling C++ with modules is
not
Dear all,
the fix for PR108527 came with a testcase that revealed a latent
bug with array sections and invalid array declarations. The ICE
first popped up on powerpc64-linux-gnu (big endian), but the issue
was not so clear as such on x86_64-pc-linux-gnu, as it did not show
up e.g. in valgrind.
the
desired warning exactly once.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 8340523c8df8edd008174d44e87c0fa54b58b2c7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 30 Jan 2023 22:46:43 +0100
Subject: [PATCH] Fortran: prevent redundant integer division
Hi Mikael,
Am 29.01.23 um 17:21 schrieb Mikael Morin:
Hello,
this is a fix for a gcc-12 ICE regression.
This ICE rings a bell to me, and I think the change by Tobias which
triggers it only uncovers a bug that can also happen independently in
other cases.
The problem is resolution of maxloc
Early gentle ping.
Am 24.01.23 um 22:48 schrieb Harald Anlauf via Gcc-patches:
Dear all,
when checking expressions for array sections, we need to ensure
that these use only type INTEGER. However, it does not make sense
to generate an internal error when encountering wrong types,
but rather
From 3f0e4b23038ade2cd14d93b0705af93848ee45c2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 28 Jan 2023 17:59:23 +0100
Subject: [PATCH] Fortran: diagnose USE associated symbols in COMMON blocks
[PR108453]
gcc/fortran/ChangeLog:
PR fortran/108453
* match.cc (gfc_match_common): A USE
201 - 300 of 873 matches
Mail list logo
