From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28672 invoked by alias); 5 Nov 2014 03:54:25 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 28628 invoked by uid 48); 5 Nov 2014 03:54:19 -0000 From: "ian at airs dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/63269] libgo/math test failures in TestLog2 Date: Wed, 05 Nov 2014 03:54:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ian at airs dot com X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-11/txt/msg00228.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269 Ian Lance Taylor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |WAITING Last reconfirmed| |2014-11-05 Ever confirmed|0 |1 --- Comment #3 from Ian Lance Taylor --- First, let me say that this code is in the Go master library and must be fixed there. It might be more effective to discuss it on the Go issue tracker at http://golang.org/issue. I don't agree with your argument for item 1. You say that the wrong result happens when using a fused multiply-add instruction. The math library is compiled with -ffp-contract=off (see MATH_FLAG in configure.ac and Makefile.am), so the compiler should not be generating a fused multiply-add instruction. I'm not entirely persuaded by your argument for item 2. Zero is a special value. When we expect a zero, we should get a zero, not something close to zero. I don't think this change is correct in general. It may be correct for some specific cases, but then we need to investigate those. Item 3 is the same sort of thing: when we expect zero, we should, in general, get exactly zero.