| Message ID | 499b9ae2-1365-a954-ed5e-35aede5d0def@suse.cz |
|---|---|
| State | New |
| Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> 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 EBC73385800C for <patchwork@sourceware.org>; Mon, 8 Nov 2021 08:47:30 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 29EDF385842D for <gcc-patches@gcc.gnu.org>; Mon, 8 Nov 2021 08:45:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29EDF385842D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id EC063212C2; Mon, 8 Nov 2021 08:45:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1636361139; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6y1JUvabUu0Ii2zXfc9tTKkrAyrb++RwatTbog/8iA8=; b=L64ukXhegijE2i4T/1Fb94xcCSp1Rd00koixBaH3fDiHM0qN7tqANPEExUj3mIonKL/0um ETDbNI98QZ7dlNFTXV9MCTQ+3hvGA9rO99dKDN0vrX6FwiPBxECYUDKHTGhTBZymi/eVHv wJ0vBQ0aPAc1KTYp+JlufTneh0TSbpo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1636361139; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6y1JUvabUu0Ii2zXfc9tTKkrAyrb++RwatTbog/8iA8=; b=WQQZvO0pLzPQ/WrO93mToeVWh9W4qw8AgWLiSyeFIxw2rfYHtPMOBNIEyV8qcv+MqyZUqz 10Ye2XEH2rKPbMDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C2389139CF; Mon, 8 Nov 2021 08:45:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id SBZ0LbPjiGENYgAAMHmgww (envelope-from <mliska@suse.cz>); Mon, 08 Nov 2021 08:45:39 +0000 Message-ID: <499b9ae2-1365-a954-ed5e-35aede5d0def@suse.cz> Date: Mon, 8 Nov 2021 09:45:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 From: =?utf-8?q?Martin_Li=C5=A1ka?= <mliska@suse.cz> Subject: [PATCH] Remove dead code. To: gcc-patches@gcc.gnu.org Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Cc: Jakub Jelinek <jakub@redhat.com>, Tobias Burnus <tobias@codesourcery.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
| Series |
Remove dead code.
|
|
Commit Message
Martin Liška
Nov. 8, 2021, 8:45 a.m. UTC
This fixes issue reported in the PR. Ready to be installed? Thanks, Martin PR other/89259 liboffloadmic/ChangeLog: * runtime/offload_omp_host.cpp: Remove size < 0 for a size of size_t type. --- liboffloadmic/runtime/offload_omp_host.cpp | 5 ----- 1 file changed, 5 deletions(-)
Comments
On Mon, Nov 08, 2021 at 09:45:39AM +0100, Martin Liška wrote: > This fixes issue reported in the PR. > > Ready to be installed? I'm not sure. liboffloadmic is copied from upstream, so the right thing if we want to do anything at all (if we don't remove it, nothing bad happens, the condition is never true anyway, whether removed away in the source or removed by the compiler) would be to let Intel fix it in their source and update from that. But I have no idea where it even lives upstream. Jakub
On 11/8/2021 2:59 AM, Jakub Jelinek via Gcc-patches wrote: > On Mon, Nov 08, 2021 at 09:45:39AM +0100, Martin Liška wrote: >> This fixes issue reported in the PR. >> >> Ready to be installed? > I'm not sure. liboffloadmic is copied from upstream, so the right > thing if we want to do anything at all (if we don't remove it, nothing > bad happens, the condition is never true anyway, whether removed away > in the source or removed by the compiler) would be to let Intel fix it in > their source and update from that. > But I have no idea where it even lives upstream. I thought MIC as an architecture was dead, so it could well be the case that there isn't a viable upstream anymore for that code. jeff
On 11/8/21 15:19, Jeff Law wrote: > > > On 11/8/2021 2:59 AM, Jakub Jelinek via Gcc-patches wrote: >> On Mon, Nov 08, 2021 at 09:45:39AM +0100, Martin Liška wrote: >>> This fixes issue reported in the PR. >>> >>> Ready to be installed? >> I'm not sure. liboffloadmic is copied from upstream, so the right >> thing if we want to do anything at all (if we don't remove it, nothing >> bad happens, the condition is never true anyway, whether removed away >> in the source or removed by the compiler) would be to let Intel fix it in >> their source and update from that. >> But I have no idea where it even lives upstream. > I thought MIC as an architecture was dead, so it could well be the case that there isn't a viable upstream anymore for that code. > > jeff @H.J. ? Martin
On Fri, Nov 12, 2021 at 6:27 AM Martin Liška <mliska@suse.cz> wrote: > > On 11/8/21 15:19, Jeff Law wrote: > > > > > > On 11/8/2021 2:59 AM, Jakub Jelinek via Gcc-patches wrote: > >> On Mon, Nov 08, 2021 at 09:45:39AM +0100, Martin Liška wrote: > >>> This fixes issue reported in the PR. > >>> > >>> Ready to be installed? > >> I'm not sure. liboffloadmic is copied from upstream, so the right > >> thing if we want to do anything at all (if we don't remove it, nothing > >> bad happens, the condition is never true anyway, whether removed away > >> in the source or removed by the compiler) would be to let Intel fix it in > >> their source and update from that. > >> But I have no idea where it even lives upstream. > > I thought MIC as an architecture was dead, so it could well be the case that there isn't a viable upstream anymore for that code. > > > > jeff > > @H.J. ? > We'd like to deprecate MIC offload in GCC 12. We will remove all traces of MIC offload in GCC 13.
On 11/12/21 15:41, H.J. Lu wrote: > On Fri, Nov 12, 2021 at 6:27 AM Martin Liška <mliska@suse.cz> wrote: >> >> On 11/8/21 15:19, Jeff Law wrote: >>> >>> >>> On 11/8/2021 2:59 AM, Jakub Jelinek via Gcc-patches wrote: >>>> On Mon, Nov 08, 2021 at 09:45:39AM +0100, Martin Liška wrote: >>>>> This fixes issue reported in the PR. >>>>> >>>>> Ready to be installed? >>>> I'm not sure. liboffloadmic is copied from upstream, so the right >>>> thing if we want to do anything at all (if we don't remove it, nothing >>>> bad happens, the condition is never true anyway, whether removed away >>>> in the source or removed by the compiler) would be to let Intel fix it in >>>> their source and update from that. >>>> But I have no idea where it even lives upstream. >>> I thought MIC as an architecture was dead, so it could well be the case that there isn't a viable upstream anymore for that code. >>> >>> jeff >> >> @H.J. ? >> > > We'd like to deprecate MIC offload in GCC 12. We will remove all traces of > MIC offload in GCC 13. I see. So do you want the patch to be installed or not? Cheers, Martin > >
On Fri, Nov 12, 2021 at 6:44 AM Martin Liška <mliska@suse.cz> wrote: > > On 11/12/21 15:41, H.J. Lu wrote: > > On Fri, Nov 12, 2021 at 6:27 AM Martin Liška <mliska@suse.cz> wrote: > >> > >> On 11/8/21 15:19, Jeff Law wrote: > >>> > >>> > >>> On 11/8/2021 2:59 AM, Jakub Jelinek via Gcc-patches wrote: > >>>> On Mon, Nov 08, 2021 at 09:45:39AM +0100, Martin Liška wrote: > >>>>> This fixes issue reported in the PR. > >>>>> > >>>>> Ready to be installed? > >>>> I'm not sure. liboffloadmic is copied from upstream, so the right > >>>> thing if we want to do anything at all (if we don't remove it, nothing > >>>> bad happens, the condition is never true anyway, whether removed away > >>>> in the source or removed by the compiler) would be to let Intel fix it in > >>>> their source and update from that. > >>>> But I have no idea where it even lives upstream. > >>> I thought MIC as an architecture was dead, so it could well be the case that there isn't a viable upstream anymore for that code. > >>> > >>> jeff > >> > >> @H.J. ? > >> > > > > We'd like to deprecate MIC offload in GCC 12. We will remove all traces of > > MIC offload in GCC 13. > > I see. So do you want the patch to be installed or not? > I prefer to leave it alone and close the PR with WONTFIX.
On November 12, 2021 3:41:41 PM GMT+01:00, "H.J. Lu via Gcc-patches" <gcc-patches@gcc.gnu.org> wrote: >On Fri, Nov 12, 2021 at 6:27 AM Martin Liška <mliska@suse.cz> wrote: >> >> On 11/8/21 15:19, Jeff Law wrote: >> > >> > >> > On 11/8/2021 2:59 AM, Jakub Jelinek via Gcc-patches wrote: >> >> On Mon, Nov 08, 2021 at 09:45:39AM +0100, Martin Liška wrote: >> >>> This fixes issue reported in the PR. >> >>> >> >>> Ready to be installed? >> >> I'm not sure. liboffloadmic is copied from upstream, so the right >> >> thing if we want to do anything at all (if we don't remove it, nothing >> >> bad happens, the condition is never true anyway, whether removed away >> >> in the source or removed by the compiler) would be to let Intel fix it in >> >> their source and update from that. >> >> But I have no idea where it even lives upstream. >> > I thought MIC as an architecture was dead, so it could well be the case that there isn't a viable upstream anymore for that code. >> > >> > jeff >> >> @H.J. ? >> > >We'd like to deprecate MIC offload in GCC 12. We will remove all traces of >MIC offload in GCC 13. Can you document that in gcc-12/changes.html in the caveats section please? Thanks, Richard. >
On Fri, Nov 12, 2021 at 11:15 AM Richard Biener <richard.guenther@gmail.com> wrote: > > On November 12, 2021 3:41:41 PM GMT+01:00, "H.J. Lu via Gcc-patches" <gcc-patches@gcc.gnu.org> wrote: > >On Fri, Nov 12, 2021 at 6:27 AM Martin Liška <mliska@suse.cz> wrote: > >> > >> On 11/8/21 15:19, Jeff Law wrote: > >> > > >> > > >> > On 11/8/2021 2:59 AM, Jakub Jelinek via Gcc-patches wrote: > >> >> On Mon, Nov 08, 2021 at 09:45:39AM +0100, Martin Liška wrote: > >> >>> This fixes issue reported in the PR. > >> >>> > >> >>> Ready to be installed? > >> >> I'm not sure. liboffloadmic is copied from upstream, so the right > >> >> thing if we want to do anything at all (if we don't remove it, nothing > >> >> bad happens, the condition is never true anyway, whether removed away > >> >> in the source or removed by the compiler) would be to let Intel fix it in > >> >> their source and update from that. > >> >> But I have no idea where it even lives upstream. > >> > I thought MIC as an architecture was dead, so it could well be the case that there isn't a viable upstream anymore for that code. > >> > > >> > jeff > >> > >> @H.J. ? > >> > > > >We'd like to deprecate MIC offload in GCC 12. We will remove all traces of > >MIC offload in GCC 13. > > Can you document that in gcc-12/changes.html in the caveats section please? > I will do that. Can you review my last wwwdocs change: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578344.html Thanks.
On November 12, 2021 8:18:59 PM GMT+01:00, "H.J. Lu" <hjl.tools@gmail.com> wrote: >On Fri, Nov 12, 2021 at 11:15 AM Richard Biener ><richard.guenther@gmail.com> wrote: >> >> On November 12, 2021 3:41:41 PM GMT+01:00, "H.J. Lu via Gcc-patches" <gcc-patches@gcc.gnu.org> wrote: >> >On Fri, Nov 12, 2021 at 6:27 AM Martin Liška <mliska@suse.cz> wrote: >> >> >> >> On 11/8/21 15:19, Jeff Law wrote: >> >> > >> >> > >> >> > On 11/8/2021 2:59 AM, Jakub Jelinek via Gcc-patches wrote: >> >> >> On Mon, Nov 08, 2021 at 09:45:39AM +0100, Martin Liška wrote: >> >> >>> This fixes issue reported in the PR. >> >> >>> >> >> >>> Ready to be installed? >> >> >> I'm not sure. liboffloadmic is copied from upstream, so the right >> >> >> thing if we want to do anything at all (if we don't remove it, nothing >> >> >> bad happens, the condition is never true anyway, whether removed away >> >> >> in the source or removed by the compiler) would be to let Intel fix it in >> >> >> their source and update from that. >> >> >> But I have no idea where it even lives upstream. >> >> > I thought MIC as an architecture was dead, so it could well be the case that there isn't a viable upstream anymore for that code. >> >> > >> >> > jeff >> >> >> >> @H.J. ? >> >> >> > >> >We'd like to deprecate MIC offload in GCC 12. We will remove all traces of >> >MIC offload in GCC 13. >> >> Can you document that in gcc-12/changes.html in the caveats section please? >> > >I will do that. > >Can you review my last wwwdocs change: > >https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578344.html That change is OK. Richard. >Thanks. >
diff --git a/liboffloadmic/runtime/offload_omp_host.cpp b/liboffloadmic/runtime/offload_omp_host.cpp index 0439fec313b..4d8c57e3385 100644 --- a/liboffloadmic/runtime/offload_omp_host.cpp +++ b/liboffloadmic/runtime/offload_omp_host.cpp @@ -688,11 +688,6 @@ int omp_target_associate_ptr( return 1; } - // An incorrect size is treated as failure - if (size < 0) { - return 1; - } - // If OpenMP allows wrap-around for device numbers, enable next line //Engine& device = mic_engines[device_num % mic_engines_total]; Engine& device = mic_engines[device_num];