From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 1C7713858D3C for ; Tue, 12 Oct 2021 18:03:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1C7713858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 19CI1eYs025834; Tue, 12 Oct 2021 13:01:55 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 19CI1S69025826; Tue, 12 Oct 2021 13:01:28 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 12 Oct 2021 13:01:28 -0500 From: Segher Boessenkool To: Martin Sebor Cc: Hongtao Liu , Hongtao Liu , GCC Patches , Bill Schmidt , David Edelsohn Subject: Re: [PATCH] rs6000/test: Adjust some cases due to O2 vect [PR102658] Message-ID: <20211012180128.GI10333@gate.crashing.org> References: <0e964ac9-0e58-33c1-c0ab-24b7f1c60be3@linux.ibm.com> <20211011153050.GV10333@gate.crashing.org> <9bb2743f-cd23-5b7d-6d9d-9917e591377f@gmail.com> <20211011174302.GZ10333@gate.crashing.org> <5966f37c-a51e-593c-4ee2-05c3d04c89fc@gmail.com> <20211012161818.GH10333@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, 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-List-Received-Date: Tue, 12 Oct 2021 18:03:52 -0000 On Tue, Oct 12, 2021 at 11:15:51AM -0600, Martin Sebor wrote: > On 10/12/21 10:18 AM, Segher Boessenkool wrote: > >On Tue, Oct 12, 2021 at 09:49:19AM -0600, Martin Sebor wrote: > >>Coming back to the xfail conditionals, do you think you'll > >>be able to put together some target-supports magic so they > >>don't have to enumerate all the affected targets? > > > >There should only be an xfail if we do not expect to be able to fix the > >bug causing this any time soon. There shouldn't be one here, not yet > >anyway. > > > >Other than that: yes, and one you have such a selector, just dg-require > >it (or its inverse) for this test, don't xfail the test (if this is > >expected and correct behaviour). > > My sense is that fixing all the fallout from the vectorization > change is going to be delicate and time-consuming work. With > the end of stage 1 just about a month away I'm not too optimistic > how much of it I'll be able to get it done before then. Depending > on how intrusive the fixes turn out to be it may or may not be > suitable in stage 3. Some it will be suitable for stage4, even (testsuite-only changes for example). > Based on pr102706 that Jeff reported for the regressions in his > automated tester, it also sounds like the test failures are spread > out across a multitude of targets. In addition, it doesn't look > like the targets are all the same in all the tests. Enumerating > the targets that correspond to each test failure would be like > playing the proverbial Whac-A-Mole. > > That makes me think we do need some such selector rather soon. Yes. > The failing test cases are a subset of all the cases exercised > by the tests. We don't want to conditionally enable/disable > the whole tests just for the few failing cases (if that's what > you were suggesting by dg-require). I mean that the tests should not be done on targets where those tests do not make sense. > So we need to apply > the selector to individual dg-warning and dg-bogus directives > in these tests. Some of those tests should not be run with -fvectorize at all, imo. You *want* to limit things a lot, for detail tests. Segher