From patchwork Sun Feb 22 12:29:28 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 442272 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id D464C1400EA for ; Sun, 22 Feb 2015 23:29:48 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=jZ1URiXlp5+jEA59c 5KYlnvURa5h0YYJB2okOkdN7Y1S2Rdp1BpTGHohYFu2qOJvptMcP8d+1GcTG2X93 jO8QX9VfXZw5xS3rUkd1qVD2+v8iQRNLraX2ZXmEd6YHyK8YS+suZ0IyMzBpB68n RIIhSL/osbLXi6ePcnfTPCX7D8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=g0iaflFs1wbCmvDcM+nUkgS pWuI=; b=ufvgZNe+kfbESXQ4hPzi6FCGoh88Kr9NH3lfKpWtwz9HHNKsIiV20yk khJ1F1kIZ3crn0fYXiDTreqYof7wGqLHqo9wmxCxRoZVTfWuzUDzikyxcxcNgyws 3Dx/PmBAznwJoG0Zqilf10/VKL1s8iQOXFEqqoLVf1DVL4bwo8yo= Received: (qmail 23976 invoked by alias); 22 Feb 2015 12:29:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 23963 invoked by uid 89); 22 Feb 2015 12:29:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 22 Feb 2015 12:29:36 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YPVf9-0004fQ-Mr from Tom_deVries@mentor.com ; Sun, 22 Feb 2015 04:29:32 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Sun, 22 Feb 2015 12:29:30 +0000 Message-ID: <54E9CBA8.2070107@mentor.com> Date: Sun, 22 Feb 2015 13:29:28 +0100 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mike Stump , Jakub Jelinek CC: GCC Patches Subject: Re: [PATCH][testsuite] Abort on failure in gcc.dg/pr30957-1.c References: <54E6FDA2.5030408@mentor.com> <20150220094236.GV1746@tucnak.redhat.com> <54E72A3F.5020105@mentor.com> In-Reply-To: On 20-02-15 20:18, Mike Stump wrote: > On Feb 20, 2015, at 4:36 AM, Tom de Vries wrote: >> On 20-02-15 10:42, Jakub Jelinek wrote: >>> On Fri, Feb 20, 2015 at 10:25:54AM +0100, Tom de Vries wrote: >>>> this patch reverses the abort logic in pr30957-1.c, such that it aborts on >>>> failure rather than on success. >>> >>> That sounds really weird. From the description it looks like it is a known bug >>> that we don't return -0.0. >>> If 0.0 is the right return value instead, The behaviour of the compiler matches the semantics of -fassociative-math, so in that sense it's not a bug. I'm not how to interpret the 'right' value in case of a non-compliant optimization. I guess it's more a case of 'not wrong'. >>> I'd the test should be written as >>> if (__builtin_copysignf (1.0, foo (0.0 / -5.0, 10)) != 1.0) >>> abort (); >>> to make it clear you are expecting positive 0. >>> >> >> Updated patch accordingly. OK for stage1? > > I’ve tried to read through the bug report and all the patches, who did them and why… The entire thread is messier than I’d like, which makes dealing with this whole thing messy. The bug report I marked as fixed, as I think it now works as the bug reporter expects. Seems like a mistake it wasn’t closed a while ago. I've updated the PR with the status as I understand it, and marked it waiting (for review). > I now see why you went with this patch. Why wait for stage 1… Lets just put it in now and put an end to the misery. > > Ok for trunk now. > Committed as attached (using the more minimal -fassociative-math instead of -funsafe-math-optimizations). Thanks, - Tom 2015-02-22 Tom de Vries * gcc.dg/pr30957-1.c: Make pr30957-1.c pass rather xfail. --- gcc/testsuite/gcc.dg/pr30957-1.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/gcc/testsuite/gcc.dg/pr30957-1.c b/gcc/testsuite/gcc.dg/pr30957-1.c index 65b98fa..f34c6e5 100644 --- a/gcc/testsuite/gcc.dg/pr30957-1.c +++ b/gcc/testsuite/gcc.dg/pr30957-1.c @@ -1,12 +1,9 @@ -/* { dg-do run { xfail *-*-* } } */ -/* We don't (and don't want to) perform this optimisation on soft-float - targets, where each addition is a library call. This test requires - -fassociative-math for enabling the variable-expansion as well as - -fsigned-zeros for honoring the sign of zero; but - they can not co-exist; also under -funsafe-math-optimizations, so we - expect it to fail. */ +/* { dg-do run } */ +/* We don't (and don't want to) perform this optimisation on soft-float targets, + where each addition is a library call. / /* { dg-require-effective-target hard_float } */ -/* { dg-options "-O2 -funroll-loops -funsafe-math-optimizations -fvariable-expansion-in-unroller -fdump-rtl-loop2_unroll" } */ +/* -fassociative-math requires -fno-trapping-math and -fno-signed-zeros. */ +/* { dg-options "-O2 -funroll-loops -fassociative-math -fno-trapping-math -fno-signed-zeros -fvariable-expansion-in-unroller -fdump-rtl-loop2_unroll" } */ extern void abort (void); extern void exit (int); @@ -26,12 +23,15 @@ foo (float d, int n) int main () { - if (__builtin_copysignf (1.0, foo (0.0 / -5.0, 10)) != -1.0) + /* When compiling standard compliant we expect foo to return -0.0. But the + variable expansion during unrolling optimization (for this testcase enabled + by non-compliant -fassociative-math) instantiates copy(s) of the + accumulator which it initializes with +0.0. Hence we expect that foo + returns +0.0. */ + if (__builtin_copysignf (1.0, foo (0.0 / -5.0, 10)) != 1.0) abort (); exit (0); } /* { dg-final { scan-rtl-dump "Expanding Accumulator" "loop2_unroll" } } */ /* { dg-final { cleanup-rtl-dump "loop*" } } */ - - -- 1.9.1