From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id ECC763858C98 for ; Mon, 20 Nov 2023 07:35:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ECC763858C98 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ECC763858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.220.29 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700465716; cv=none; b=k0VKikotl/Wr+AHtds06pSSCltJ44UxHVFKfvkUOIKG5eStZg9UX12GIJPHk+/YQVM7JnFsFhPHzvTI+utY0Cfct8ajFX6w8U3btQ5nWeCDJUyIhrWkXZyKYackvuJDK7AL53mjPIYV2BLb5wwr2wIOjEj2IZn4skrnwxf8vf0U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700465716; c=relaxed/simple; bh=lnOTYR55tpNBm2YGfcgzlP9IZM6TSCjXPR1GKYLFnb8=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=hh3Uvq3AmSGRh6W5MnQLavlFOgTm1A2v2aRXucsPyh82eamSYVTfY3LUoTcY+IxnjOu04SH/FB5TtENtvnDknNF8I9WmsDRELv/GDIZWTxGiRicJjr6hsku7L25G7dciZSDQ8qcXnn+nXR0NOUYmNo90P5z5B3fwXVO45Bdvo+E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id C6DC21F750; Mon, 20 Nov 2023 07:35:13 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 7891F2D106; Mon, 20 Nov 2023 07:35:13 +0000 (UTC) Date: Mon, 20 Nov 2023 07:35:13 +0000 (UTC) From: Richard Biener To: Jeff Law cc: Alexandre Oliva , gcc-patches@gcc.gnu.org, Rainer Orth , Mike Stump Subject: Re: [PATCH] testsuite: scev: expect fail on ilp32 In-Reply-To: <6f1516e7-f4be-4e13-b04c-8b5c31cae4f7@gmail.com> Message-ID: References: <6f1516e7-f4be-4e13-b04c-8b5c31cae4f7@gmail.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Level: Authentication-Results: smtp-out2.suse.de; none X-Rspamd-Server: rspamd2 X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Spam-Score: -4.00 X-Rspamd-Queue-Id: C6DC21F750 X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_NUMSUBJECT,KAM_SHORT,SPF_HELO_NONE,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 List-Id: On Sun, 19 Nov 2023, Jeff Law wrote: > > > On 11/19/23 00:30, Alexandre Oliva wrote: > > > > I've recently patched scev-3.c and scev-5.c because it only passed by > > accident on ia32. It also fails on some (but not all) arm-eabi > > variants. It seems hard to characterize the conditions in which the > > optimization is supposed to pass, but expecting them to fail on ilp32 > > targets, though probably a little excessive and possibly noisy, is not > > quite as alarming as getting a fail in test reports, so I propose > > changing the xfail marker from ia32 to ilp32. > > > > I'm also proposing to add a similar marker to scev-4.c. Though it > > doesn't appear to be failing for me, I've got reports that suggest it > > still does for others, and it certainly did for us as well. > > > > Regstrapped on x86_64-linux-gnu, also tested on arm-eabi with default > > cpu on trunk, and with tms570 on gcc-13. Ok to install? > > > > > > for gcc/testsuite/ChangeLog > > > > * gcc.dg/tree-ssa/scev-3.c: xfail on all ilp32 targets, > > though some of these do pass. > > * gcc.dg/tree-ssa/scev-4.c: Likewise. > > * gcc.dg/tree-ssa/scev-5.c: Likewise. > OK. Though hopefully someone will figure out what properties actually cause > the differences so that we can do the right thing without the noisy XPASS at > some point. The tests all test IVOPTs induction variable selecting results (assuming every target would come to the "obvious" conclusion), so it's probably not only target but also sub-target (aka -mtune) sensitive ... In the end we might need to move/duplicate the test to some gcc.target/* dir and restrict it to a specific tuning. Richard.