From patchwork Tue Oct 1 08:56:35 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 1169789 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-509947-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="RzHYfq9O"; dkim-atps=neutral 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 46jCnS5CZhz9sP7 for ; Tue, 1 Oct 2019 18:56:58 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=NrVRAM5J5AU2ZQG7 OK/ULpuziuDUx3Xf1QYtImWAKHY0oW3Oa6UbgECNmkgGqDWeKrDPHc1gfSuAnMSe HfY/+UEeZKMXmF5dHIplaFqKY6ovD+cjIwUmvTe59K6fW33+n7xAjoTZ8Pa5ZMXp BaV7vvbAaoqd8OiQ34q7DUrw/Z0= 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:from :to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=yq08BkClYU3ZCnnBtWVRqQ orEG0=; b=RzHYfq9O41TRtDunI1BMSZl95hrSk7oGib15FyRXEVHlQVOGzL2Dky 9rth55wlXSAaR/KrAbqaQp7GwbYl23X+MX5CcwjcaXq4TucBrZ9hMkEpGI/dBlVL tJNnLnlvBoKdfGBue7bdt+pcSgcLAQAZ2oY10qtV5mY4QeJSAorIg= Received: (qmail 110876 invoked by alias); 1 Oct 2019 08:56:51 -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 110864 invoked by uid 89); 1 Oct 2019 08:56:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 Oct 2019 08:56:50 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0F43E117A4B; Tue, 1 Oct 2019 04:56:49 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0h+cZTFqO295; Tue, 1 Oct 2019 04:56:49 -0400 (EDT) Received: from free.home (tron.gnat.com [IPv6:2620:20:4000:0:46a8:42ff:fe0e:e294]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id C4008117A48; Tue, 1 Oct 2019 04:56:48 -0400 (EDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id x918uZbS186729 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 1 Oct 2019 05:56:35 -0300 From: Alexandre Oliva To: gcc-patches@gcc.gnu.org Cc: Richard Biener Subject: Store float for pow result test Date: Tue, 01 Oct 2019 05:56:35 -0300 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Optimizing gcc.dg/torture/pr41094.c, the compiler computes the constant value and short-circuits the whole thing. At -O0, however, on 32-bit x86, the call to pow() remains, and the program compares the returned value in a stack register, with excess precision, with the exact return value expected from pow(). If libm's pow() returns a slightly off result, the compare fails. If the value in the register is stored in a separate variable, so it gets rounded to double precision, and then compared, the compare passes. It's not clear that the test was meant to detect libm's reliance on rounding off the excess precision, but I guess it wasn't, so I propose this slight change that enables it to pass regardless of the slight inaccuracy of the C library in use. Regstrapped on x86_64-linux-gnu, and tested on the affected target. Ok to install? for gcc/testsuite/ChangeLog * gcc.dg/torture/pr41094.c: Introduce intermediate variable. --- gcc/testsuite/gcc.dg/torture/pr41094.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/torture/pr41094.c b/gcc/testsuite/gcc.dg/torture/pr41094.c index 2a4e9616cbfad..9219a1741a37f 100644 --- a/gcc/testsuite/gcc.dg/torture/pr41094.c +++ b/gcc/testsuite/gcc.dg/torture/pr41094.c @@ -13,7 +13,8 @@ double foo(void) int main() { - if (foo() != 2.0) + double r = foo (); + if (r != 2.0) abort (); return 0; }