From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5091 invoked by alias); 29 Jan 2003 21:06:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5083 invoked from network); 29 Jan 2003 21:06:47 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by 172.16.49.205 with SMTP; 29 Jan 2003 21:06:47 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id h0TL35j01972; Wed, 29 Jan 2003 13:03:05 -0800 Date: Wed, 29 Jan 2003 22:13:00 -0000 From: Mark Mitchell To: Richard Henderson cc: "gcc@gcc.gnu.org" , "gdr@integrable-solutions.net" Subject: Re: One more limits question Message-ID: <26890000.1043874185@warlock.codesourcery.com> In-Reply-To: <20030129205055.GB21841@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2003-01/txt/msg01594.txt.bz2 --On Wednesday, January 29, 2003 12:50:55 PM -0800 Richard Henderson wrote: > On Wed, Jan 29, 2003 at 12:39:48PM -0800, Mark Mitchell wrote: >> The constant-folding machinery seems to always consider this >> expression to evaluate to true, due to this code in fold: > > IIRC the plan was that __builtin_nan would produce some > non-nan value on targets that don't support them. I don't > remember off-hand where this happens. fold_builtin_nan calls real_nan. real_nan calls get_canonical_{q,s}nan in this case. Those functions seem to be unconditionalized in any way. I also see that we have -ftrapping-math, which sets __SUPPORT_SNAN__, which may or may not be related. We also have MODE_HAS_NANS, but not MODE_HAS_SIGNALING_NANS. Do you know a non-signaling-Nan target I could build a cross-compiler for, so that I could check out how this works? Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com