From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25009 invoked by alias); 14 Oct 2011 20:08:31 -0000 Received: (qmail 25001 invoked by uid 22791); 14 Oct 2011 20:08:29 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_EJ,TW_JT X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Oct 2011 20:08:16 +0000 From: "ejtttje at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/50724] isnan broken by -ffinite-math-only in g++ Date: Fri, 14 Oct 2011 20:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ejtttje at gmail dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2011-10/txt/msg01424.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 --- Comment #9 from Ethan Tira-Thompson 2011-10-14 20:07:41 UTC --- Thanks, I think Michael hit the nail on the head for summarizing my intention, I'm satisfied to file this as a feature request (although personally I'd still call it a bug ;)) For reference regarding the test case, I agree with your point that 0.f/0 needn't be a reliable NaN generator under -ffast-math. The original source was actually using std::numeric_limits::quiet_NaN() and/or signaling_NaN(), but I switched to 0.f/0 in order to test under C (not-++) and forgot to switch back. So yeah, considering numeric_limits still returns the NaN bit patterns regardless of -ff-m-o, it's unbalanced that isnan is prevented from detecting them. Regardless, disabling classification routines is going beyond the scope of "math" and "arithmetic" as per the name of the flag and its documentation. (For those oversimplifying -ff-m-o as "No NaNs", perhaps you would like to add a new -fno-nans or perhaps -fno-quiet-nans flag if that is what you really want -ffinite-math-only to mean...) In the three linked bug reports, the first is basically a "don't do that" without discussion, the second specifically complains about the lack of discussion, and the third is redirected toward fixing an issue in -mno-ieee without resolving the -ffinite-math-only aspect.