Hi Mikael,
Am 31.07.22 um 10:35 schrieb Mikael Morin:
Le 30/07/2022 à 21:40, Harald Anlauf a écrit :
Hi Mikael,
Am 30.07.22 um 10:28 schrieb Mikael Morin:
Meh! We killed one check for gfc_current_form but the other one is still
there.
OK, match_kind_param calls two functions that also gobble
cb33d1d0b91b371a864379d920ddaefc15d587f9 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 28 Jul 2022 22:07:02 +0200
Subject: [PATCH] Fortran: detect blanks within literal constants in free-form
mode [PR92805]
gcc/fortran/ChangeLog:
PR fortran/92805
* match.cc (gfc_match_small_literal_int): Make gobbling
Hi Thomas,
Am 30.07.22 um 09:46 schrieb Thomas Koenig via Fortran:
Hi Harald,
This introduces the helper function gfc_match_next_char, which is
your second option.
I would be a little bit concerned about compilation times
with the additional function call overhead.
the function it
a different one.
how about the attached?
This introduces the helper function gfc_match_next_char, which is
your second option.
Thanks,
Harald
From 0a95d103e4855fbcc20fd24d44b97b690d570333 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 28 Jul 2022 22:07:02 +0200
Subject: [PATCH] Fortran
Am 28.07.22 um 22:19 schrieb Mikael Morin:
Hello,
Le 27/07/2022 à 21:45, Harald Anlauf via Fortran a écrit :
ok, I have thought about your comments in the review process,
and played with the Cray compiler. Attached is a refined version
of the patch that now rejects in addition these cases
Hi Mikael,
Am 29.07.22 um 13:11 schrieb Mikael Morin:
Hello,
Le 28/07/2022 à 22:11, Harald Anlauf via Fortran a écrit :
Dear all,
in free-form mode, blanks are significant, so they cannot appear
in literal constants, especially not before or after the "_" that
separates t
he parsing of string literals.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From f58c00f5792d6ec0037696df733857580a029ba9 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 28 Jul 2022 22:07:02 +0200
Subject: [PATCH] Fortran: detect blanks within literal constants in free-
Hi Mikael,
Am 26.07.22 um 21:25 schrieb Mikael Morin:
Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
I would normally trust NAG more than Intel and Cray.
… and yourself, it seems. Too bad.
If somebody else convinces me to accept that NAG has it wrong this
time, I would be happy to proceed
diagnosed, see testcase.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This is a really safe fix and potentially backportable to other
open branches. Would that be fine?
Thanks,
Harald
From 04bea97afd7f17083774b4309ee4d3c45e278dd3 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 25 Jul
Hi Mikael,
> > https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159
> >
>
> I disagree with the conclusion. Quoting Steve Lionel’s post:
> > What you're missing is this:
> >
> > TARGET (optional)
As a consequence, the PR is likely invalid, as is the patch.
Withdrawing.
Sorry for the noise!
Harald
> Gesendet: Montag, 25. Juli 2022 um 12:43 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf" , "fortran" ,
> "gcc-patches"
> Betreff: Re: [PATCH]
338b43aefece04435d32f961c33d217aaa511095 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 21 Jul 2022 22:02:58 +0200
Subject: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is
remapped [PR77652]
gcc/fortran/ChangeLog:
PR fortran/77652
* check.cc (gfc_check_associated): Make the rank check
-1767-g26bbe78f77f73bb66af1ac13d0deec888a3c6510
Will backport to 12-branch, as the offending code was introduced there.
Thanks,
Harald
From 26bbe78f77f73bb66af1ac13d0deec888a3c6510 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 20 Jul 2022 20:40:23 +0200
Subject: [PATCH] Fortran: fix
Hi Mikael,
Am 19.07.22 um 22:53 schrieb Mikael Morin:
It could be anything better than the (unhelpfull) internal error it is
replacing.
I suggest for example "Invalid array reference of a non-array entity at
%L".
yes, that's much better! The attached updated patch uses this.
Committed:
Hi Mikael,
Am 19.07.22 um 11:03 schrieb Mikael Morin:
Hello,
the principle looks good, but...
Le 18/07/2022 à 22:43, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ebf076f730..dacd33561d0 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc
/associate_54.f90 similarly to Intel.
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
From e6ecc4d8227afea565b0555e95a4f5dcb8f4ecab Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 18 Jul 2022 22:34:53 +0200
Subject: [PATCH] Fortran: error recovery on invalid array reference of
non
Dear all,
the attached patch by Steve fixes a regression under -ff2c for functions
where the result is not set. There would otherwise be conflicting
declarations of the returned result, which gimple doesn't like.
I've committed this as obvious after discussion with Steve for him,
see PR, as
:748f8a8b145dde59c7b63aa68b5a59515b7efc49
Thanks,
Harald
From 748f8a8b145dde59c7b63aa68b5a59515b7efc49 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 14 Jul 2022 22:24:55 +0200
Subject: [PATCH] Fortran: error recovery for bad initializers of implied-shape
arrays [PR106209]
gcc/fortran/ChangeLog
As there were no comments, committed as r13-1650.
Am 05.07.22 um 22:31 schrieb Harald Anlauf via Fortran:
Dear all,
poor error recovery while trying to simplify intrinsics with given
invalid arguments seems to be a recurrent theme in testcases submitted
by Gerhard. In the present case
that cannot be simplified. With some luck, this might prevent issues
in similar cases elsewhere...
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From b70a225cd9ac83cd182938bb8019f9138f85b222 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 5 Jul 2022 22:20:05 +0200
Subject
Hi Tobias,
Am 30.06.22 um 11:58 schrieb Tobias Burnus:
The initial patch is by Steve. I adjusted and moved
it slightly so that it also handles CLASS(*)
(unlimited polymorphic) at the same time.
Shouldn't you then also acknowledge him, e.g. via Co-authored-by?
yeah, I noticed that right
as 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
-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
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)
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 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
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
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:
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
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
ent 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 Anlauf
Date: S
on x86_64-pc-linux-gnu.
I plan to backport as seems appropriate.
Thanks,
Harald
From eac44ace68dd0476bda93ea49a758904c30e3a33 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 10 May 2022 23:41:57 +0200
Subject: [PATCH] Fortran: fix error recovery on invalid array section
gcc/fortran
,
Harald
From 9e5aefa51df49a498854b25ce9dacd46bf58eb4e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 9 May 2022 22:14:21 +0200
Subject: [PATCH] Fortran: check TEAM arguments to coarray intrinsics
TEAM arguments to coarray intrinsics must be scalar expressions of type
TEAM_TYPE of intrinsic
Hi Mikael,
Am 09.05.22 um 20:24 schrieb Mikael Morin:
The fix itself looks good. Regarding the test, I don’t understand the
problem. Can’t there be multiple subroutines, each having one (or more)
problematic statement(s)?
that's why I tried but failed. Example:
subroutine a
errorstop
to provide a testcase for each single fixed pattern.
Therefore a provided a single, minimal testcase based on the report.
Regtested on x86_64-pc-linux-gnu. OK for mainline (i.e. 13-master)?
Thanks,
Harald
From 8b04cb084e138966cf20187887da676ad9e4a00e Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date
Hi Mikael,
Am 26.04.22 um 21:10 schrieb Mikael Morin:
Le 26/04/2022 à 19:12, Mikael Morin a écrit :
Le 26/04/2022 à 15:32, Jakub Jelinek a écrit :
or one can repeat it like:
if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr)
&&
Hi Mikael,
Am 22.04.22 um 12:53 schrieb Mikael Morin:
Le 21/04/2022 à 23:14, Mikael Morin a écrit :
Hello,
this is a fix for PR103662, a TBAA issue with unlimited polymorphic
types.
I attached a draft patch to the PR which was accumulating all unlimited
polymorphic symbols to a single
Hi Fritz,
Am 20.04.22 um 20:03 schrieb Fritz Reese via Fortran:
See the bug report at gcc dot gnu dot org/bugzilla/show_bug.cgi?id=105310 .
This code was originally authored by me and the fix is trivial, so I
intend to commit the attached patch in the next few days if there is
no dissent.
OK
Hi Mike,
for contributing, you'd need to have a GNU copyright assignment or
DCO certification, and I cannot find your name in the usual place.
See e.g. https://gcc.gnu.org/dco.html for details.
Thanks,
Harald
Am 05.04.22 um 19:33 schrieb Mike Kashkarov via Gcc-patches:
Greetings,
Propose
Dear all,
Am 06.04.22 um 22:30 schrieb Harald Anlauf via Fortran:
Dear all,
the logic for checking the allocate-coshape-spec in an ALLOCATE
statement was sort of sideways, and allowed to pass invalid
specifications to the code generation.
The fix seems obvious (to me).
after submitting
From 2adcdbd40e3a64d1f2d42eb0e0fdcc7e593da137 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 6 Apr 2022 22:24:21 +0200
Subject: [PATCH] Fortran: fix logic for checking coshape specification in
ALLOCATE statement
gcc/fortran/ChangeLog:
PR fortran/105184
* resolve.cc
Am 29.03.22 um 23:41 schrieb Harald Anlauf via Fortran:
Dear all,
during error recovery on invalid declarations of functions as
coarrays we may hit multiple places with NULL pointer dereferences.
The attached patch provides a minimal and conservative solution.
Regtested on x86_64-pc-linux-gnu
4c23f78a41fad7cb19ad84c99a73d761fa02 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 4 Apr 2022 20:42:51 +0200
Subject: [PATCH] Fortran: a RECURSIVE procedure cannot be an INTRINSIC
gcc/fortran/ChangeLog:
PR fortran/105138
* intrinsic.cc (gfc_is_intrinsic): When a symbol refers to a
RECURSIVE
00:00:00 2001
From: Harald Anlauf
Date: Wed, 30 Mar 2022 22:36:12 +0200
Subject: [PATCH] Fortran: NULL pointer dereference checking arguments to
ASSOCIATED intrinsic
gcc/fortran/ChangeLog:
PR fortran/100892
* check.cc (gfc_check_associated): Avoid NULL pointer dereference.
gcc/testsuite
ce80d4b2ce3f35684f09bbb2f95f6edc5827224b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 29 Mar 2022 23:33:23 +0200
Subject: [PATCH] Fortran: improve error recovery for invalid coarray function
declarations
gcc/fortran/ChangeLog:
PR fortran/104210
* arith.cc (eval_intrinsic): Avoid NULL
69db6e7f4e1d07bf8f33e93a29139cc16c1e0a2f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 29 Mar 2022 22:12:15 +0200
Subject: [PATCH] Fortran: avoid NULL pointer dereference checking elemental
procedure args
gcc/fortran/ChangeLog:
PR fortran/104571
* resolve.cc (resolve_elemental_actual): Avoid NULL
Hi Tobias,
Am 29.03.22 um 09:14 schrieb Tobias Burnus:
Hi Harald,
On 28.03.22 22:03, Harald Anlauf via Fortran wrote:
All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
'sprintf', and I did not find any other use of %wd/%wu. So the
mentioned implementation is not really
Hi Tobias,
sorry for replying to myself now, but
Am 28.03.22 um 22:03 schrieb Harald Anlauf via Fortran:
All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
'sprintf', and I did not find any other use of %wd/%wu. So the
mentioned implementation is not really stressed yet
--
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
Registergericht München, HRB 106955
From 7efd0613261c5d2120e189387f4b916917c25683 Mon
,
while Intel does not detect the length difference.
Regtested on x86_64-pc-linux-gnu.
OK for mainline? Would it be still ok for 12, or rather wait until
branching for 13?
Thanks,
Harald
From 3b88c941619bc4996ef7d4ba247086f04deb8683 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 27 Mar
-g774ab2edcb5f3a24ed3a5cffd1143bd49a69f1ee
Thanks,
Harald
From 774ab2edcb5f3a24ed3a5cffd1143bd49a69f1ee Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 22 Mar 2022 20:54:18 +0100
Subject: [PATCH] Fortran: ensure intialization of stride array
gcc/fortran/ChangeLog:
PR fortran/104999
* simplify.cc
Hi Mikael,
Am 14.03.22 um 19:28 schrieb Mikael Morin:
Hello,
this workarounds the regression I introduced with the fix for pr104228.
The problem comes from the evaluation of character length for the
associate target (y) in the testcase.
The expression is non-scalar which is not supported at
Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 9 Mar 2022 21:58:26 +0100
Subject: [PATCH] Fortran: improve error recovery on invalid array section
gcc/fortran/ChangeLog:
PR fortran/104849
* expr.cc (find_array_section): Avoid NULL pointer dereference on
invalid array section.
gcc
Hi Tobias,
Am 08.03.22 um 21:19 schrieb Tobias Burnus:
PS: Can I make you review my two pending patches? (NULL and SIZEOF) ;-)
I just approved the former one, but rather hope that Paul or Mikael
or somebody else would jump in on the other one.
PPS: I lost a bit track working on other things
Hi Tobias,
Am 07.03.22 um 15:16 schrieb Tobias Burnus:
Pre-remark: Related NULL, there some accepts-invalid issues, not
addressed in this
patch. See https://gcc.gnu.org/PR104819
This patch fixes an ICE (12 regression) with NULL() that has no MOLD
argument.
the patch does fix the ICE. But
-branch.
Thanks,
Harald
From e3e369dad6cbecb1b490b3f3b154c600fba5a6f3 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 8 Mar 2022 21:47:04 +0100
Subject: [PATCH] Fortran: do not frontend-optimize MINLOC/MAXLOC for character
arrays
gcc/fortran/ChangeLog:
PR fortran/104811
* frontend
Hi Tobias,
Am 07.03.22 um 15:01 schrieb Tobias Burnus:
The problem is that inside the main program,
y = f(z)
where the the result of z is
type(t) :: z(size(x%a))
and 'x' is a dummy argument.
'x' looses the attr.dummy in gfc_add_interface_mapping
and this leads to an additional indirect
ope I got you right. The attached patch fixes your variant
as well as the original testcase, and regtests fine.
Just to be sure: is this what you were thinking of?
Thanks for the very constructive review!
Harald
From e4816e150c31e127c3b6dc0032ae533a2d42 Mon Sep 17 00:00:00 2001
From: Har
Dear Jerry, Mikael,
thanks for the feedback!
Am 24.02.22 um 12:50 schrieb Mikael Morin:
Le 23/02/2022 à 23:21, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
Fortran 2018 added a QUIET= specifier to STOP and ERROR STOP statements.
Janne already implemented the library side code four
Am 16.02.22 um 22:20 schrieb Harald Anlauf via Gcc-patches:
Dear Fortranners,
while we detect invalid uses of type(*), we may run into other issues
later when the declared variable is used, leading to an ICE due to a
NULL pointer dereference. This is demonstrated by Gerhard's testcase.
Steve
on x86_64-pc-linux-gnu. OK for mainline?
One step closer to F2018!
Thanks,
Harald
From 66e80a9847b3e16d4c619ba8da9f3dba891cff34 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 23 Feb 2022 23:08:29 +0100
Subject: [PATCH] Fortran: frontend code for F2018 QUIET specifier to STOP and
ERROR
-linux-gnu. OK for mainline / affected branches?
Thanks,
Harald
From 356d1ab6ddb58559d3641f169f44fd24f7cb00d1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 21 Feb 2022 22:49:05 +0100
Subject: [PATCH] Fortran: skip compile-time shape check if constructor shape
is not known
gcc/fortran
Am 09.02.22 um 22:11 schrieb Harald Anlauf via Gcc-patches:
Dear all,
as we did not properly check the initialization of pointers in
DATA statements for valid initial data targets, we could either
ICE or generate wrong code. Testcase based on Gerhard's, BTW.
The attached patch adds a check
.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 01d629506edca711f02912e2cc124f8894cfa389 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 16 Feb 2022 22:13:02 +0100
Subject: [PATCH] Fortran: error recovery after invalid assumed type
declaration
gcc/fortran
d0250b563eb51f5f5fba5a73a40451cedeb5900d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 10 Feb 2022 21:22:48 +0100
Subject: [PATCH] Fortran: improve error recovery on bad array section
gcc/fortran/ChangeLog:
PR fortran/104211
* expr.cc (find_array_section): Replace assertion by error
recovery when
Hi Paul,
Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran:
Conclusions on ifort:
(i) The agreement between gfortran, with the patch applied, and ifort is
strongest of all the other brands;
(ii) The disagreements are all down to the treatment of the parent
component of arrays of
.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From c94d8f63482e810453dd188faa8396dfac397929 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 9 Feb 2022 21:54:29 +0100
Subject: [PATCH] Fortran: improve check of pointer initialization in DATA
statements
gcc/fortran
Hi Paul,
Am 08.02.22 um 12:22 schrieb Paul Richard Thomas via Fortran:
Hi Harald,
Thanks for giving the patch a whirl.
the parent components as an array. I strongly suspect that, from reading
7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However,
this
is another issue to
Hi Paul,
thanks for attacking this.
I haven't looked at the actual patch, only tried to check the new
testcases with other compilers.
Am 03.02.22 um 18:14 schrieb Paul Richard Thomas via Fortran:
I have tried to interpret F2018 7.5.6.2 and 7.5.6.3 as well as possible.
This is not always
and that it is an ICE on valid code,
would this qualify for later application to 11-branch?
Thanks,
Harald
From 65966b608cff757f43316e1aeed37bd07ce63fe2 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 6 Feb 2022 21:47:20 +0100
Subject: [PATCH] Fortran: try simplifications during reductions
Hi Mikael,
Am 04.02.22 um 11:45 schrieb Mikael Morin:
Hello,
Le 29/01/2022 à 22:41, Harald Anlauf via Fortran a écrit :
The least invasive change - already pointed out by the reporter - is
to check the presence of the argument before dereferencing the data
pointer after the offset calculation
Hi Mikael,
Am 29.01.22 um 15:24 schrieb Mikael Morin:
Hello,
the attached patch is a fix for PR104228.
Even if simple, I wouldn’t call it obvious, as it’s involving character
length and associate, so I don’t mind some extra review eyes.
I am probably not experienced enough to review this.
b8f124adcf258eccd29ffcec5cc3f8915cc2ca47 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 1 Feb 2022 23:33:24 +0100
Subject: [PATCH] Fortran: reject simplifying TRANSFER for MOLD with storage
size 0
gcc/fortran/ChangeLog:
PR fortran/104311
* check.cc (gfc_calculate_transfer_sizes): Checks
delay.
Thanks,
Harald
From 447047a8f95c6bf4b1873f390c833e91aa8af18c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 1 Feb 2022 21:36:42 +0100
Subject: [PATCH] Fortran: error recovery when simplifying EOSHIFT
gcc/fortran/ChangeLog:
PR fortran/104331
* simplify.cc (gfc_simplify_eoshift
69ca8f83149107f48b86360eb878d9d746b99234 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 29 Jan 2022 22:18:30 +0100
Subject: [PATCH] Fortran: fix handling of absent array argument passed to
optional dummy
gcc/fortran/ChangeLog:
PR fortran/101135
* trans-array.cc (gfc_get_dataptr_offset
passes on x86_64-pc-linux-gnu?
Thanks,
Harald
From af5cb1f0ec1cacb47acc8c2b0c0629cf3808e1af Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 26 Jan 2022 21:50:41 +0100
Subject: [PATCH] Fortran: add missing conversions for result of intrinsics to
result type
gcc/fortran/ChangeLog:
PR
Hi Andre',
Am 25.01.22 um 17:32 schrieb Andre Vehreschild via Fortran:
Hi all,
attached patch fixes wrong code generation when broadcasting a derived type
containing allocatable and non-allocatable scalars. Furthermore does it prevent
broadcasting of coarray-tokens, which are always local
intend to backport to the affected branches after some
waiting time.
Thanks,
Harald
From ec543c9833c2d9283c035cd8430849eb4ec04406 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 25 Jan 2022 21:56:39 +0100
Subject: [PATCH] Fortran: MOLD argument to TRANSFER intrinsic having storage
size
.
Thanks,
Harald
From 6c91996f7fc0664a0cf7f5f33ecf2b84c57d4b42 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 24 Jan 2022 21:40:41 +0100
Subject: [PATCH] Fortran: optional argument DIM for intrinsics NORM2, PARITY
must be scalar
gcc/fortran/ChangeLog:
PR fortran/104212
* check.cc
ould find and produces dumps that looked
fine to me. Maybe some expert here can find a better fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline? Maybe 11-branch?
Thanks,
Harald
From ddf161bd2b4de1c0a9655cb61634d94c857b458b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 23 Jan 2022 21:55
-linux-gnu. I also fixed a minor logic bug
in testcase transfer_simplify_11.f90.
OK for mainline? Backports to branches?
Thanks,
Harald
From c9882ace6199e2a327b69449f825e0366b442cba Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 20 Jan 2022 22:36:50 +0100
Subject: [PATCH] Fortran: fix
Am 17.01.22 um 22:26 schrieb Martin Liška:
On 1/12/22 16:54, Martin Liška wrote:
There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.
The patch has been installed as I've made the renaming now.
b9be44b422063c6c1f7a4bb50245ba4051e76136 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 17 Jan 2022 22:52:08 +0100
Subject: [PATCH] Fortran: handle expansion of zero-sized array constructors
gcc/fortran/ChangeLog:
PR fortran/103692
* array.c (gfc_expand_constructor): Handle zero-sized array
constructors.
gcc
An early *ping* ...
Am 11.01.22 um 22:17 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
when digging into the issue pointed out in the PR by Gerhard it turned
out that there were several issues with the TRANSFER intrinsics in the
case MOLD was CHARACTER(kind=4). Default CHARACTER
iers which
therefore must be unconditionally rejected for all standard intrinsics.
OK'ed by Steve (see PR), and committed to mainline as obvious after
regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
From 70e24c9682ddbcade0301665bccd8e7f928d0082 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: F
on the extended testcase
as well as regtests fine on x86_64-pc-linux-gnu.
OK for mainline? Backport to affected branches?
Thanks,
Harald
From 5b914bef991528aebfe9734b4e7af7bae039e66a Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 13 Jan 2022 21:50:45 +0100
Subject: [PATCH] Fortran: fix
after a suitable waiting period.
Thanks,
Harald
From 31436189cb2859040703ec6baff816cd63ef Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 12 Jan 2022 21:24:49 +0100
Subject: [PATCH] Fortran: fix error recovery on bad structure constructor in
DATA statement
gcc/fortran/ChangeLog:
PR
Hi FX,
Am 11.01.22 um 23:04 schrieb FX via Fortran:
Hi Harald,
I think this patch breaks the testsuite
On what platform? It regtested fine on x86_64-pc-linux-gnu
I looked at gcc-testresults and find e.g.
https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747938.html
Hi FX,
Am 02.01.22 um 11:50 schrieb FX via Fortran:
Hi,
This is the first part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code implementing IEEE_CLASS, by
using the
an extended testcase
which is a "hull" of what I used in debugging.
(The testcase was and can be cross-checked with the NAG compiler.)
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From cb14e9a1975bc9d9d2f544c314a0820f68b8bdc7 Mon Sep 17 00:00:00 2001
From: Harald An
Am 11.01.22 um 16:50 schrieb Martin Liška:
On 1/11/22 16:48, Toon Moene wrote:
On 1/11/22 13:56, Martin Liška wrote:
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Plus it survives build of all FEs (--enable-languages=all) on
x86_64-linux-gnu
and I've built all cross
Am 09.01.22 um 21:12 schrieb Mikael Morin:
Le 06/01/2022 à 22:44, Mikael Morin a écrit :
Le 06/01/2022 à 20:50, Harald Anlauf a écrit :
Did you find the time to try your version?
Not yet. But I have not (yet) forgotten about this.
I have looked at it, and it enables infinite mutual
Hi Mikael,
Am 09.01.22 um 20:28 schrieb Mikael Morin:
Le 03/01/2022 à 20:45, Harald Anlauf via Fortran a écrit :
Dear all,
the initial-data-target for a pointer initialization can be either
NULL() or a non-constant target. In the latter case subscripts of
the target specification
Hi Paul,
Am 07.01.22 um 14:42 schrieb Paul Richard Thomas via Fortran:
I doubt that this is a regression on 9-11 branches since the testcase
compiles correctly on each of my copies of these branches. IMHO it is
rather more likely to have been caused by
64f9623765da3306b0ab6a47997dc5d62c2ea261,
Hi Sandra,
Am 06.01.22 um 21:11 schrieb Sandra Loosemore:
This patch fixes an ICE introduced with the recent-ish rewrite to inline
the SIZE intrinsic, using a helper function to do the bulk of the work
in producing the expansion. It turns out to be a simple think-o type
mistake in the wrapper
Hi Mikael,
Am 21.12.21 um 13:38 schrieb Mikael Morin:
Le 20/12/2021 à 23:05, Harald Anlauf via Fortran a écrit :
Dear all,
we need to check the arguments of the elemental MASKL and MASKR
intrinsics also before simplifying.
Testcase by Gerhard. The fix is almost obvious, but I'm happy to
get
Am 05.01.22 um 22:34 schrieb Sandra Loosemore:
One of my previous TS29113-related patches from last fall introduced an
ICE due to a bogus assertion. This is the fix Steve suggested in the
issue, bundled with the test cases, regression-tested, etc. OK to check
in?
OK.
-Sandra
Thanks,
that current Intel and Cray compilers generate similar
errors for the testcase.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From db7562ef764564560fcc59c192df5c00269382ac Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 3 Jan 2022 20:31:10 +0100
Subject: [PATCH
Hi Sandra,
Am 02.01.22 um 19:32 schrieb Sandra Loosemore:
This patch is for PR103390. For background on this issue, the Fortran
standard requires that, when passing a non-contiguous array from Fortran
to a BIND(C) function with the CONTIGUOUS attribute on the corresponding
dummy argument, the
post 12-release.
Cheers,
Harald
Cheers
Paul
On Tue, 28 Dec 2021 at 21:08, Harald Anlauf wrote:
Hi Paul,
Am 28.12.21 um 12:56 schrieb Paul Richard Thomas via Fortran:
Hi Harald,
This looks good to me. OK for mainline and, dare I suggest, 11-branch?
From a quick run through resolve.c
401 - 500 of 873 matches
Mail list logo
