From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id 0A8103858D32 for ; Thu, 30 Nov 2023 08:35:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0A8103858D32 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 0A8103858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701333359; cv=none; b=A9XCSq0Z/eao+WTL7WIBug2MG3BsNXhBcChy9MpA7YIJHup6nSIE0Mg8dkDytcAFRcAMpy+0WK4mG6XtC0+MXiKGjd7/2WnLN+roi58K+6FOaB0UHi7pa9JN0CMYFWJszsoBS9zpEP/bGSlLzHW7PerxnCcjf5sWuZJJDkLcP+U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701333359; c=relaxed/simple; bh=k+UlqO7DEq/7hXVNLaDWGFfUpONSUlsM+0/kR/41nWc=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=V0jLtbR82jbQUJLPTRbuspuapN6ZS5tUqJQpY1IymcdJhQyHQn9b40/O8qkZdT3hSc7blecFvpkAfXeUWm1qbnI+fs2Oh/pkprzZDIvZ9ENBqVIHR1rbbJps4lo3r1ajkFGYVwE4s7Q3JmI8sZXqZpla4rEsHGf9VLrh7PMWhzw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from relay2.suse.de (unknown [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D895F1FC26; Thu, 30 Nov 2023 08:35:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1701333355; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zp5CpCJGgEd04SY28hTKRCinXwJ0TtODbwZIqM9cUto=; b=h1UxpvtKwIY9yiil0SHR3Ms3RrKnwEyAmKK9YFqe1ZrkpEA5285JYZ1nwa5ibnY0xF2pjz 277A5QGlRJg0wtlLSoGP4CB42X+vzKKJCtE4qFUENC4GRaPzzONGTL3j5dOp/9ZAGKkZAk axeuuD+P/W/e6Pbh5wBm1mGZ3Fryw+E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1701333355; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zp5CpCJGgEd04SY28hTKRCinXwJ0TtODbwZIqM9cUto=; b=RB5akyPIy270CwpFD5LE+NbBGdHKoB5/owrPnry9HjrYwiDy/WDiFcw0NEmbnVxj1foIrn x7+/iYRYPaO634BQ== Received: from [10.168.4.150] (unknown [10.168.4.150]) (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 E8A952C15C; Thu, 30 Nov 2023 08:35:53 +0000 (UTC) Date: Thu, 30 Nov 2023 09:32:15 +0100 (CET) From: Richard Biener To: Alexandre Oliva cc: Hans-Peter Nilsson , Eric Botcazou , jeffreyalaw@gmail.com, Rainer Orth , gcc-patches@gcc.gnu.org, mikestump@comcast.net Subject: Re: [PATCH] testsuite: scev: expect fail on ilp32 In-Reply-To: Message-ID: <60s842q0-01r1-q0pp-q606-p6q8p4s1o269@fhfr.qr> References: <6f1516e7-f4be-4e13-b04c-8b5c31cae4f7@gmail.com> <20231129180047.1334620430@pchp3.se.axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ++++++++++++++ Authentication-Results: smtp-out2.suse.de; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=suse.de (policy=none); spf=softfail (smtp-out2.suse.de: 149.44.160.134 is neither permitted nor denied by domain of rguenther@suse.de) smtp.mailfrom=rguenther@suse.de X-Rspamd-Server: rspamd2 X-Spamd-Result: default: False [14.69 / 50.00]; RDNS_NONE(1.00)[]; SPAMHAUS_XBL(0.00)[149.44.160.134:from]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(-1.00)[149.44.160.134:from]; HFILTER_HELO_IP_A(1.00)[relay2.suse.de]; HFILTER_HELO_NORES_A_OR_MX(0.30)[relay2.suse.de]; R_SPF_SOFTFAIL(4.60)[~all:c]; MX_GOOD(-0.01)[]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(2.20)[]; MIME_TRACE(0.00)[0:+]; BAYES_HAM(-3.00)[100.00%]; RDNS_DNSFAIL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[comcast.net,gmail.com]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_SPAM_LONG(3.50)[1.000]; FUZZY_BLOCKED(0.00)[rspamd.com]; FREEMAIL_CC(0.00)[axis.com,adacore.com,gmail.com,CeBiTec.Uni-Bielefeld.DE,gcc.gnu.org,comcast.net]; RCVD_COUNT_TWO(0.00)[2]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; DMARC_POLICY_SOFTFAIL(0.10)[suse.de : No valid SPF, No valid DKIM,none] X-Spam-Score: 14.69 X-Rspamd-Queue-Id: D895F1FC26 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 Thu, 30 Nov 2023, Alexandre Oliva wrote: > On Nov 29, 2023, Hans-Peter Nilsson wrote: > > >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "&a" 1 > >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1 > >> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "&a" 1 > > > It XPASSes on the ilp32 targets I've tried - except "ia32" > > (as in i686-elf) and h8300-elf. Notably XPASSing targets > > includes a *default* configuration of arm-eabi, which in > > part contradicts your observation above. > > My arm-eabi testing then targeted tms570 (big-endian cortex-r5). > > I borrowed the ilp32 vs lp64 line from an internal patch by Eric that > we've had in gcc-11 and gcc-12, when I hit this fail while transitioning > the first and then the second of our 32-bit targets to gcc-13. > > Eric, would you happen to recall where the notion that lp64 was a good > heuristic for these tests? > > > Alex, can you share the presumably plural set of targets > > where you found gcc.dg/tree-ssa/scev-[3-5].c to fail before > > your patch, besides "ia32"? > > I haven't even seen scev-4.c fail, I only got reports that it did. > > I'm not even claiming it fails, I'm only claiming it has been observed > to fail on some ilp32 targets, and nobody seems to have a good sense of > when it's supposed to pass or fail, so my reasoning was that making it > an expected fail is less alarming than seeing actual failures on some > targets. It was known to be imprecise, but to be an improvement over > getting a FAIL for some reasonably common targets when there was no > reason to expect it to actually pass, or even to have ever passed. > > > So, ilp32 is IMO a really bad approximation for the elusive > > property. > > Yeah. Maybe we should just drop the ilp32, so that it's an unsurprising > fail on any targets? > > > Would you please consider changing those "ilp32" to a > > specific set of targets where these tests failed? > > I'd normally have aimed for that, but the challenge is that arm-eabi is > not uniform in the results for this test, and there doesn't seem to be > much support or knowledge to delineate on which target variants it's > meant to pass or not. The test expects the transformation to take > place, as if it ought to, but there's no strong reason to expect that it > should. There's nothing wrong if it doesn't. Going about trying to > match the expectations to the current results may be useful, but > investigating the reasons why we get the current results for each target > is beyond my available resources for a set of tests that used to *seem* > to pass uniformly only because of a bug in the test pattern. > > I don't see much value in these tests as they are, TBH. As I said the tests are really testing IVOPTs costing which is target specific. Maybe we should move them to gcc.target/$X and figure what target they were originally intended to cover ... Richard.