From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 50D833858C20 for ; Wed, 6 Jul 2022 12:38:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 50D833858C20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.92,250,1650960000"; d="scan'208";a="78367612" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 06 Jul 2022 04:38:50 -0800 IronPort-SDR: Yd6dUZd1ZJUa4zz0kmLHRLu8YI6Q/9p+hXiHQSlQGv7nbdZe1zJbmUCceBpcn+7BGuYEYJ+L+g 0G2y00tEs2WPpZGKZws7jAwomF9y89MgOAyTz99sTKe0mzJtbDP+TDE/mgaW/8bGR1JrpBRduo TOpqOZ+nRU3nZi7QVx6lRSsQKf2nM1cZGT5//7hEGU7sUaftaGiObuer30tiyh5LrGgv4R6ns+ 81mVJVMDNXEae9cc6rLxuEPQjH1JLVfEEVlMkFe/jUOsN8VRRRE/L+OSijQrZk3dHJbHtevOar B/E= From: Thomas Schwinge To: Tobias Burnus CC: , Jakub Jelinek Subject: Re: Fix Intel MIC 'mkoffload' for OpenMP 'requires' (was: [Patch] OpenMP: Move omp requires checks to libgomp) In-Reply-To: <0d0b2fcf-6357-f896-dcd9-99b3d81acd21@codesourcery.com> References: <07fec82a-41cf-fdc5-6307-c068dd95ef1a@mentor.com> <87r12y4i3u.fsf@euler.schwinge.homeip.net> <0d0b2fcf-6357-f896-dcd9-99b3d81acd21@codesourcery.com> User-Agent: Notmuch/0.29.1+93~g67ed7df (https://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) Date: Wed, 6 Jul 2022 14:38:43 +0200 Message-ID: <87mtdml8ks.fsf@dem-tschwing-1.ger.mentorg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-14.mgc.mentorg.com (139.181.222.14) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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: , X-List-Received-Date: Wed, 06 Jul 2022 12:38:53 -0000 Hi Tobias! On 2022-07-06T13:29:14+0200, Tobias Burnus wrote: > On 06.07.22 13:04, Thomas Schwinge wrote: >> On 2022-06-08T05:56:02+0200, Tobias Burnus wr= ote: >>> PS: I have not fully tested the intelmic version. >> As part of my standard testing, I'm reporting that it got completely >> broken. ;'-) > > Interesting. Because intelmic-mkoffload.cc calls GOMP_offload_register > and not GOMP_offload_register_ver - and that call path should be unchange= d. True indeed for that code path... > However, I missed that I had an assert that GCC_OFFLOAD_OMP_REQUIRES_FILE= is > set. ..., but not for that one. > Thus, an alternative is to change that into an 'if'. > But I concur that updating intelmic-mkoffload.cc is nicer! Thanks! ACK. > Regarding: >> -! { dg-do link { target { offload_target_nvptx || offload_target_amdgcn= } } } >> +! { dg-do link { target offloading_enabled } } > This patch looks wrong. We are not interested whether there is an offload= ing device > available or not - but whether the offloading compiler is running. > > Those are completely independent. Obviously, offloading can be configured= but not > being present. (That's the usual case for testing distro builds but also = can > occur elsewhere.) > And also the reverse if possible - usually because of -foffload=3D... but= when GCC is > configured with --enable-offload-defaulted, also other combinations are p= ossible. > > > I think the proper check would be write and use an 'offload_target_any', > i.e. OFFLOAD_TARGET_NAMES=3D being present and nonempty. > > Cf. check_effective_target_offload_target_nvptx / ..._amdgcn and > libgomp_check_effective_target_offload_target > in libgomp/testsuite/lib/libgomp.exp > > Possible patch (untested): > > # Return 1 if compiling for some offload target(s) > proc check_effective_target_offload_target_any { } { > return [libgomp_check_effective_target_offload_target ""] > } > > At least if I understand the following correctly, "" should work: > return [string match "*:$target_name*:*" ":$gcc_offload_targets:= "] :-) Haha, that's actually *exactly* what I had implemented first! But then I realized that 'target offloading_enabled' is doing exactly that: check that offloading compilation is configured -- not that "there is an offloading device available or not" as you seem to understand? Or am I confused there? I do however agree that (generally) replacing 'target offloading_enabled' with a new 'target offload_target_any' would seem appropriate (as a separate patch), because that would also do the right thing when running libgomp testing with non-default '-foffload=3D[...]', including '-foffload=3Ddisable'. For checking "offloading device available" we'd use 'check_effective_target_offload_device[...]'. Gr=C3=BC=C3=9Fe Thomas > Thanks for taking care of the patch fallout! > > Tobias ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955