From patchwork Sun Jan 29 16:21:36 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mikael Morin X-Patchwork-Id: 63879 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 21003383FB8A for ; Sun, 29 Jan 2023 16:22:06 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp.smtpout.orange.fr (smtp-25.smtpout.orange.fr [80.12.242.25]) by sourceware.org (Postfix) with ESMTPS id AA8403858409 for ; Sun, 29 Jan 2023 16:21:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AA8403858409 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.16] ([2.10.193.163]) by smtp.orange.fr with ESMTPA id MAQypC95qmlmmMAR4pRj7F; Sun, 29 Jan 2023 17:21:43 +0100 X-ME-Helo: [192.168.1.16] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Sun, 29 Jan 2023 17:21:43 +0100 X-ME-IP: 2.10.193.163 Message-ID: <673726a8-fdce-6c8a-0814-3d0ad666fa2c@orange.fr> Date: Sun, 29 Jan 2023 17:21:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 From: Mikael Morin Subject: [PATCH] fortran: Explicitly set name for *LOC default BACK argument [PR108450] To: gfortran , gcc-patches Content-Language: en-US X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hello, this is a fix for a gcc-12 ICE regression. This ICE rings a bell to me, and I think the change by Tobias which triggers it only uncovers a bug that can also happen independently in other cases. The problem is resolution of maxloc expressions is not idempotent, that is resolution changes the expression in such a way that it can't be successfully resolved again. I have not tried to prevent multiple resolutions, and fixed instead the way the expression is changed. The patch explains the details. No regression on x86_64-pc-linux-gnu. OK for master and 12? From e61e2a51e1859f884125670010337f34265997b8 Mon Sep 17 00:00:00 2001 From: Mikael Morin Date: Sun, 29 Jan 2023 14:38:08 +0100 Subject: [PATCH] fortran: Set name for *LOC default BACK argument [PR108450] This change fixes an ICE caused by the double resolution of MINLOC, MAXLOC and FINDLOC expressions which get a default value for the BACK argument at resolution time. That argument is added without name, and argument reordering code is not prepared to handle unnamed arguments coming after named ones, so the second resolution causes a NULL pointer dereference. The problem is fixed by explicitly setting the argument name. PR fortran/108450 gcc/fortran/ChangeLog: * check.cc (gfc_check_minloc_maxloc): Explicitly set argument name. (gfc_check_findloc): Ditto. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/minmaxloc_1.f90: New test. --- gcc/fortran/check.cc | 2 ++ .../gfortran.dg/gomp/minmaxloc_1.f90 | 32 +++++++++++++++++++ 2 files changed, 34 insertions(+) create mode 100644 gcc/testsuite/gfortran.dg/gomp/minmaxloc_1.f90 diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc index ebcb8f39852..8c1ae8c2f00 100644 --- a/gcc/fortran/check.cc +++ b/gcc/fortran/check.cc @@ -3888,6 +3888,7 @@ gfc_check_minloc_maxloc (gfc_actual_arglist *ap) { b = gfc_get_logical_expr (gfc_logical_4_kind, NULL, 0); ap->next->next->next->next->expr = b; + ap->next->next->next->next->name = gfc_get_string ("back"); } if (m == NULL && d != NULL && d->ts.type == BT_LOGICAL @@ -3969,6 +3970,7 @@ gfc_check_findloc (gfc_actual_arglist *ap) { b = gfc_get_logical_expr (gfc_logical_4_kind, NULL, 0); ap->next->next->next->next->next->expr = b; + ap->next->next->next->next->next->name = gfc_get_string ("back"); } if (m == NULL && d != NULL && d->ts.type == BT_LOGICAL diff --git a/gcc/testsuite/gfortran.dg/gomp/minmaxloc_1.f90 b/gcc/testsuite/gfortran.dg/gomp/minmaxloc_1.f90 new file mode 100644 index 00000000000..b3691f774de --- /dev/null +++ b/gcc/testsuite/gfortran.dg/gomp/minmaxloc_1.f90 @@ -0,0 +1,32 @@ +! { dg-do compile } +! +! PR fortran/108450 +! This program used to cause an ICE because of the double resolution +! of the maxloc expression and the addition of a hidden unnamed argument +! during the first resolution. +! +! Original testcase from G. Steinmetz + +subroutine s1 + integer :: a(8) = 0 + integer :: l + integer :: n + !$omp atomic + n = maxloc(a, mask=l) ! { dg-error ".mask. argument of .maxloc. intrinsic at .1. must be LOGICAL" } +end + +subroutine s2 + integer :: a(8) = 0 + integer :: l + integer :: n + !$omp atomic + n = minloc(a, mask=l) ! { dg-error ".mask. argument of .minloc. intrinsic at .1. must be LOGICAL" } +end + +subroutine s3 + integer :: a(8) = 0 + integer :: l + integer :: n + !$omp atomic + n = findloc(a, 3, mask=l) ! { dg-error ".mask. argument of .findloc. intrinsic at .1. must be LOGICAL" } +end -- 2.39.0