From patchwork Thu Aug 5 16:26:07 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mikael Morin X-Patchwork-Id: 1514009 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=Xk1Gkelk; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4GgYxB2CvCz9sPf for ; Fri, 6 Aug 2021 02:30:05 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3BC373969027 for ; Thu, 5 Aug 2021 16:30:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3BC373969027 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1628181003; bh=LK6zD1VWoHl7lZcvcpqEnb75qoaxuESFb62kR4J6D/E=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=Xk1Gkelk48U4JhqbaYbDZyX+9Zr8eR60isd0npQmjMOgRYVKGsgr3jbvIMSBRZSAO TPvStMaJgYS2M8BNKxrCHbQ9feKuSUWYFa9YLH+gE6Zs4qlior+Vw8RJgTXl+hlJVs GNsiblB9QPBlB5napgSwkkN20/M08khouaJ4V//A= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by sourceware.org (Postfix) with ESMTPS id 5C7C33980C36 for ; Thu, 5 Aug 2021 16:26:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C7C33980C36 Received: from cyrano.home ([92.167.144.168]) by mwinf5d08 with ME id dsSE2500R3eCq5G03sSKYc; Thu, 05 Aug 2021 18:26:19 +0200 X-ME-Helo: cyrano.home X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Thu, 05 Aug 2021 18:26:19 +0200 X-ME-IP: 92.167.144.168 To: fortran@gcc.gnu.org Subject: [PATCH v2 0/7] fortran: Ignore unused arguments for scalarisation [PR97896] Date: Thu, 5 Aug 2021 18:26:07 +0200 Message-Id: <20210805162614.647806-1-mikael@gcc.gnu.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: , X-Patchwork-Original-From: Mikael Morin via Gcc-patches From: Mikael Morin Reply-To: Mikael Morin Cc: gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" Hello, This is the second submit of a patch series whose first version[1] was not welcome because of its C++ usage. After some thought I figured out that rewriting the series without C++ features would not be that impacting after all. So here you go, the (not so) good old-fashioned way. The problematic case is intrinsic procedures where an argument is actually not used in the code generated (KIND argument of INDEX in the testcase), which confuses the scalariser. Thomas König comitted a change to workaround the problem, but it regressed in PR97896. These patch put the workaround where I think it is more appropriate, namely at the beginning of the scalarisation procedure. This is the patch 7 of the series, preceded with the revert in patch 6. I intend to commit both of them squashed together. The rest of the series (patches 1-5) is preliminary work to be able to identify the KIND argument of the INDEX intrinsic by its name, rather than using the right number of next->next->next indirections starting with the first argument. It is probably overkill for just this use case, but I think it’s worth having that facility in the long term. I intend to submit a separate patch for the release branch with only patch 6 and 7 and the next->next->next indirections. Regression-tested on x86_64-linux-gnu. Ok for master? [1] https://gcc.gnu.org/pipermail/fortran/2021-August/056303.html Mikael Morin (7): fortran: new wrapper class gfc_dummy_arg fortran: Tiny sort_actual internal refactoring fortran: Reverse actual vs dummy argument mapping fortran: simplify elemental arguments walking fortran: Delete redundant missing_arg_type field Revert "Remove KIND argument from INDEX so it does not mess up scalarization." fortran: Ignore unused args in scalarization [PR97896] gcc/fortran/gfortran.h | 41 +++++++++-- gcc/fortran/interface.c | 77 ++++++++++++++++++-- gcc/fortran/intrinsic.c | 101 +++++++++++--------------- gcc/fortran/intrinsic.h | 3 +- gcc/fortran/iresolve.c | 21 +----- gcc/fortran/trans-array.c | 74 ++++++++++++++----- gcc/fortran/trans-array.h | 5 +- gcc/fortran/trans-decl.c | 24 +----- gcc/fortran/trans-expr.c | 9 ++- gcc/fortran/trans-intrinsic.c | 3 +- gcc/fortran/trans-stmt.c | 30 ++++---- gcc/fortran/trans.h | 4 +- gcc/testsuite/gfortran.dg/index_5.f90 | 23 ++++++ 13 files changed, 262 insertions(+), 153 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/index_5.f90