there are objections or
other comments.
Thanks,
Harald
From 70385de214fe4de289c56e7f4e06a4b252414379 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 20 Dec 2021 22:01:05 +0100
Subject: [PATCH] Fortran: CASE selector expressions must be scalar
gcc/fortran/ChangeLog:
PR fortran/103776
* match.c
Dear all,
committed as obvious after discussion with Steve: SIZEOF() cannot
accept a BOZ argument which has no defined type.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
From fd74a2ee40456a1d1621e88738f8e57536194080 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 18 Dec 2021 23:21
Hi FX,
Am 16.12.21 um 15:17 schrieb FX via Fortran:
Hi,
DATE_AND_TIME can return incorrect values for non-UTC timezones, near the new
year, when the local time and UTC time are in different years.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
Attached patch fixes the issue by
Hi FX,
we now use "STOP n" instead of "call abort" in testcases.
OK with this change.
Am 16.12.21 um 17:34 schrieb FX via Fortran:
With correct patch attached, sorry.
Hi,
Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255
Hi FX,
Am 16.12.21 um 15:49 schrieb FX via Fortran:
Hi,
Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255
Trivial fix, adding a testcase.
it seems you attached the wrong patch (the one for pr985079).
Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to
7 00:00:00 2001
From: Harald Anlauf
Date: Tue, 14 Dec 2021 21:57:04 +0100
Subject: [PATCH] Fortran: prevent NULL pointer dereference in check of passed
do-loop variable
gcc/fortran/ChangeLog:
PR fortran/103717
* frontend-passes.c (doloop_code): Prevent NULL pointer
dereference when checking f
:00 2001
From: Harald Anlauf
Date: Tue, 14 Dec 2021 21:02:04 +0100
Subject: [PATCH] Fortran: prevent NULL pointer dereferences checking do-loop
contained stuff
gcc/fortran/ChangeLog:
PR fortran/103718
PR fortran/103719
* frontend-passes.c (doloop_contained_procedure_code): Add several
checks
Works better with patch attached...
Am 13.12.21 um 21:25 schrieb Harald Anlauf via Gcc-patches:
Hi Mikael,
Am 09.12.21 um 21:37 schrieb Mikael Morin:
Hello,
On 09/12/2021 21:05, Harald Anlauf via Fortran wrote:
Dear all,
I had thought that we had fixed this in the past (see PR31001
Hi Mikael,
Am 09.12.21 um 21:37 schrieb Mikael Morin:
Hello,
On 09/12/2021 21:05, Harald Anlauf via Fortran wrote:
Dear all,
I had thought that we had fixed this in the past (see PR31001),
but it did fail for me with all gcc versions I have tried (7-12)
for a slightly more elaborate case
,
Harald
From 6e41e4391a54337bd32560be2b72e11ceba37b3a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 10 Dec 2021 22:41:24 +0100
Subject: [PATCH] Fortran: fix checking of elemental functions of type CLASS
gcc/fortran/ChangeLog:
PR fortran/103606
* resolve.c (resolve_fl_procedure): Do
Hi Mikael,
Am 08.12.21 um 10:32 schrieb Mikael Morin:
On 07/12/2021 21:46, Harald Anlauf wrote:
Hi Mikael,
Am 07.12.21 um 21:17 schrieb Mikael Morin:
The existing code looks dubious to me (or at least difficult to
understand), and your patch doesn’t make that any better.
I would rather try
this, if there are no objections.
Thanks,
Harald
From dfa1e1ac5d8e43f1ca8f13b64330825581174f36 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 9 Dec 2021 20:55:08 +0100
Subject: [PATCH] Fortran: PACK intrinsic should not try to read from
zero-sized array
libgfortran/ChangeLog:
PR
:
PR fortran/103609
* gfortran.dg/pr103609.f90: New test.
Thanks,
Harald
From b77968a70537429b4f548f90c369d26e6b6943cc Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 8 Dec 2021 21:14:19 +0100
Subject: [PATCH] Fortran: avoid NULL pointer dereference on missing
rald
From f8d6aae66b1cb3f75b47d50695ef1be7770abc30 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 7 Dec 2021 23:06:41 +0100
Subject: [PATCH] Fortran: dimensions of an array have to be non-negative
gcc/fortran/ChangeLog:
PR fortran/103610
* array.c (spec_dimen_size): Fix simplification of SHAPE:
dimensions must be no
Hi Mikael,
Am 07.12.21 um 21:17 schrieb Mikael Morin:
Hello,
On 05/12/2021 22:55, Harald Anlauf via Fortran wrote:
Dear all,
the check of dummy arguments with pointer attribute and INTENT(IN)
was broken in the case the argument was passed to an intrinsic.
We therefore rejected valid code
4ee6ec6681b76372d10d4e9e82ea037628b8b21b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 7 Dec 2021 21:34:31 +0100
Subject: [PATCH] Fortran: perform array subscript checks only for valid
INTEGER bounds
gcc/fortran/ChangeLog:
PR fortran/103607
* frontend-passes.c (do_subscript): Ensure that array
From 1487d327b13b45acca79c0c691a748ca1a50bc04 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 6 Dec 2021 23:34:17 +0100
Subject: [PATCH] Fortran: catch failed simplification of bad stride
expression
gcc/fortran/ChangeLog:
PR fortran/103588
* array.c (gfc_ref_dimen_size): Do not generate
Dear all,
we didn't check the type of the upper bound in a case range.
Bummer. Simply add a corresponding check.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b4e7aeae4f6c59d8fe950d7981832e3f9c6a8f0e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 6 Dec 2021
for MOVE_ALLOC.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As this is a rejects-valid and possibly annoying, I would like to
backport as far seems reasonable.
Thanks,
Harald
From fa07ada75a5ea25845d7e168204cd980263a7d8d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 5 Dec 2021 22:45
. This allows discovery of
arithmetic errors also at later stages and will be used here.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 27f981bd1e9611373e4565c1d350b1da3eb653f0 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 2 Dec 2021 22:33:49 +0100
Subject: [PATCH
Hi Tobias,
Am 30.11.21 um 18:24 schrieb Tobias Burnus:
On 29.11.21 22:11, Harald Anlauf wrote:
"A whole array is a named array or a structure component whose final
part-ref is an array component name; no subscript list is appended."
I think in "h(3)" there is not really
Hi Mikael,
Am 30.11.21 um 12:25 schrieb Mikael Morin:
Hello,
Le 29/11/2021 à 22:31, Harald Anlauf via Fortran a écrit :
Dear all,
a trivial one: we need to check the type of the SUB argument
to the coarray IMAGE_INDEX intrinsic. It has to be an array
of type integer.
Patch by Steve Kargl
6bdecd3805eb0d55722992ccb517d08b9bafe605 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 29 Nov 2021 22:56:30 +0100
Subject: [PATCH] Fortran: error recovery when simplifying MINLOC/MAXLOC
gcc/fortran/ChangeLog:
PR fortran/103473
* simplify.c (simplify_minmaxloc_nodim): Avoid NULL pointer
dereference when shape
17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 29 Nov 2021 22:23:02 +0100
Subject: [PATCH] Fortran: check type of SUB argument to IMAGE_INDEX
gcc/fortran/ChangeLog:
PR fortran/101565
* check.c (gfc_check_image_index): Verify that SUB argument to
IMAGE_INDEX is of type integer.
gcc/testsuite
Hi Tobias, all,
Am 29.11.21 um 21:56 schrieb Tobias Burnus:
The problem is that the standard does not really state what the bounds
are :-(
I sort of expected that comment...
Usually, it ends up referring to LBOUND (with wordings like "each lower
bound equal to the corresponding element of
Hi Chung-Lin,
Am 29.11.21 um 15:25 schrieb Chung-Lin Tang:
This patch by Tobias, fixes a case of setting array low-bounds, found
for particular uses of SOURCE=/MOLD=.
For example:
program A_M
implicit none
real, dimension (:), allocatable :: A, B
allocate (A(0:5))
call Init (A)
Am 29.11.21 um 12:28 schrieb Richard Biener via Fortran:
This fixes an appearant mistake in gfc_insert_parameter_exprs.
Yes, that looks pretty much like a missed cleanup and fix during
development. CC'ing Paul.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
OK?
LGTM if it
as in these PRs, the incomplete expansion
led to an unnecessary creation of array temporaries. This is
improved by the attached patch.
Regtested on x86_64-pc-linux-gnu.
OK for mainline?
Thanks,
Harald
From 6aced0b26e54cea48cca36637f3616054391864b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 27
Hi Mikael,
> Gesendet: Freitag, 26. November 2021 um 15:45 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf" , fort...@gcc.gnu.org
> Cc: gcc-patches@gcc.gnu.org
> Betreff: Re: [PATCH, v2] PR fortran/103411 - ICE in
> gfc_conv_array_initializer, at fortran/tra
Hi Mikael,
Am 25.11.21 um 22:02 schrieb Mikael Morin:
Le 25/11/2021 à 21:03, Harald Anlauf a écrit :
Hi Mikael,
Am 25.11.21 um 17:46 schrieb Mikael Morin:
Hello,
Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index
Hi Mikael,
Am 25.11.21 um 17:46 schrieb Mikael Morin:
Hello,
Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 5a5aca10ebe..837eb0912c0 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -4866,10 +4868,17
on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From d6af2a33bad852bcea39b8c5b2e7c27976bde2a1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 24 Nov 2021 22:22:24 +0100
Subject: [PATCH] Fortran: improve check of arguments to the RESHAPE intrinsic
gcc/fortran/ChangeLog:
PR
82c5d7ab299ad4bce98b53cc9bba223c29b34e66 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 23 Nov 2021 21:39:36 +0100
Subject: [PATCH] Fortran: do not attempt simplification of [LU]BOUND for
pointer/allocatable
gcc/fortran/ChangeLog:
PR fortran/103392
* simplify.c (simplify_bound): Do
Am 21.11.21 um 12:46 schrieb Mikael Morin:
Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
scalariziation of the elemental intrinsic LEN_TRIM was ICEing
when the optional KIND argument was present.
The cleanest solution is to use the infrastructure added
Let's have a look at the tree-dump of the existing testcase:
integer(kind=4) runtime_poppar (integer(kind=16) & restrict i)
{
integer(kind=4) res;
{
uint128_t D.4221;
D.4221 = (uint128_t) *i;
res = __builtin_parityll ((unsigned long) D.4221 ^ (unsigned long)
(D.4221 >> 64));
Early ping.
Am 15.11.21 um 22:38 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
the attached patch fixes the handling of the DEC trigonometric intrinsics
for different argument kinds. It is based on the original patch by Steve,
which fixes the lookup for the needed intrinsics
-branch only, though.
My suggestion is to fix the current PR only for the same branches,
leaving the regression unfixed for older ones.
Regtested on x86_64-pc-linux-gnu. OK for mainline and 11-branch?
Thanks,
Harald
From f700c43fef4a239af25dd30dc22930b1bb1dbe95 Mon Sep 17 00:00:00 2001
From: Harald
7 00:00:00 2001
From: Harald Anlauf
Date: Wed, 17 Nov 2021 22:21:24 +0100
Subject: [PATCH] Fortran: NULL() is not interoperable
gcc/fortran/ChangeLog:
PR fortran/101329
* check.c (is_c_interoperable): Reject NULL() as it is not
interoperable.
gcc/testsuite/ChangeLog:
PR fortran/101329
* g
Do you have testcases/reproducers demonstrating that the patch actually
fixes the issues you're describing?
Am 17.11.21 um 09:12 schrieb Bernhard Reutner-Fischer via Gcc-patches:
On Tue, 16 Nov 2021 21:46:32 +0100
Harald Anlauf via Fortran wrote:
Hi Bernhard,
I'm trying to understand your
From: Harald Anlauf
Date: Tue, 16 Nov 2021 21:06:06 +0100
Subject: [PATCH] Fortran: avoid NULL pointer dereference on invalid range in
logical SELECT CASE
gcc/fortran/ChangeLog:
PR fortran/103286
* resolve.c (resolve_select): Choose appropriate range limit to
avoid NULL pointer dereference
From e979db00b8e84333c53bc0b8f1c89cd8ce18d72c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 15 Nov 2021 22:32:17 +0100
Subject: [PATCH] Fortran: fix lookup for gfortran builtin math intrinsics used
by DEC extensions
gcc/fortran/ChangeLog:
PR fortran/99061
* trans-intrinsic.c
Hi Bernhard,
Am 12.11.21 um 21:18 schrieb Bernhard Reutner-Fischer via Fortran:
On Fri, 12 Nov 2021 18:39:48 +0100
Harald Anlauf via Fortran wrote:
Sounds plausible.
this is what I thought, too. And nvfortran and flang accept the
testcase, as well as crayftn (cce/12.0.2).
Intel accepts
1fc44a5bf0b294021490f3c0a1539982a09000f5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 12 Nov 2021 18:32:18 +0100
Subject: [PATCH] Fortran: fix interoperability check for character variables
for F2008
gcc/fortran/ChangeLog:
PR fortran/102368
* check.c (is_c_interoperable): F2008
Hi Thomas,
> > I'd like to commit the attached patch as obvious within the next 24 hours
> > unless anybody objects, or earlier if there is positive feedback.
>
> OK with a ChangeLog entry and the correct PR numbers (I believe
> they are 103137 and 103138) :-)
I think I had really fat fingers
, or they are closed and the remaining issues moved to a new PR.
Regtested on x86_64-pc-linux-gnu. Comments welcome.
Thanks,
Harald
From a40cbf2b28db7824740ff1cff3eaffcd768fe456 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 9 Nov 2021 21:02:44 +0100
Subject: [PATCH] Fortran: avoid NULL
Hi Mikael,
thanks for working on this!
Am 07.11.21 um 17:17 schrieb Mikael Morin via Gcc-patches:
Hello,
I repost this patch series initially targetted at the 11 branch only [1],
and that I now would like to commit to master as well before.
The problematic case is intrinsic procedures where
Hi Thomas,
Am 07.11.21 um 19:18 schrieb Thomas Koenig via Fortran:
Hello world,
the attached patches fix the name of the function argument to CO_REDUCE
to conform to Fortran 2018 instead of the TR.
This is a user-visible change, so I have put this both into changes.html
and porting_to.html.
Hi Bernhard,
I cannot comment on the gcc/ parts, but
Am 05.11.21 um 22:17 schrieb Bernhard Reutner-Fischer via Gcc-patches:
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/68800
* cpp.h (gfc_cpp_free_cpp_dirs): New declaration.
* cpp.c
Hi Mikael,
Am 05.11.21 um 22:28 schrieb Mikael Morin:
Le 01/11/2021 à 22:39, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
a recent patch uncovered a latent issue with simplification of
array-valued expressions where the resulting shape was not set
from the referenced subobject. Once
Early ping.
Am 31.10.21 um 22:35 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
the fix for initialization of DT arrays caused an apparent regression for
cases where inconsistent ranks were used in such an initialization.
This caused either an ICE in subsequent uses of these arrays
Hi Bernhard,
Am 04.11.21 um 10:06 schrieb Bernhard Reutner-Fischer via Fortran:
On Wed, 3 Nov 2021 21:00:41 +0100
Harald Anlauf via Fortran wrote:
*PING*
Am 27.10.21 um 21:09 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
when debugging the testcase, I noticed that a coarray
*PING*
Am 27.10.21 um 21:09 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
when debugging the testcase, I noticed that a coarray declaration in
a COMMON statement wrongly set the dimension attribute instead of the
codimension. As a consequence, subsequent checks that catch this
invalid
Dear Fortranners,
a recent patch uncovered a latent issue with simplification of
array-valued expressions where the resulting shape was not set
from the referenced subobject. Once found, the fix looks obvious.
Regtested on x86_64-pc-linux-gnu. OK?
Thanks,
Harald
Fortran: fix simplification
b1b5e5da928accfe02a7289a331cbea815255a16
Author: Harald Anlauf
Date: Sun Oct 31 22:20:01 2021 +0100
Fortran: error recovery on rank mismatch of array and its initializer
gcc/fortran/ChangeLog:
PR fortran/102715
* decl.c (add_init_expr_to_sym): Reject rank mismatch between
Committed as r12-4808 after checking "make dvi".
Thanks for the patch!
Harald
Am 30.10.21 um 01:16 schrieb Manfred Schwarb via Gcc-patches:
Am 29.10.21 um 21:52 schrieb Harald Anlauf via Fortran:
Hi Manfred,
Am 29.10.21 um 16:13 schrieb Manfred Schwarb via Gcc-patches:
Hi,
on
Committed as r12-4807.
Thanks for the patch!
Harald
Am 30.10.21 um 01:15 schrieb Manfred Schwarb via Gcc-patches:
Am 29.10.21 um 21:51 schrieb Harald Anlauf via Fortran:
Hi Manfred,
Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran:
Hi,
on 2019-07-23, support for SHORT and LONG
Committed as r12-4806.
Thanks for the patch!
Harald
Am 30.10.21 um 01:17 schrieb Manfred Schwarb via Fortran:
Am 29.10.21 um 21:56 schrieb Harald Anlauf via Fortran:
Hi Manfred,
Am 29.10.21 um 16:18 schrieb Manfred Schwarb via Gcc-patches:
Hi,
documentation for REAL intrinsic is slightly
Committed as r12-4805.
Thanks for the patch!
Harald
Am 30.10.21 um 01:14 schrieb Manfred Schwarb via Fortran:
Am 29.10.21 um 21:44 schrieb Harald Anlauf via Fortran:
Hi Manfred,
Am 29.10.21 um 16:05 schrieb Manfred Schwarb via Fortran:
Hi,
in intrinsic.texi, a lot of tables wrap lines
Committed as simple and obvious as r12-4803.
Harald
Am 30.10.21 um 01:18 schrieb Manfred Schwarb via Fortran:
Am 29.10.21 um 21:58 schrieb Harald Anlauf via Fortran:
Hi Manfred,
Am 29.10.21 um 16:33 schrieb Manfred Schwarb via Fortran:
Hi,
there were really a lot of test cases provided
Committed as simple and obvious after discussion in PR.
Harald
Am 28.10.21 um 23:03 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
the original fix by Steve was lingering in the PR.
We did ICE in situations where in a SELECT CASE a kind conversion
was deemed necessary, but it did
Hi Manfred,
Am 29.10.21 um 16:18 schrieb Manfred Schwarb via Gcc-patches:
Hi,
documentation for REAL intrinsic is slightly wrong. Fix it.
Patch is done on top of the column adjustment patch.
the patch looks fine, but it would help a lot to have a ChangeLog entry.
Thanks,
Harald
Hi Manfred,
Am 29.10.21 um 16:33 schrieb Manfred Schwarb via Fortran:
Hi,
there were really a lot of test cases provided by Gerhard Steinmetz lately.
Although I'm not really in the position to suggest this,
I would appreciate it, if one could recognize him by adding an entry to
gfortran.texi.
Hi Manfred,
Am 29.10.21 um 16:13 schrieb Manfred Schwarb via Gcc-patches:
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics was removed be Steve Kargl
by
adding an error message in check.c. As far as I can see code support is still
there, though.
Remove documentation for these
Hi Manfred,
Am 29.10.21 um 16:12 schrieb Manfred Schwarb via Fortran:
Hi,
on 2019-07-23, support for SHORT and LONG intrinsics were removed be Steve
Kargl by
adding an error message in check.c. However, the error message
Error: 'long' intrinsic subprogram at (1) has been deprecated
is
Hi Manfred,
Am 29.10.21 um 16:05 schrieb Manfred Schwarb via Fortran:
Hi,
in intrinsic.texi, a lot of tables wrap lines when watching the
resulting info file in a 80char terminal.
Adjust the @columnfractions items to fit screen. Some minor white space
changes are added as well to help saving
Dear Bernhard, all,
Am 29.10.21 um 02:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 53c760a6c38..cde34c67482 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -5052,7 +5052,7 @@ gfc_get_typebound_proc
Hi Bernhard,
Am 27.10.21 um 23:43 schrieb Bernhard Reutner-Fischer via Gcc-patches:
ping
[I'll rebase and retest this too since it's been a while.
Ok if it passes?]
On Sun, 21 Oct 2018 16:04:34 +0200
Bernhard Reutner-Fischer wrote:
Hi!
Regtested on x86_64-unknown-linux, installing on
Dear Fortranners,
the original fix by Steve was lingering in the PR.
We did ICE in situations where in a SELECT CASE a kind conversion
was deemed necessary, but it did involve different types.
The check gfc_convert_type_warn () was invoked with arguments
requesting to generate an internal error.
Dear Fortranners,
when debugging the testcase, I noticed that a coarray declaration in
a COMMON statement wrongly set the dimension attribute instead of the
codimension. As a consequence, subsequent checks that catch this
invalid situation would not trigger.
I see two possible solutions:
- in
commit 0ec53a3df536f83ec72ef25b045768c06c363f86
Author: Harald Anlauf
Date: Tue Oct 26 22:22:36 2021 +0200
Fortran: error recovery on invalid code with SELECT TYPE
gcc/testsuite/ChangeLog:
PR fortran/86551
* gfortran.dg/pr86551.f90: New test to verify that PR86551
Dear Fortranners,
we were missing a conflict check for PDT KIND and LEN type parameters:
F2018: 7.5.3.1 Type parameter definition statement
R732 type-param-def-stmt is
integer-type-spec, type-param-attr-spec :: type-param-decl-list
R734 type-param-attr-spec is KIND or LEN
(3) The
Thanks,
Harald
> Tobias
>
> >> Gesendet: Freitag, 22. Oktober 2021 um 22:25 Uhr
> >> Von: "Steve Kargl"
> >> An: "Harald Anlauf"
> >> Cc: fort...@gcc.gnu.org
> >> Betreff: Re: PDT type parameters are not restricted to default in
Hi Tobias,
> In other cases, it requires some careful weighting whether error should
> have the error location "use m" or where the symbol is used. (Here, it
> cannot occur as the module won't get generated and an error is already
> printed at the proper location.)
I had though about this but
Dear Fortranners, Steve,
I've created PR 102917 for tracking this issue and packaged
the attached patch.
Regtested on x86_64-pc-linux-gnu. OK mainline?
Thanks,
Harald
> Gesendet: Freitag, 22. Oktober 2021 um 22:25 Uhr
> Von: "Steve Kargl"
> An: "Harald Anlauf&quo
Hi Tobias, José,
Am 22.10.21 um 15:06 schrieb Tobias Burnus:
https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html
PR100245 - ICE on automatic reallocation.
Still ICEs
TODO: Review patch.
this one works and LGTM.
Thanks for the patch!
Harald
Hi Tobias, José,
Am 22.10.21 um 15:06 schrieb Tobias Burnus:
https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html
PR100136 - ICE, regression, using flag -fcheck=pointer
First testcase has an ICE with -fcheck=pointer
Second testcase has always an ICE + possibly missing func.
TODO:
Hi Tobias,
Am 22.10.21 um 15:06 schrieb Tobias Burnus:
https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html
PR100103 - Automatic reallocation fails inside select rank
Still segfaults at runtime for 'that = a' where the RHS is a parameter
and the LHS an allocatable assumed-rank array
Dear Fortranners,
the recently introduced shape validation for array components
in DT constructors did not properly deal with invalid code
created by ingenious testers.
Obvious solution: replace the gcc_assert by a suitable error message.
Regarding the error message: before the shape
Hi Tobias, all,
> > In developing the patch I encountered a difficulty with testcase
> > dec_structure_6.f90, which uses a DEC extension, namelist "old-style
> > CLIST initializers in STRUCTURE". I could not figure out how to
> > determine the shape of the initializer; it seemed to be always
Dear Fortranners,
the attached patch adds a check for the shape of arrays in derived type
constructors. This brings it in line with other major brands.
Example:
type t
integer :: a(1)
end type
type(t), parameter :: y(2) = t([1,2])
end
This was silently accepted before, but now
Hi Tobias,
Am 13.10.21 um 18:01 schrieb Tobias Burnus:
Dear all,
a minor update [→ v3].
this has become an impressive work.
I searched for XFAIL in Sandra's c-interop/ and found
two remaining true** xfails, now fixed:
- gfortran.dg/c-interop/typecodes-scalar-basic.f90
The conversion of
Dear Fortranners,
another simple and obvious fix: we need to reorder the argument checks
to the SHAPE intrinsic so that invalid KIND arguments can be detected.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As I consider this a safe fix, I'd like to backport to suitable branches.
Thanks,
Dear Fortranners,
when simplifying RESHAPE we hit a gcc_assert for negative entries in the
SHAPE array. Obvious solution: replace gcc_assert by an error message.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As this is a safe fix, I'd like to backport to suitable branches.
Thanks,
Hi Tobias,
Am 01.10.21 um 02:43 schrieb Tobias Burnus:
Hi all,
this patch fixes a bunch of issues with CLASS.
* * *
besides my previous minor remarks I do not have further comments.
I played around a little but did not find any (new) obstacles.
OK for mainline?
OK from my side.
Hi Tobias,
just some random remarks from initially browsing your patch.
- leftover from debugging?
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1c24556c299..8a82e55d1f9 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1,3 +1,4 @@
+#pragma GCC
*Ping*
Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
when initializing parameter arrays from scalars, we did handle only
the case init->expr_type == EXPR_CONSTANT, which misses the case of
derived types. As a consequence the constructor for the r.h.s. was
not
Hi Jerry,
> Gesendet: Samstag, 09. Oktober 2021 um 00:28 Uhr
> Looks all good Harald, OK and thanks for the support!
Thanks for the quick review!
Harald
Dear Fortranners,
F2018:10.1.5.5.1(2) requires the same interpretation of old and new-style
relational operators. We internally distinguish between old and new style,
but try to map appropriately when used.
This mapping was missing when reading a module via
USE module, ONLY: OPERATOR(op)
Hi Tobias,
Am 05.10.21 um 20:03 schrieb Tobias Burnus:
Played around with the warning in the 'omp_lib' module (needs tweaking
as for the current version, no warning is done). Turned out that already
use omp_lib
outputs a warning even when not used.
that must have been a non-trivial
Dear Fortranners,
when initializing parameter arrays from scalars, we did handle only
the case init->expr_type == EXPR_CONSTANT, which misses the case of
derived types. As a consequence the constructor for the r.h.s. was
not set up, which later led to different ICEs.
To solve this I looked at
Hi Tobias,
the corrected attached patch fixes the regression for testcase
default_initialization_3.f90 for me now, and as a bonus matches
the description.
Am 02.10.21 um 21:56 schrieb Tobias Burnus:
Hi Harald,
unfortunately, your email did not arrive at fort...@gcc.gnu.org – nor at
my private
Hi Tobias,
Am 02.10.21 um 20:29 schrieb Tobias Burnus:
On 02.10.21 20:01, Sandra Loosemore wrote:
On 9/29/21 2:53 AM, Tobias Burnus wrote:
There are three issues, this patch solves the first:
* reject-valid issue due to adding the initializer also to a dummy
argument which is in an
[Resending as I did not see it show up in the MLs]
Hi Tobias,
Am 29.09.21 um 10:53 schrieb Tobias Burnus:
Found when looking at F2018:C839 / PR54753.
For INTENT(OUT) the dummy variable (might) also be default initialized
or deallocated. However, with assumed rank, that causes issues, which
Hi Tobias,
Am 29.09.21 um 10:53 schrieb Tobias Burnus:
Found when looking at F2018:C839 / PR54753.
For INTENT(OUT) the dummy variable (might) also be default initialized
or deallocated. However, with assumed rank, that causes issues, which
C839 prevents. In the current GCC implementation,
Dear Fortranners,
I think I have solved the remaining issue in PR 102458 that prevented the
simplification of an expression involving a static initialization and the
evaluation of the SIZE of an automatic array which has provable constant
size. My previous related query to the ML has thus become
Dear Fortranners,
Gerhard's testcase triggers a NULL pointer dereference during the
attempt to expand an invalid constructor. The simple and obvious
solution is to catch that case.
Regtested on x86_64-pc-linux-gnu. OK for all affected branches?
Thanks,
Harald
Fortran: fix error recovery for
Hi Tobias,
let me first reach for my brown bag...
> Otherwise, the quote from F2018 of my previous email applies:
>
> F2018:16.9.109 LBOUND has for "case(i)", i.e. with a 'dim'
> argument the following. The case without 'dim' just iterates
> through case (i) for each dim. Thus:
>
> "If DIM is
Hi Thomas,
Am 27.09.21 um 14:07 schrieb Tobias Burnus:
While playing I stumbled over the fact that when allocating an array
with a dimension that has extent 0, e.g. 4:-5, the lbound gets reset
to 1 and ubound set to 0.
I am not sure, whether I fully understand what you wrote. For:
Hi Thomas,
> > Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> It was actually 10.1.12 :-)
dang, you're right. Steve had it right, and I failed miserably
on copy I should fix the comment.
> OK for trunk.
>
> Thanks for the patch!
Thanks for the review, which came after Jerry's!
I
Dear Fortranners,
we missed certain intrinsics as being disallowed in constant expressions,
which lead to an ICE when these intrinsics were used in a specification
expression with an initializer. The intrinsics in question are listed in
F2018:10.1.2.
As discussed in the PR, Steve recommended to
501 - 600 of 869 matches
Mail list logo
