From patchwork Wed Jul 3 21:59:23 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 1956459 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=scmBlsgV; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4WDtxL0jRZz1xqs for ; Thu, 4 Jul 2024 08:00:04 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 249273858282 for ; Wed, 3 Jul 2024 22:00:02 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id E8A6B385840E for ; Wed, 3 Jul 2024 21:59:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E8A6B385840E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=baylibre.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E8A6B385840E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::32a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720043976; cv=none; b=nJY/7+aQUr3WqgvdObwZX9e/6gn/zYNmpYuBUN+UzOhjfJf3sr+rvrGVRLxUMG3x7ty+jElaKp8G37EvPDzQM7pA3dofjNgXCcf15/+wbEFTAy6VmkIKlCbrBJ2KxQ18FgY1szV8C+ffA/9PJ4rN6jwrDp9nLwqkSISM+Zu8gjk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720043976; c=relaxed/simple; bh=z5iBFB244CEgxLoRqQbBVX7Ew5jBj4jFqMeHMHFu4r8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=p/GZCw/sJ4VPFetF7oqO+dw7uEvBTVlX8VF5YbM+gkwJjo1qPs4ai073S3Jmrrm+kLOWSkzNc2mG43egWk4GRxSJdUMvwk1TvWvu00c7vGB2OSbqqzrN7Ya/L/Zgw3ulp8mx4pFVQ4B5QhDoip2aKnqjZu+uneKmfgMGABO4kuU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4255fa23f7bso41794175e9.2 for ; Wed, 03 Jul 2024 14:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1720043971; x=1720648771; darn=gcc.gnu.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=oRwteimVO3hq1d04FfwUyWNU7MODpRWZPn6WjCEEPyg=; b=scmBlsgVXrcRC6NAZhkmArrM2M1xU3roNwefxpReKYVWWUJO9qpoYSq5rob/Wtcb8q iKXoifshPuT/IRHg4Jo5dWMKTnQAyc+BFOSfkzMbekOcrt/LPkKfiuCOyPrE/3/rhNtp A3tcxoAR6SO1fntXwW+b9/CzCpZTxiiyWLYPT5S9m8yZaQjlAlPVq5vK+8Hdtc/TIUAp ei+ev6gL62JsntAuAFuVpzvxf1jlTyz5Xgz39oWEYLJv5vfNbEzJrI62/WiiJUziWmIv LDNCK5CmrSdCnkaBX7cFENyjRYm6eBkj9FZU82GodKstcNXV/LgrICYEsbrToXlJckzF rdXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720043971; x=1720648771; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oRwteimVO3hq1d04FfwUyWNU7MODpRWZPn6WjCEEPyg=; b=N51xZ4+GpPtavk92qmNxVXocenxx8DQ1tx2lvZU/7D3+OvCqY7qhn1ntNdXAxMOGFD ILCZdv/dq8of6yyrfKg6GaOXaen6eMW+IpYaOvaC5ao1uI1HxcHtoOdk1TU4AbAY7/az QULYxrnH9sBr8V4A2j5HIMr4Rk95cvHVM7L3o6ZNNAvzros92aDO21bzDBOKnSW3EiXw B0D/YZms4Ab7/F3rOc1soeAB4Dwn2xOnKxu6kqoDztJN31cBaL04ClVRnOFoQhAPhAD9 q8oAYtQdNmgrMhtv3+h7TtOC1dLXP/b8b5XkdEgQPdR3qp1sc7Sk5IwxNY3IDX5m3Oyq 1f0A== X-Gm-Message-State: AOJu0Yy0qXNcbLBIVQ6wVCVt/mcsn5yjctPmL7WZrkDvfFDNFhO464ok E1bY+Ft08wx7NEsdsRIFsIYlaBUfS34QMl3HsqY8gu135QMStOyv+OQe4kR+Kak= X-Google-Smtp-Source: AGHT+IEHIxYX836jOwfoL2aRkZOOfrZlLMnvEOH4EawycvRj+4dtXsWFqHFUTsRlEkT5aR6gNsSQdQ== X-Received: by 2002:a05:600c:3594:b0:425:5ea6:236 with SMTP id 5b1f17b1804b1-4257a02b717mr76003945e9.28.1720043971237; Wed, 03 Jul 2024 14:59:31 -0700 (PDT) Received: from euler.schwinge.ddns.net (p200300c8b733b9005e8fc6f38b6af531.dip0.t-ipconnect.de. [2003:c8:b733:b900:5e8f:c6f3:8b6a:f531]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4264a1d615csm212535e9.14.2024.07.03.14.59.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jul 2024 14:59:30 -0700 (PDT) From: Thomas Schwinge To: Tobias Burnus Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, Jakub Jelinek Subject: [OG14] Fortran/OpenMP: Support mapping of DT with allocatable components: disable 'generate_callback_wrapper' for nvptx target (was: [Patch][Stage 1] Fortran/OpenMP: Support mapping of DT with allocatable components) In-Reply-To: References: User-Agent: Notmuch/0.30+8~g47a4bad (https://notmuchmail.org) Emacs/29.4 (x86_64-pc-linux-gnu) Date: Wed, 03 Jul 2024 23:59:23 +0200 Message-ID: <87plrugmro.fsf@euler.schwinge.ddns.net> MIME-Version: 1.0 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org Hi Tobias! I've compared test results for nvptx target for GCC 14 vs. the new OG14, and ran into a number of unexpected regressions: thousands of compilation PASS -> FAIL in the Fortran testsuite. The few that I looked at were all like: ptxas /tmp/ccAMr7D9.o, line 63; error : Illegal operand type to instruction 'st' ptxas /tmp/ccAMr7D9.o, line 63; error : Unknown symbol '%stack' ptxas fatal : Ptx assembly aborted due to errors nvptx-as: ptxas returned 255 exit status compiler exited with status 1 Comparing '-fdump-tree-all' for 'gfortran.dg/pr37287-1.f90' (randomly picked) for GCC 14 vs. OG14, already in 'pr37287-1.f90.005t.original' we see: --- [GCC 14]/pr37287-1.f90.005t.original 2024-07-03 12:45:08.369948469 +0200 +++ [OG14]/pr37287-1.f90.005t.original 2024-07-03 12:44:57.770072298 +0200 @@ -1,3 +1,21 @@ +__attribute__((fn spec (". r r r r "))) +integer(kind=8) __callback___iso_c_binding_C_ptr (integer(kind=8) (*) (void *, void * & restrict, integer(kind=2), void (*) (void)) cb, void * token, void * this_ptr, integer(kind=2) flag) +{ + integer(kind=8) result; + void * * scalar; + + result = 0; + if (flag == 1) + { + result = cb (token, &this_ptr, 64, 3, 0B); + return result; + } + L$1:; + scalar = (void * *) this_ptr; + return result; +} + + __attribute__((fn spec (". . . "))) void __copy___iso_c_binding_C_ptr (void * & restrict src, void * & restrict dst) { (In addition to the whole function '__callback___iso_c_binding_C_ptr', also note that the 'L$1:' label and 'scalar' variable are dead here; but that's likely unrelated to the issue at hand?) This points to OG14 commit 92c3af3d4f82351c7133b6ee90e213a8a5a485db "Fortran/OpenMP: Support mapping of DT with allocatable components": On 2022-03-01T16:34:18+0100, Tobias Burnus wrote: > this patch adds support for mapping something like > type t > type(t2), allocatable :: a, b(:) > integer, allocatable :: c, c(:) > end type t > type(t), allocatable :: var, var2(:,:) > > !$omp target enter data map(var, var) > > which does a deep walk of the components at runtime. > > [...] > > Issues: None known, but I am sure with experimenting, > more can be found - [...] Due to a number of other commits (at least textually) depending on this one, this commit isn't easy to revert on OG14. But: if I disable it for nvptx target as per the attached "Fortran/OpenMP: Support mapping of DT with allocatable components: disable 'generate_callback_wrapper' for nvptx target", then we're back to good -- all GCC 14 vs. OG14 regressions resolved for nvptx target. By the way: it's possible that we've had the same misbehavior also on OG13 and earlier, but just nobody ever tested that for nvptx target. Note that also outside of OG14 (that is, in GCC 14 as well as GCC trunk), we have a number of instances of: ptxas /tmp/ccAMr7D9.o, line 63; error : Illegal operand type to instruction 'st' ptxas /tmp/ccAMr7D9.o, line 63; error : Unknown symbol '%stack' ... all over the Fortran test suite (only). My current theory therefore is that there is some latent issue, which is just greatly exacerbated by OG14 commit 92c3af3d4f82351c7133b6ee90e213a8a5a485db "Fortran/OpenMP: Support mapping of DT with allocatable components" (or some related change). This could be the Fortran front end generating incorrect GIMPLE, or the middle end or (more likely?) nvptx back end not correctly handling something that only comes into existance via the Fortran front end. Anyway: until we understand the underlying issue, OK to push the attached "Fortran/OpenMP: Support mapping of DT with allocatable components: disable 'generate_callback_wrapper' for nvptx target" to devel/omp/gcc-14 branch? Grüße Thomas From 3fb9e4cabea736ace66ee197be1b13a978af10ac Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 3 Jul 2024 22:09:39 +0200 Subject: [PATCH] Fortran/OpenMP: Support mapping of DT with allocatable components: disable 'generate_callback_wrapper' for nvptx target This is, obviously, not the final fix for this issue. gcc/fortran/ * class.cc (generate_callback_wrapper) [GCC_NVPTX_H]: Disable. --- gcc/fortran/class.cc | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc index 15aacd98fd8..2c062204e5a 100644 --- a/gcc/fortran/class.cc +++ b/gcc/fortran/class.cc @@ -64,6 +64,7 @@ along with GCC; see the file COPYING3. If not see #include "gfortran.h" #include "constructor.h" #include "target-memory.h" +#include "tm.h" //TODO /* Inserts a derived type component reference in a data reference chain. TS: base type of the ref chain so far, in which we will pick the component @@ -2420,6 +2421,30 @@ generate_callback_wrapper (gfc_symbol *vtab, gfc_symbol *derived, gfc_namespace *ns, const char *tname, gfc_component *vtab_cb) { + //TODO +#ifdef GCC_NVPTX_H + /* Code generated here appears not relevant for nvptx target (completely + unused?), but results in erroneous PTX code generated: + + ptxas /tmp/ccAMr7D9.o, line 63; error : Illegal operand type to instruction 'st' + ptxas /tmp/ccAMr7D9.o, line 63; error : Unknown symbol '%stack' + ptxas fatal : Ptx assembly aborted due to errors + nvptx-as: ptxas returned 255 exit status + compiler exited with status 1 + + Note that also outside of OG14 (that is, in GCC 14 as well as GCC trunk), + we have a number of instances of this 'ptxas' error, all over the Fortran + test suite (only). The current theory therefore is that there is some + latent issue, which is just greatly exacerbated by this code here. + + This could be the Fortran front end generating incorrect GIMPLE, or the + middle end or (more likely?) nvptx back end not correctly handling + something that only comes into existance via the Fortran front end. + + Until that is resolved, just skip this. */ + return; +#endif + gfc_namespace *sub_ns; gfc_code *last_code, *block; gfc_symbol *callback, *cb, *token, *this_ptr, *scalar, *flag, *result; -- 2.34.1