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
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
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
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 th
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
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
dif
Sep 17 00: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
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" if
.
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
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/fo
-hanging fruits.
There are also far more than 100 TODOs in gcc/fortran/*.cc ...
And with the usual PRs, there's enough work left for all kinds
of contributions.
Cheers,
Harald
Paul
On Mon, 21 Aug 2023 at 20:48, Harald Anlauf via Fortran
wrote:
Dear all,
the attached patch implements v
arald
From 829c0c06fe7ba2cf3e83508b95999b884b21236d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 23 Aug 2023 21:08:01 +0200
Subject: [PATCH] Fortran: improve diagnostic message for COMMON with automatic
object [PR32986]
gcc/fortran/ChangeLog:
PR fortran/32986
* resol
here). We now get a warning with -std=gnu, and an
error with -std=f.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
(The PR is over 15 years old, so no backport intended... ;-)
Thanks,
Harald
From 420804e7399dbc307a80f084cfb840444b8ebfe7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Hi Mikael,
On 8/27/23 21:22, Mikael Morin via Gcc-patches wrote:
Hello,
this fixes an old error-recovery bug.
Tested on x86_64-pc-linux-gnu.
OK for master?
I have only a minor comment:
+/* Free the leading members of the gfc_interface linked list given in INTR
+ up to the END element (ex
x-gnu. OK for mainline?
Thanks,
Harald
From 944a35909e8eeb79c92e398ae3f27e94708584e6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 31 Aug 2023 22:19:58 +0200
Subject: [PATCH] Fortran: runtime bounds-checking in presence of array
constructors [PR31059]
gcc/fortran/ChangeLog:
PR fo
Hi Mikael,
On 9/1/23 10:41, Mikael Morin via Gcc-patches wrote:
Le 31/08/2023 à 22:42, Harald Anlauf via Fortran a écrit :
Dear all,
gfortran's array bounds-checking code does a mostly reasonable
job for array sections in expressions and assignments, but
forgot the case that (r
Am 08.09.23 um 12:04 schrieb Mikael Morin via Gcc-patches:
Hello,
this avoids some redundant work in the symbol deletion code, which is
used a lot by the parser to cancel statements that fail to match in the
end.
I haven't tried to measure the performance effect, if any, on a pathological
examp
Hi Mikael,
On 9/11/23 14:38, Mikael Morin via Gcc-patches wrote:
Hello,
this fixes a memory management issue in the fortran frontend.
I have included the (reduced) testcase from the PR, even if it wasn't failing
here on x86_64 with the test harness.
Tested on x86_64-pc-linux-gnu and manually ch
more similar cases.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From bb2a765f56b440c8d086329f55c8ff0eaee2b97d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 14 Sep 2023 22:08:26 +0200
Subject: [PATCH] Fortran: improve bounds-checking for array sections [PR30802
over from playing, since I thought
the outlined function could be used more than once.
I've removed those lines before pushing.
Thanks for the review!
Harald
Apart from that, it looks good to me. OK for mainline.
Thanks for the patch.
Paul
On Thu, 14 Sept 2023 at 21:22, Harald Anlauf vi
9d8133 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 18 Sep 2023 22:11:40 +0200
Subject: [PATCH] fortran: fix checking of CHARACTER lengths in array
constructors [PR70231]
gcc/fortran/ChangeLog:
PR fortran/70231
* trans-array.cc (trans_array_constructor): In absence of a typespec,
ICE on valid code.
Original patch by Steve, slightly adjusted and regtested on x86_64-pc-linux-gnu.
OK for master? Backports? Should be safe everywhere, as it replaces an assert
by an if condition.
Thanks,
Harald
PR fortran/95372 - ICE in find_array_section, at fortran/expr.c:1687
Fix handl
Dear all,
ICE-on-invalid: testcase by Arseny, draft patch by Steve,
slightly polished and regtested by me on x86_64-pc-linux-gnu.
OK for master?
Thanks,
Harald
PR fortran/98284 - ICE in get_array_index
Reject DATA elements with the ALLOCATABLE attribute also when they are
components of a deri
Dear all,
since the introduction of check_forall_dependencies() we mishandled the
dependencies of ALLOCATABLE components of derived types, while POINTER
was dealt with. Fix that.
Regtested on x86_64-pc-linux-gnu.
OK for master? Since we generate wrong code under the given circumstances,
what d
Dear all,
the patch is almost self-explaining. We mishandled the case of initializing
pointer components to derived types of type CHARACTER via DATA, which screwed
up both legal and illegal uses. The attached patch fixes that, and checks
that the legal cases work.
Regtests cleanly on x86_64-pc-
Dear all,
happy New Year!
The testcase committed with the fix for PR93337 uncovered a latent issue
with an invalid read that was discovered with an ASAN instrumented compiler
but which could also be verified by running f951 under valgrind.
According to my gdb sessions the invalid read happens wh
Dear all,
the PR contains a lengthy discussion of several testcases, some which were
considered invalid and thus removed from the testsuite (charlen_03.f90,
charlen_10.f90), charlen_15.f90 was resolved elsewhere, so that only
class_61.f90 was left with an invalid access after error recovery with
a
Dear all,
when playing around with the issues exposed by PR93340, particularly visible
in the tree dump, I tried to find ways to simplify substrings in those cases
where they are eligible as designator, which is required e.g. in DATA
statements.
Given my limited understanding, I finally arrived
Dear all,
the former Fortran testcase charlen_03.f90, which some time ago used to
ICE, could still display issues during error recovery. As Dominique
pointed out, this required either an instrumented compiler, or valgrind.
The issue turned out to not have anything to do with CHARACTER, but
with
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, it is in the
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 adjustmen
tch so that your 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:
From 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
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
-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
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(-)
-
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 @@ compare_com
, 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
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
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
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
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 ok
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
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
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
).
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
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
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
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 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
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 == ' ' \
0
2-line/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
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 defau
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 t
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
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 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 t
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
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
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
nu and pushed 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 2
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
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:
https://gcc.gnu.org/g:9fb9da3d38513d320bfea72050f7a59688595e
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 that it is not
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
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
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 exp
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
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. T
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 embarrassin
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 of
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
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 C
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
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:
&
ifferent causes of
failure.
The testcase should be able to handle 32 and 64 bit systems.
At least that's what I think.
Regtested on x86_64-pc-linux-gnu. OK for mainline? Suggestions?
Thanks,
Harald
From 19ccd22ee9359bd14b32a95bd9efcaead3593b2f Mon Sep 17 00:00:00 2001
From: Harald Anlau
Hi Tobias,
Am 30.05.22 um 09:33 schrieb Tobias Burnus:
On 28.05.22 22:25, Harald Anlauf via Fortran wrote:
the PR rightfully complained that we did not differentiate errors on
ALLOCATE(...,stat=,errmsg=) for failures from allocation of already
allocated objects or insufficient virtual memory
32c95012378ada5ce555a819dbc640e1dd2b88d5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 15 Jun 2022 22:20:09 +0200
Subject: [PATCH] Fortran: check POS and LEN arguments simplifying bit
intrinsics [PR105986]
gcc/fortran/ChangeLog:
PR fortran/105986
* simplify.cc (gfc_simplify_btest): Add check for
x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 65f7fd793415cb291ffb5bca8cdbcb10fc511ab8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 20 Jun 2022 20:59:55 +0200
Subject: [PATCH] Fortran: handle explicit-shape specs with constant bounds
[PR105954]
gcc/fortran/ChangeLog:
2cfe8034340424ffa15784c61584634ccac4c4fc Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 21 Jun 2022 23:20:18 +0200
Subject: [PATCH] Fortran: fix simplification of INDEX(str1,str2) [PR105691]
gcc/fortran/ChangeLog:
PR fortran/105691
* simplify.cc (gfc_simplify_index): Replace old simplification
code
Hi Jakub,
Am 23.06.22 um 14:04 schrieb Jakub Jelinek via Gcc-patches:
Hi!
As mentioned by Joseph in PR105101, glibc 2.26 or later has on x86
(both -m32/-m64), powerpc64le, ia64 and mips support for
*f128 math/complex APIs plus strtof128 and strfromf128, and these APIs allow
us to avoid libquadm
f21f17f95c0237f4f987a5fa9f1fa9c7e0db3c40 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 24 Jun 2022 22:21:39 +0200
Subject: [PATCH] Fortran: fix checking of arguments to UNPACK when MASK is a
variable [PR105813]
gcc/fortran/ChangeLog:
PR fortran/105813
* check.cc (gfc_check_unpack): Try
Hi Jakub,
Am 24.06.22 um 12:29 schrieb Jakub Jelinek via Gcc-patches:
On Thu, Jun 23, 2022 at 11:17:50PM +0200, Jakub Jelinek via Gcc-patches wrote:
We currently use
%rename lib liborig
*lib: %{static-libgfortran:--as-needed} -lquadmath
%{static-libgfortran:--no-as-needed} -lm %(libgcc) %(libo
-pc-linux-gnu.
Will commit to mainline as obvious within 24 hours unless
there are loud objections.
Thanks,
Harald
From 55aacfd22d73edfb38871e211f85b2ae69fd0072 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 28 Jun 2022 22:29:28 +0200
Subject: [PATCH] Fortran: improve error recovery for
far as it seems appropriate.
Thanks,
Harald
From e0d5aeadd218f21e450db6601956691293210156 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 29 Jun 2022 21:36:17 +0200
Subject: [PATCH] Fortran: error recovery on invalid CLASS(), PARAMETER
declarations [PR105243]
gcc/fortran/ChangeLog:
PR
Dear all,
character variables with undefined length are not allowed as
objects in DATA statements. We better reject them.
Regtested on x86_64-pc-linux-gnu. OK for master / backport?
Thanks,
Harald
PR fortran/99205 - Out of memory with undefined character length
A variable that is a data sta
Dear Tobias,
thanks for your comments.
> > A variable that is a data statement object shall be a designator,
> > thus a character variable shall have a constant length.
>
> This comment is wrong: A designator does not imply this – nor is
> F2018:C875 violated, not even the substring starting/end
Dear Tobias, all,
> The reason that it is not permitted is the "automatic data object"
> (see *...* highlighted parts in the quote):
>
> C876 (R839) A *variable* whose *designator* appears as a
> *data-stmt-object* or a data-i-do-object hall not be a
> dummy argument, accessed by use or host ass
Dear all,
the addition of runtime checks for the SIZE intrinsic created a regression
that showed up for certain CLASS arguments to procedures. Paul did most of
the work (~ 99%), but asked me to dig into an issue with an inappropriately
selected error message. This actually turned out to be a sim
n the commit logs, but it is used in the
> testcases for the change-log generator, see:
> contrib/gcc-changelog/test_patches.txt
I've done it as described above. In the git log I see the co-author, while
> git show -1 | ./contrib/gcc-changelog/git_check_commit.py -p
produces:
Che
Hi Tobias,
> Shouldn't there be also a testcase which triggers this run-time error?
The testcase is there, it simply has the wrong dg-foo:
! { dg-do compile }
which should be
! { dg-do run }
*-*-*
There are certainly more cases which should insert checks but currently don't,
like:
subrouti
Dear all,
the simplification of the TRANSPOSE of a zero-sized array would lead to
an ICE if the result was used in a subsequent simplification of a MATMUL.
The reason was the lack of the proper initialization of the shape, which
is mpz_t. Use mpz_init_set instead of mpz_set.
Regtested on x86_64-
Hello everybody,
we currently write the interface for intrinsic procedures to module
files although that should not be necessary. (F2018:15.4.2.1 actually
states that interfaces e.g. of intrinsic procedures are 'explicit'.)
This lead to bogus errors due to an apparently bogus ambiguity.
A simple
Hi Paul, all,
having really enjoyed the review process, I've now committed Paul's version
including his comment. See also attached.
Thanks,
Harald
Gesendet: Freitag, 16. April 2021 um 13:02 Uhr
Von: "Paul Richard Thomas"
An: "Bernhard Reutner-Fischer"
Dear Fortranners,
while analyzing a different PR (PR100154), Tobias pointed out that the
target of a pointer from the evaluation of function-reference is allowed
to be used in a variable definition context and thus as an actual
argument to a function or subroutine.
This seems to be a more general
Dear Fortranners,
we need to check the arguments to the affected GNU intrinsic extensions
properly, and - as pointed out in the PR by Tobias - we need to allow
function references that have a data pointer result. Also the argument
names of the character arguments of the subroutine versions needed
Now with the correct patch attached ...
Sorry for the confusion!
---
Dear Fortranners,
we need to check the arguments to the affected GNU intrinsic extensions
properly, and - as pointed out in the PR by Tobias - we need to allow
function references that have a data pointer result. Also the arg
Hi Paul,
> Is there a test for an error with -std=f2003? If not, you should, perhaps,
> include one.
after checking for the corresponding error message, I found that
ptr-func-2.f90 already covers this case. Considering this, I'll
rename the current testcase from pr100218.f90 to ptr-func-4.f90.
A recent change to the checking of legacy FORMAT tags did not handle
cases where the type is not set. Adjust the check.
Regtested on x86_64-pc-linux-gnu.
OK for mainline / 11- / 10-branch?
Thanks,
Harald
Fortran: reject FORMAT tag of unknown type.
gcc/fortran/ChangeLog:
PR fortran/1
As confirmed in the PR by Jakub, there was a bad conversion of the result
of min0/max0 to the result type. We should just unconditionally convert
in all cases.
As a benefit, this also fixes pr100283.
Committed after regtesting.
Thanks,
Harald
Fortran - fix conversion to result type for the min
901 - 1000 of 1074 matches
Mail list logo
