From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59940 invoked by alias); 12 Jan 2018 17:55:43 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 59859 invoked by uid 89); 12 Jan 2018 17:55:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*f:sk:pARWnkD, H*f:CAAgBjMnokvHyD, H*f:sk:a2206a8, H*f:sk:3a12541 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Jan 2018 17:55:42 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C06D62D1CA; Fri, 12 Jan 2018 17:55:40 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-22.ams2.redhat.com [10.36.117.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5663D179E9; Fri, 12 Jan 2018 17:55:39 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id w0CHtaFU010628; Fri, 12 Jan 2018 18:55:36 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id w0CHtY4X010207; Fri, 12 Jan 2018 18:55:34 +0100 Date: Fri, 12 Jan 2018 17:56:00 -0000 From: Jakub Jelinek To: Jeff Law Cc: Martin Sebor , Prathamesh Kulkarni , Rainer Orth , Christophe Lyon , gcc Patches Subject: Re: PR81703 and Martin's fix for PR83501 Message-ID: <20180112175534.GF2063@tucnak> Reply-To: Jakub Jelinek References: <94c15f57-5bfe-a66a-712a-cc74a4f6f209@gmail.com> <07574588-3c67-45e2-a79d-693646915fd1@gmail.com> <3a12541d-e56c-21c8-fa51-bdebc8578c66@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a12541d-e56c-21c8-fa51-bdebc8578c66@redhat.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg01093.txt.bz2 On Fri, Jan 12, 2018 at 10:38:39AM -0700, Jeff Law wrote: > >>> Thanks for pointing it out.  I see it there as well with > >>> Prathamesh's test case, though not with the test case in > >>> bug 83543.  It is the same root cause in both.  I agree > >>> that enhancing the strlen pass to handle this case would > >>> be preferable to just xfailing the test.  I'm just not > >>> sure it's possible before stage 3 closes.  If not, I'll > >>> work on it in GCC 9.  Although the details are target- > >>> specific, the limitation affects all targets and so > >>> having a solution will benefit all all of them. > >> Indeed, however for now I am not sure what would be the best approach ? > >> If the test-case starts failing for many targets, not sure if XFAIL > >> would be the right choice. > >> Should I just restrict it to x86_64 target for now ? > > > > That sounds like a good approach in the interim, until we have > > a general solution.  It will avoid having to maintain a list > > of targets where it's known to fail. > Agreed and pre-approved. Just please test with RUNTESTFLAGS='--target_board=unix\{-m64,-m32,-m32/-mno-sse\} dg.exp=strlenopt-*.c' and restrict to { i?86-*-* x86_64-*-* }, e.g. on Solaris it is i?86-*-* canonical target, even when it supports -m64 multilib. If you need x86_64 64-bit, that would be { { i?86-*-* x86_64-*-* } && lp64 } or ! ia32, depending on if -mx32 works or not. Jakub