59034b3b938a2f5e3391208fca56fcf54d5b6d18 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 25 Jan 2023 22:47:26 +0100
Subject: [PATCH] Fortran: fix ICE in check_host_association [PR108544]
gcc/fortran/ChangeLog:
PR fortran/108544
* resolve.cc (check_host_association): Extend host association check
so
Dear all,
I've committed the attached simple and obvious patch by
Steve after regtesting on x86_64-pc-linux-gnu.
Instead of generating an internal error when wrong types
are passed to a bounds comparison, simply return false.
Committed:
Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 24 Jan 2023 22:36:25 +0100
Subject: [PATCH] Fortran: fix ICE in compare_bound_int [PR108527]
gcc/fortran/ChangeLog:
PR fortran/108527
* resolve.cc (compare_bound_int): Expression to compare must be of
type INTEGER.
(compare_bound_mpz_t
hed to mainline as
https://gcc.gnu.org/g:6c96382eed96a9285611f2e3e2e59557094172b8
The PR is marked as a 10/11/12/13 regression, thus I plan to
backport.
Thanks,
Harald
From 6c96382eed96a9285611f2e3e2e59557094172b8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 24 Jan 2023 21:39:43 +0
d27e1b13ba312411ce271f5122f694ffe6c051e6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 23 Jan 2023 22:13:44 +0100
Subject: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency
[PR108502]
gcc/fortran/ChangeLog:
PR fortran/108502
* dependency.cc (gfc_check_dependency): Prevent
in get_expr_storage_size.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 771d793df1622a476e1cf8d05f0a6aee350fa56b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 23 Jan 2023 21:19:03 +0100
Subject: [PATCH] Fortran: avoid ICE on invalid array subscript triplets
[PR108501]
gcc
Ping!
Am 16.01.23 um 22:11 schrieb Harald Anlauf via Gcc-patches:
Dear all,
it appears that the fix for pr107874 uncovered a latent bug
for the case of arrays of type character and size zero when
passed to the intrinsics MERGE and SPREAD as SOURCE. In that
case, there is no constructor from
Hi Jerry,
Am 21.01.23 um 19:27 schrieb Jerry D via Gcc-patches:
On 1/20/23 9:16 PM, Jerry D wrote:
On 1/20/23 5:46 PM, Jerry D wrote:
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which
turns out
Am 19.01.23 um 20:39 schrieb Jason Merrill via Gcc-patches:
On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
wrote:
Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
This function definition was removed years ago, remove it's prototype.
gcc/fortran
.
Thanks,
Harald
From e240637f6c2e2605a8424538bee885d899507506 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 18 Jan 2023 22:13:29 +0100
Subject: [PATCH] Fortran: error recovery for invalid CLASS component
[PR108434]
gcc/fortran/ChangeLog:
PR fortran/108434
* expr.cc (class_allocatable
Hi Tobias,
Am 18.01.23 um 16:42 schrieb Tobias Burnus:
Reported by nightstrike, who also tested this patch.
On Windows, we call system() which works as described at
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/system-wsystem?view=msvc-170
Namely, it only fails with "-1"
:00:00 2001
From: Harald Anlauf
Date: Mon, 16 Jan 2023 21:41:09 +0100
Subject: [PATCH] Fortran: fix ICE in check_charlen_present [PR108420]
gcc/fortran/ChangeLog:
PR fortran/108420
* iresolve.cc (check_charlen_present): Preserve character length if
there is no array constructor.
gcc/testsuite
Dear all,
here's an obvious patch for an ICE-on-invalid where we missed
a check that we actually have an integer length before trying
to extract a usable value.
Regtested on x86_64-pc-linux-gnu.
I intend to commit it to mainline within the next 24h unless
there are comments.
Cheers,
Harald
regtesting on x86_64-pc-linux-gnu as:
r13-5095-gfec9fc1a17ec44461cee841513f1b6b8ad680fe4
Thanks,
Harald
From fec9fc1a17ec44461cee841513f1b6b8ad680fe4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 10 Jan 2023 22:41:17 +0100
Subject: [PATCH] Fortran: frontend passes do_subscript leaks gmp
Hi Jerry,
Am 26.12.22 um 23:26 schrieb Jerry DeLisle via Gcc-patches:
The attached patch was provided by Steve Kargl. After exploring for
possible other checks I settled on leaving the patch intact.
Two existing test cases updated as different but sensible error messages
resulted.
I think
Am 17.12.22 um 22:21 schrieb Harald Anlauf via Gcc-patches:
Dear all,
the previous fix for pr103505 introduced a regression that could lead
to wrong array bounds when LBOUND/UBOUND were used in the array spec
of a declaration. The reason was that we tried to simplify too early
the array
Dear all,
the attached patch adds a check for statement function bodies for
invalid uses of dummy arguments. This fixes an ICE-on invalid.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 794af0d00b7086c9f0493f3a1aaac644e1fd50f6 Mon Sep 17 00:00:00 2001
From: Harald
dc22544c2412cf8810a4956f537a2f50e0711a05 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 20 Dec 2022 21:17:08 +0100
Subject: [PATCH] Fortran: a C interoperable function cannot have the CLASS
attribute [PR95375]
gcc/fortran/ChangeLog:
PR fortran/95375
* decl.cc (verify_bind_c_sym): Extend
-gnu. OK for mainline?
As this is a 10/11/12/13 regression, I would like to backport
as seems fit.
Thanks,
Harald
From 531be0753352ec30c4b1e24591ec3e0c33cd4409 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 17 Dec 2022 22:04:32 +0100
Subject: [PATCH] Fortran: incorrect array bounds when
Hi Tobias,
thanks for your explanation! Now things are clearer.
Am 14.12.22 um 08:57 schrieb Tobias Burnus:
@@ -63 +66 @@ cfi_desc_to_gfc_desc (gfc_array_void *d,
- d->dtype.version = s->version;
+ d->dtype.version = 0;
I was wondering what the significance of "version" is.
In
Hi Tobias,
Am 13.12.22 um 22:41 schrieb Tobias Burnus:
Note: We only talk about those two functions, the other functions are used
by both GCC <= 11 and GCC >= 12.
yes.
Fortunately, these functions matter most as they map GFC internals to CFI
internals or vice versa. Most other functions are
Hi Tobias,
Am 13.12.22 um 17:29 schrieb Tobias Burnus:
This is a 12/13 regression as come changes to fix the GFC/CFI descriptor
that went into GCC 12 fail with the (bogus) descriptor passed via by a
GCC-11-compiled program.
As later GCC 12 changes moved the descriptor to the front end, those
Dear all,
here's another obvious patch by Steve which prevents a
NULL pointer dereference during parsing.
Regtested on x86_64-pc-linux-gnu.
Will commit to mainline within 24h unless there are comments.
Thanks,
Harald
From f23a5252ee086f9b78c44150d409e40a445c6928 Mon Sep 17 00:00:00 2001
From:
Hi Steve,
Am 12.12.22 um 00:52 schrieb Steve Kargl via Gcc-patches:
On Sun, Dec 11, 2022 at 11:33:43PM +0100, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch improves checking of array specs in two ways:
- bad assumed size array spec
- a bad first array element spec may already
06c1d0a96544640c7b1485fe977337ef1572ac91 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 11 Dec 2022 23:24:03 +0100
Subject: [PATCH] Fortran: improve checking of assumed size array spec
[PR102180]
gcc/fortran/ChangeLog:
PR fortran/102180
* array.cc (match_array_element_spec): Add check for bad
Dear all,
I'm submitting the attached patch on behalf of Steve.
It fixes an ICE that occurs on an obscure use of a
statement function as argument to that function.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From f717054e7d656588650f6d4fd5a03840c6dc9a9c Mon Sep 17
Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 10 Dec 2022 22:05:15 +0100
Subject: [PATCH] Fortran: reject bad SIZE argument while simplifying ISHFTC
[PR106911]
gcc/fortran/ChangeLog:
PR fortran/106911
* simplify.cc (gfc_simplify_ishftc): If the SIZE argument is known
to be outside
Dear all,
I am submitting the attached simple - and obvious - patch on
behalf of Paul. It prevents a resource exhaustion due to an
infinite loop, and has been regtested by multiple contributers, ;-)
at least on x86_64-pc-linux-gnu.
I intend to commit it to mainline within 24 hours, unless
there
?
Thanks,
Harald
From 3a9f6d5a8ee490adf9a18f93feaf86542642be7d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 8 Dec 2022 22:50:45 +0100
Subject: [PATCH] Fortran: diagnose and reject duplicate CONTIGUOUS attribute
[PR108025]
gcc/fortran/ChangeLog:
PR fortran/108025
* symbol.cc
From 02a8b7308d04dc84fb13b077bd3b2fe01e15c92e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 7 Dec 2022 21:50:23 +0100
Subject: [PATCH] Fortran: handle zero-sized arrays in ctors with typespec
[PR108010]
gcc/fortran/ChangeLog:
PR fortran/108010
* arith.cc (reduce_unary): Handle zero-s
Hi Mikael,
Am 04.12.22 um 14:11 schrieb Mikael Morin:
Le 01/12/2022 à 21:25, Harald Anlauf via Fortran a écrit :
Dear all,
we did not properly handle the case of insufficient array-valued
FIELD when trying to simplify UNPACK and could run into a NULL
pointer dereference. The fix is obvious
Hi Paul,
thanks - and it is good to see that you are back!
Harald
Am 04.12.22 um 12:48 schrieb Paul Richard Thomas via Gcc-patches:
Hi Harald,
That's good to commit.
Thanks for the patch.
Paul
On Sat, 3 Dec 2022 at 20:40, Harald Anlauf via Fortran
wrote:
Dear all,
here's a small
or mainline?
Thanks,
Harald
From 2ad9a19b1cfc0bd9c71d10894f9aca2532f88db4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 3 Dec 2022 21:13:48 +0100
Subject: [PATCH] Fortran: fix typo in documentation of intrinsic FLOOR
[PR107870]
gcc/fortran/ChangeLog:
PR fortran/107870
* intr
From: Harald Anlauf
Date: Sat, 3 Dec 2022 19:21:07 +0100
Subject: [PATCH] Fortran: error recovery handling invalid CLASS variable
[PR107899]
gcc/fortran/ChangeLog:
PR fortran/107899
* resolve.cc (resolve_deallocate_expr): Avoid NULL pointer dereference
on invalid CLASS variable.
gcc/testsuite
schrieb Paul Richard Thomas via Gcc-patches:
Hi Harald,
It looks good to me.
Thanks to you and Steve for the patch.
Paul
On Mon, 28 Nov 2022 at 20:05, Harald Anlauf via Fortran
wrote:
Dear all,
as reported, the Fortran standard requires all actual argument
expressions to be evaluated (e.g
Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 1 Dec 2022 21:16:46 +0100
Subject: [PATCH] Fortran: error recovery simplifying UNPACK for insufficient
FIELD [PR107922]
gcc/fortran/ChangeLog:
PR fortran/107922
* simplify.cc (gfc_simplify_unpack): Terminate simplification when
array
or assumed. I decided to modify the
test in such way that simplification is valid and provides
the expect pattern.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 0f6058937c04a7af5e6dcfa173648149c24f08df Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 28 Nov 202
.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From c6f9d47f2e631a7ace71466ba6ec6f323d791b1b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 27 Nov 2022 21:10:18 +0100
Subject: [PATCH] Fortran: ICE with elemental and dummy argument with VALUE
attribute [PR107819]
gcc
Dear all,
please find attached an obvious patch by Steve for a technical
regression that resulted from improvements in error recovery
of bad uses of associate.
Regtested on x86_64-pc-linux-gnu.
Will commit soon unless there are comments.
As a sidenote: the testcase shows that we resolve the
c6b19d662f51b1e2d2691e81cfeb68ad953a4c09 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 17 Nov 2022 21:36:49 +0100
Subject: [PATCH] Fortran: reject NULL actual argument without explicit
interface [PR107576]
gcc/fortran/ChangeLog:
PR fortran/107576
* interface.cc (gfc_procedure_use
Dear all,
I've committed the attached patch for Steve after regtesting.
It obviously checks the types of character length to be integer
before passing them to mpz_*.
Pushed as r13-4113-gbdd784fc48a283d54f5f1e3cc2a0668c14dd3bee
Thanks,
Harald
@Steve: please close PR if you think everything is
00:00:00 2001
From: Harald Anlauf
Date: Wed, 16 Nov 2022 21:41:19 +0100
Subject: [PATCH] Fortran: error recovery after reference to bad CLASS variable
[PR107681]
gcc/fortran/ChangeLog:
PR fortran/107681
* resolve.cc (resolve_fl_var_and_proc): Prevent NULL pointer
dereference with reference
Am 16.11.22 um 12:39 schrieb Mikael Morin:
Le 15/11/2022 à 21:45, Harald Anlauf via Fortran a écrit :
Dear all,
when constant expressions involve parentheses, array constructors,
typespecs, and the power operator (**), we could fail with an ICE
during simplification in arith_power.
Debugging
for mainline?
Thanks,
Harald
From efe9dafabc2e2cc2dab079dfa3be3d09b3471c0f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 15 Nov 2022 21:20:20 +0100
Subject: [PATCH] Fortran: ICE in simplification of array expression involving
power [PR107680]
gcc/fortran/ChangeLog:
PR fortran/107680
, which does
the adjustment of the name of the generated internal symbol.
Can you please confirm that it fixes your issues?
Thanks,
Harald
From 872ed50812d3ca13554411e107317161777ecf5d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 13 Nov 2022 21:53:58 +0100
Subject: [PATCH] Fortran: fix
Am 13.11.22 um 11:39 schrieb Bernhard Reutner-Fischer via Gcc-patches:
On Sun, 13 Nov 2022 12:13:26 +0200
Janne Blomqvist wrote:
On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran
wrote:
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1135,7 +1135,7 @@
Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
This function definition was removed years ago, remove it's prototype.
gcc/fortran/ChangeLog:
* gfortran.h (gfc_check_include): Remove declaration.
---
gcc/fortran/gfortran.h | 1 -
1 file changed, 1 deletion(-)
-gnu. OK for mainline?
Thanks,
Harald
From d87e299dd2b7f4be6ca829e80cd94babc53fa12f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 10 Nov 2022 22:30:27 +0100
Subject: [PATCH] Fortran: fix treatment of character, value, optional dummy
arguments [PR107444]
Fix handling of character dummy
Dear all,
Jose posted a patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html
I think the diagnostics improvement is helpful, as it adjusts
to the changes from F2003 to F2008.
The patch suffered a little from bitrot, but was otherwise
straightforward
e505f7493bed1395d121d2f53137ec11706fa42e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 9 Nov 2022 21:05:28 +0100
Subject: [PATCH] Fortran: avoid NULL pointer dereference on bad EQUIVALENCEs
[PR107559]
gcc/fortran/ChangeLog:
PR fortran/107559
* resolve.cc (resolve_equivalence): Avoid NULL
r testcase above compiles
and runs. But as explained, I don't want to add it now.
Regtested again. What do you think?
Thanks,
Harald
From 8694d1d2cbd19b5148b5d1d891b182cc3e718f40 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 28 Oct 2022 21:58:08 +0200
Subject: [PATCH] Fortran
Dear all,
Am 04.11.22 um 10:53 schrieb Mikael Morin:
Le 03/11/2022 à 23:03, Harald Anlauf a écrit :
I've spent some time not only staring at create_function_arglist,
but trying several variations handling the declared hidden parms,
and applying the necessary adjustments
Am 03.11.22 um 11:06 schrieb Mikael Morin:
Le 02/11/2022 à 22:19, Harald Anlauf via Fortran a écrit :
Am 02.11.22 um 18:20 schrieb Mikael Morin:
Unfortunately no, the coarray case works, but the other problem remains.
The type problem is not visible in the definition of S
Am 02.11.22 um 18:20 schrieb Mikael Morin:
Unfortunately no, the coarray case works, but the other problem remains.
The type problem is not visible in the definition of S, it is in the
declaration of S's prototype in P.
S is defined as:
void s (character(kind=1)[1:_c] & restrict c,
46b84e831bbead6095a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 28 Oct 2022 21:58:08 +0200
Subject: [PATCH] Fortran: ordering of hidden procedure arguments [PR107441]
gcc/fortran/ChangeLog:
PR fortran/107441
* trans-decl.cc (create_function_arglist): Adjust the ordering of
automat
7 00:00:00 2001
From: Harald Anlauf
Date: Fri, 28 Oct 2022 21:58:08 +0200
Subject: [PATCH] Fortran: ordering of hidden procedure arguments [PR107441]
gcc/fortran/ChangeLog:
PR fortran/107441
* trans-decl.cc (create_function_arglist): Adjust the ordering of
automatically generated hidden
on x86_64-pc-linux-gnu. OK for mainline?
The PR is marked as a 10/11/12/13 regression, so OK for backports?
Thanks,
Harald
From 986bf9cc5abc51598609b16edc9242a87244571b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 26 Oct 2022 21:00:44 +0200
Subject: [PATCH] Fortran: BOZ literal constants
Hi Mikael,
Am 21.10.22 um 13:13 schrieb Mikael Morin:
Le 18/10/2022 à 22:48, Harald Anlauf via Fortran a écrit :
I intended to add the updated patch but forgot, so here it is...
Am 18.10.22 um 22:41 schrieb Harald Anlauf via Fortran:
Dear all,
Jose posted a patch here that was never
From 0da12c71a6ccbefa1456be5759974a4b450c78e6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 19 Oct 2022 22:37:56 +0200
Subject: [PATCH] Fortran: error recovery with references of bad array
constructors [PR105633]
gcc/fortran/ChangeLog:
PR fortran/105633
* expr.cc (find_array_section
I intended to add the updated patch but forgot, so here it is...
Am 18.10.22 um 22:41 schrieb Harald Anlauf via Fortran:
Dear all,
Jose posted a patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
I could not find any issues with his patch
Dear all,
Jose posted a patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
I could not find any issues with his patch, it works as advertised
and fixes the reported problem.
As his testcases did not reliably fail without the patch but rather
Dear all,
I've pushed a very obvious fix for a NULL pointer dereference
on behalf of Steve after regtesting on x86_64-pc-linux-gnu as
https://gcc.gnu.org/g:84807af0ca6dfdb81abb8e925ce32acbcab29868
Thanks,
Harald
Hi Mikael,
Am 16.10.22 um 23:17 schrieb Mikael Morin:
Le 15/10/2022 à 22:15, Harald Anlauf via Fortran a écrit :
Dear all,
here is an updated version of the patch that includes suggestions
and comments by Mikael in PR93483.
Basic new features are:
- a new enum value ARITH_NOT_REDUCED to keep
Hi Tobias,
the patch LGTM.
Regarding testcase char4_decl-2.f90, I played a little and found that
one could in addition check the storage_size of aa, pp in the main and
compare with storage_size (4_'foo') etc. Without your patch the
storage sizes look odd. (Strictly speaking, a comparison like
of accepts-invalid.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 779baf06888f3adef13c12c468c0a5ef0a45f93e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 16 Oct 2022 20:32:27 +0200
Subject: [PATCH] Fortran: check type of operands of logical operations,
comparisons
ee65197f4d0b0050dc61687b5a77f1afe3bd4a27 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 12 Oct 2022 21:33:36 +0200
Subject: [PATCH] Fortran: simplify array constructors with typespec [PR93483,
PR107216, PR107219]
gcc/fortran/ChangeLog:
PR fortran/93483
PR fortran/107216
PR fortran/107219
* array.cc
/, keeping an internal error if any
unhandled type shows up,
- numeric types for **
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From a95f251504bcb8ba28b7db1d2b7990631c761e9c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 11 Oct 2022 22:08:48 +0200
Subject: [PATC
of the source expression.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 87dae7eb9d4cc76060d258ba99bc53f62c7130f2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 11 Oct 2022 20:37:42 +0200
Subject: [PATCH] Fortran: check types of source expressions before conversion
-linux-gnu. OK for mainline?
Thanks,
Harald
From 4db0aba8309a2c7e2c7ac95195621dff02e9796c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 9 Oct 2022 20:43:32 +0200
Subject: [PATCH] Fortran: fix check of polymorphic elements in data transfers
[PR100971]
gcc/fortran/ChangeLog:
PR fortran
Hi Mikael,
Am 07.10.22 um 22:26 schrieb Mikael Morin:
Le 07/10/2022 à 21:47, Mikael Morin a écrit :
Let me have a look.
The attached patch works with your test, I just moved the checks into
the loops.
I'm now checking the patch against the full fortran testsuite.
I'm (finally) fine with that
Am 07.10.22 um 10:01 schrieb Mikael Morin:
Le 06/10/2022 à 23:36, Harald Anlauf a écrit :
For example, for this case:
[real :: 2] * [real :: +(.true.)]
First there is a "root" invocation of reduce binary with arguments [real
:: 2] and [real :: +(.true.)]
The root invocation of red
Hi Mikael,
> Gesendet: Donnerstag, 06. Oktober 2022 um 22:14 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf"
> Cc: "fortran" , "gcc-patches"
> Betreff: Re: [PATCH, v2] Fortran: error recovery for invalid types in array
> constructors [
gfc_simplify_expr (result, 1);
seems to fail in interesting cases (as in PR105371).
So that is something to look into...
Cheers,
Harald
> Gesendet: Donnerstag, 06. Oktober 2022 um 22:32 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf"
> Cc: "gc
Hi Mikael,
> Gesendet: Mittwoch, 05. Oktober 2022 um 11:23 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf" , "fortran" ,
> "gcc-patches"
> Betreff: Re: [PATCH] Fortran: error recovery for invalid types in array
> constructors [PR107
thanks for your comments!
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 as IO
element [PR107074]
gcc/fortran/ChangeLog:
PR fortran/1070
from these errors, and tries to handle
all unary and binary arithmetic expressions.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From ad892a270c504def2f8f84494d5c7bcba9aef27f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 4 Oct 2022 23:04:06 +0200
Subject: [PATCH
not
have a value that is a procedure pointer.
Attached patch generates an error instead.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 3b15fe83830c1e75339114e0241e9d2158393017 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 4 Oct 2022 21:19:21 +0200
Subject: [PATCH
Am 04.10.22 um 17:12 schrieb Ben Boeckel:
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Is there a reason that you are touching so many frontends?
diff
and testcase by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This is a 10/11/12/13 regression and shall be backported.
Thanks,
Harald
From 80285cdad1fe98c52ebf38f9f66070b2a50191c6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 27 Sep 2022 20:54:28 +0200
Subject: [PATCH
Dear all,
the patch for these PRs was submitted for review by Jose here:
https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html
but unfortunately was never reviewed.
I verified that the rebased patch still works on mainline and
x86_64-pc-linux-gnu, and I think that it is fine. It is
Dear all,
the patch for this PR was submitted for review by Jose here:
https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html
but unfortunately was never reviewed.
I verified that it works on mainline and x86_64-pc-linux-gnu,
and I think that it is fine.
Although the above mail
Hi Mikael,
Am 21.09.22 um 20:56 schrieb Mikael Morin:
Le 21/09/2022 à 11:57, Thomas Koenig a écrit :
Hi Harald,
I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an
0259762271b2eb430e058b0bff4d7b11513c48c4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 21 Sep 2022 19:55:30 +0200
Subject: [PATCH] Fortran: fix ICE in generate_coarray_sym_init [PR82868]
gcc/fortran/ChangeLog:
PR fortran/82868
* trans-decl.cc (generate_coarray_sym_init): Skip symbol
if attr.associate_var
Am 19.09.22 um 22:50 schrieb Mikael Morin:
Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t
tps://gcc.gnu.org/g:5976fbf9d5dd9542fcb82eebb2185886fd52d000
The PR is marked as a 10/11/12/13 regression, thus I plan to
backport.
Thanks,
Harald
From 5976fbf9d5dd9542fcb82eebb2185886fd52d000 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 20 Sep 2022 22:41:48 +0200
Subject: [PATCH] Fort
c092
Thanks,
Harald
From 8dbb15bc2d019488240c1e69d93121b0347ac092 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 20 Sep 2022 22:23:43 +0200
Subject: [PATCH] Fortran: NULL pointer dereference in invalid simplification
[PR106985]
gcc/fortran/ChangeLog:
PR fortran/106985
* exp
Am 20.09.22 um 13:51 schrieb Tobias Burnus:
In several cases, one just wants to have the address where an object starts
without requiring the detour via 'c_loc' and the (locally) required
'target'
attribute.
In principle, type(*),dimension(*) of TS29113 permits this, except that
on that.
Thanks,
Harald
From 0b19cfc098554572279c8d19997df4823b426191 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 19 Sep 2022 22:00:45 +0200
Subject: [PATCH] Fortran: Fix function attributes [PR100132]
gcc/fortran/ChangeLog:
PR fortran/100132
* trans-types.cc (create_fn_spec): Fix function
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t it the converse that is true?
Assumed shape can be non-contiguous so have to be excluded
On 18.09.22 12:23, Thomas Koenig via Gcc-patches wrote:
On 18.09.22 11:10, Mikael Morin wrote:
It is unfortunate as there is some desirable behavior within reach here.
I think some of the desired behavior can still be salvaged. For
example, for
subroutine foo(a,n)
integer :: n
.
Committed to mainline after regtesting on x86_64-pc-linux-gnu
as commit r13-2691-g2b75d5f533b9d6b39f4055949aff64ed0d22dd24
This is a 10/11/12/13 regression, so I will check if it can
be backported.
Thanks,
Harald
From 2b75d5f533b9d6b39f4055949aff64ed0d22dd24 Mon Sep 17 00:00:00 2001
From: Harald
and pushed to mainline as
commit r13-2690-g7bd4deb2a7c1394550610ab27507d1ed2af817c2
Thanks,
Harald
From 7bd4deb2a7c1394550610ab27507d1ed2af817c2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 15 Sep 2022 22:06:53 +0200
Subject: [PATCH] Fortran: error recovery for bad deferred character length
Dear all,
said PR was addressed by Jose in
https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html
but unfortunately his patch was never reviewed.
IMHO the patch is mostly fine, with one small exception that
it should use POINTER_TYPE_P (TREE_TYPE (tmp)), see PR and
attached adjusted
Dear all,
Jose posted a small patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html
IMHO the patch is fine and nearly obvious.
I inquired in the PR, and Jose did not object to my handling of
his patch. So - unless there are objections - I will
b6aa7d45b502c01f8703c8d2cee2690f9aa8e282 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 2 Sep 2022 21:07:26 +0200
Subject: [PATCH] Fortran: avoid NULL pointer dereference on invalid DATA
constant [PR99349]
gcc/fortran/ChangeLog:
PR fortran/99349
* decl.cc (match_data_constant): Avoid NULL pointer
Hi Tobias,
this is not really a review, but:
Am 26.08.22 um 20:21 schrieb Tobias Burnus:
I did run into some issues related to this; those turned out to be
unrelated, but I end ended up implementing this feature.
Side remark: 'omp parallel workshare' seems to actually permit 'nowait'
now, but
Hi Tobias,
Am 24.08.22 um 19:47 schrieb Tobias Burnus:
This patch is about error diagnostic + an ICE for invalid code.
[...]
(So far, so good, but then the parsing-code did run into a bug.)
For the blocks, the following applies. OpenMP permits either
* strictly structured blocks (with
-pc-linux-gnu.
The PR is marked as a 12/13 regression. Will therefore
commit to both.
Thanks,
Harald
From d306c0b171e502e3c87b92b6bc63b532f734e754 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 23 Aug 2022 22:16:14 +0200
Subject: [PATCH] Fortran: improve error recovery while
OK for mainline?
Thanks,
Harald
From a540a806cf02d739a408f129738252e73f03e60c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 20 Aug 2022 20:36:28 +0200
Subject: [PATCH] Fortran: fix simplification of intrinsics IBCLR and IBSET
[PR106557]
gcc/fortran/ChangeLog:
PR fortran/10655
for interpretation of
compile-time restrictions on ASSOCIATED
Date : Thu, 4 Aug 2022 11:43:16 +0900
De : Malcolm Cohen
Pour : 'Mikael Morin' , sc22...@open-std.org
Copie à : 'Harald Anlauf'
Dear Mikael,
Thank you for your query.
I would agree with Steve Lionel that the ranks must be the same (when
POINTER
301 - 400 of 873 matches
Mail list logo
