[PATCH, v2] PR fortran/105184 - ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

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 the

[PATCH] PR fortran/105184 - ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

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

*Ping* [PATCH] PR fortran/104210 - [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685

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

[PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used

rald From 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

[committed] PR fortran/100892 - ICE on procedure pointer to function returning array of size n

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

[PATCH] PR fortran/104210 - [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685

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

[PATCH, committed] PR fortran/104571 - ICE in resolve_elemental_actual, at fortran/resolve.cc:2383

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

Re: [PATCH] PR fortran/50549 - should detect different type parameters in structure constructors

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

Re: [PATCH] PR fortran/50549 - should detect different type parameters in structure constructors

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 st

Re: [PATCH] PR fortran/50549 - should detect different type parameters in structure constructors

ortran/ use 'sprintf', and I did not find any other use of %wd/%wu. So the mentioned implementation is not really stressed yet... ;-) Thanks, Harald - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftu

[PATCH] PR fortran/50549 - should detect different type parameters in structure constructors

larly, 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, 2

[Committed] PR fortran/104999 - [12 Regression] runtime error: pointer index expression with base 0x00000cf67720 overflowed to 0xffffffffea627728

-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

Re: [PATCH] fortran: Separate associate character lengths earlier [PR104570]

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 tha

[PATCH, committed] PR fortran/104849 - ICE in find_array_section, at fortran/expr.cc:1616

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

Re: [Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]

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

Re: [Patch] Fortran: Fix gfc_conv_gfc_desc_to_cfi_desc with NULL [PR104126]

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 giv

[PATCH, committed] PR fortran/104811 - maxloc/minloc cannot accept character arguments without `dim` optional argument

to 11-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 * fro

Re: [Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]

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 re

[PATCH, v2] PR fortran/104573 - ICE in resolve_structure_cons, at fortran/resolve.cc:1299

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

Re: [PATCH] PR fortran/84519 - [F2018] STOP and ERROR STOP statements with QUIET specifier

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

*Ping* [PATCH] PR fortran/104573 - ICE in resolve_structure_cons, at fortran/resolve.cc:1299

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.

[PATCH] PR fortran/84519 - [F2018] STOP and ERROR STOP statements with QUIET specifier

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

[PATCH] PR fortran/104619 - [10/11/12 Regression] ICE on list comprehension with default derived type constructor

-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

*Ping* [PATCH] PR fortran/77693 - ICE in rtl_for_decl_init, at dwarf2out.c:17378

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 che

[PATCH] PR fortran/104573 - ICE in resolve_structure_cons, at fortran/resolve.cc:1299

ached. 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/fo

[PATCH] PR fortran/104211 - ICE in find_array_section, at fortran/expr.cc:1720

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

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

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 exten

[PATCH] PR fortran/77693 - ICE in rtl_for_decl_init, at dwarf2out.c:17378

uture. 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/fo

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

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 co

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

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 straig

[PATCH] PR fortran/66193 - ICE for initialisation of some non-zero-sized arrays

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

Re: [PATCH] PR/101135 - Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument

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

Re: [PATCH] fortran: Unshare associate var charlen [PR104228]

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. Pa

[PATCH] PR fortran/104311 - [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce

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

[pushed] PR fortran/104331 - [10/11/12 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590

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

[PATCH] PR/101135 - Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument

-gnu. OK for mainline? Thanks, Harald From 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/101

[PATCH] PR fortran/84784 - ICEs: verify_gimple failed with -fdefault-integer-8

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

Re: [PR103970, Fortran, Coarray] Multi-image co_broadcast of derived type with allocatable components fails^

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 this_

[pushed] PR/fortran 104227 - [9/10/11/12 Regression] ICE virtual memory exhausted: Cannot allocate memory

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

[PATCH] PR fortran/104212 - ICE in transformational_result, at fortran/simplify.cc:466

. 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

[PATCH] PR fortran/104128 - ICE in gfc_widechar_to_char, at fortran/scanner.c:199

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

[PATCH] PR fortran/104127 - [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244

-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

Re: [PATCH] git-backport: support renamed .cc files in commit message.

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. Chee

[PATCH] PR fortran/103692 - [11/12 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:2062

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

Re: [PATCH] PR fortran/83079 - ICE and wrong code with TRANSFER and character(kind=4)

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 was

[PATCH, committed] PR fortran/99256 - ICE in variable_check, at fortran/check.c:1012

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 Da

[PATCH] PR fortran/103782 - [9/10/11/12 Regression] internal error occurs when overloading intrinsic

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

[PATCH] PR fortran/67804 - ICE on data initialization of type(character) with wrong data

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

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

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 https://gcc.gn

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

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 issignali

[PATCH] PR fortran/83079 - ICE and wrong code with TRANSFER and character(kind=4)

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

Re: [PATCH] Mass rename of C++ .c files to .cc suffix

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 co

Re: [PATCH] PR fortran/103777 - ICE in gfc_simplify_maskl, at fortran/simplify.c:4918

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

Re: [PATCH] PR fortran/101762 - ICE on non-constant pointer initialization targets

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 (or

Re: [Patch, fortran] PR103366 - [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647

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, w

Re: [PATCH] Fortran: Fix handling of optional argument to SIZE intrinsic [PR103898]

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 a

Re: [PATCH] PR fortran/103777 - ICE in gfc_simplify_maskl, at fortran/simplify.c:4918

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 t

Re: [PATCH] Fortran: Fix ICE in argument_rank_mismatch [PR103287]

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, Haral

[PATCH] PR fortran/101762 - ICE on non-constant pointer initialization targets

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

Re: [PATCH] Fortran: fix PR103390, ICE in gimplification

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 c

Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366

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

Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366

ributes should already have been set up? Or use a better name? (IS_CLASS_OBJECT?) Thanks, Harald Thanks for the patch Paul On Mon, 27 Dec 2021 at 22:17, Harald Anlauf via Fortran wrote: Dear all, there are a couple of NULL pointer dereferences leading to improper error recovery when tr

[PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366

should be done here. (I was surprised to see that there are several different places involved by rather simple variations in the basic test case.) Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From 4cda248202ea741bea1dd1ca4531aa15f423801b Mon Sep 17 00:00:00 2001 From: Har

[PATCH] PR fortran/103777 - ICE in gfc_simplify_maskl, at fortran/simplify.c:4918

MASKR, which however misses the case of array arguments.) Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From b58a44bc861ee3d1e67e3b7c949a301b6290c05c Mon Sep 17 00:00:00 2001 From: Harald Anlauf Date: Mon, 20 Dec 2021 22:59:53 +0100 Subject: [PATCH] Fortran: check arguments of

[PATCH] PR fortran/103778 - [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

suggestions. Thanks, Harald From 2e6c83fbddda3215faf111263ebfc754bc07096c Mon Sep 17 00:00:00 2001 From: Harald Anlauf Date: Mon, 20 Dec 2021 22:12:33 +0100 Subject: [PATCH] Fortran: BOZ literal constants are not interoperable gcc/fortran/ChangeLog: PR fortran/103778 * check.c (is_c_interoperable

[PATCH] PR fortran/103776 - ICE in gfc_compare_string, at fortran/arith.c:1118

e 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 * ma

[PATCH, committed] PR fortran/103412 - [10/11/12 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

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

Re: [patch] Fix libfortran/98507, handling of timezone near year boundaries

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 correcting

Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

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

Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

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 commit

[PATCH, committed] PR fortran/103717 - ICE in doloop_code, at fortran/frontend-passes.c:2656

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

[PATCH] PR fortran/103718 & PR fortran/103719 - [11/12 Regression] ICE in doloop_contained_procedure_code

: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

Re: [PATCH, v2] PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays

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), but

[PATCH, v2] PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays

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 as

[PATCH] PR fortran/103606 - [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297

, 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 not

[PATCH, v2] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

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

[PATCH] PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays

, 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

[PATCH, committed] PR fortran/103609 - [11/12 Regression] ICE in gfc_sym_get_dummy_args, at fortran/symbol.c:5243

: 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 or

[PATCH] PR fortran/103610 - ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

s, Harald 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

Re: [PATCH] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

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 as

[PATCH] PR fortran/103607 - [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

From 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

[PATCH] PR fortran/103588 - ICE: Simplification error in gfc_ref_dimen_size, at fortran/array.c:2407

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

[PATCH] PR fortran/103591 - ICE in gfc_compare_string, at fortran/arith.c:1119

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

[PATCH] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

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

[PATCH] PR fortran/103505 - ICE in compare_bound_mpz_t, at fortran/resolve.c:4587

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

Re: [PATCH, Fortran] Fix setting of array lower bound for named arrays

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

Re: [PATCH] PR fortran/101565 - ICE in gfc_simplify_image_index, at fortran/simplify.c:8234

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

[PATCH] PR fortran/103473 - [11/12 Regression] ICE in simplify_minmaxloc_nodim, at fortran/simplify.c:5287

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 is not

[PATCH] PR fortran/101565 - ICE in gfc_simplify_image_index, at fortran/simplify.c:8234

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

Re: [PATCH, Fortran] Fix setting of array lower bound for named arrays

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 LB

Re: [PATCH, Fortran] Fix setting of array lower bound for named arrays

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) cont

Re: [PATCH] Only return after resetting type_param_spec_list

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 regtes

[PATCH, fortran] Improve expansion of constant array expressions within constructors

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

[PATCH, v3] PR fortran/103411 - ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

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

[PATCH, v2] PR fortran/103411 - ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

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

Re: [PATCH] PR fortran/103411 - ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

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

[PATCH] PR fortran/103411 - ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

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

[PATCH] PR fortran/103392 - [9/10/11/12 Regression] ICE in simplify_bound, at fortran/simplify.c:4273

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 not

Re: [PATCH] PR fortran/87851 - [9/10/11/12 Regression] Wrong return type for len_trim

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 by

Re: [PATCH] gfortran: Improve translation of POPPAR intrinsic

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)); }

<    1   2   3   4   5   6   7   8   9   10   >