From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97514 invoked by alias); 18 Aug 2015 16:01:02 -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 97411 invoked by uid 55); 18 Aug 2015 16:00:56 -0000 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN Date: Tue, 18 Aug 2015 16:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: 2015-08/txt/msg01245.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #9 from joseph at codesourcery dot com --- On Tue, 18 Aug 2015, ssaraswati at gmail dot com wrote: > Ok, have a further question though. For the current test case, which has the > following code - > > float sNaN = __builtin_nansf ("") > > the sNaN will have a signaling NaN representation. What does > -fno-signaling-nans imply for this situation? Should the compiler assume that It implies the compiler can do whatever is convenient. > this signaling NaN need not be preserved as this would not lead to a trap? In > other words, can the compiler assume that it can carry out optimizations > without having to care for traps? With -fno-signaling-nans the compiler does not need to care about traps from signaling NaNs. It does need to care about traps from quiet NaNs (for example, from ordered comparisons or conversion to integer types) unless -fno-trapping-math / -ffinite-math-only (the former means no need to care about traps, the latter means no need to care about NaNs at all). > > Local fixes for particular signaling NaNs issues seem reasonable (as in: > > if you fold an operation involving a signaling NaN, you may as well quiet > > it in the process, even though signaling NaNs aren't meant to occur in any > > mode where folding them is likely to be safe). > > Thanks, I will prepare a patch to do this. Should I wait for the bug to move to > "new" state, or is it ok to send a fix even though it is marked as > "unconfirmed"? There is no need to wait for bugs to move state (rather, if working on a bug, you may wish to change it to ASSIGNED yourself with yourself as assignee).