From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29065 invoked by alias); 3 Aug 2011 14:33:28 -0000 Received: (qmail 29053 invoked by uid 22791); 3 Aug 2011 14:33:27 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Aug 2011 14:33:09 +0000 Received: (qmail 12603 invoked from network); 3 Aug 2011 14:33:09 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Aug 2011 14:33:09 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1QocVP-0002H5-GY; Wed, 03 Aug 2011 14:33:07 +0000 Date: Wed, 03 Aug 2011 14:33:00 -0000 From: "Joseph S. Myers" To: Rainer Orth cc: gcc-patches@gcc.gnu.org, Paolo Bonzini , Ian Lance Taylor , trevor_smigiel@playstation.sony.com, dje.gcc@gmail.com, uweigand@de.ibm.com Subject: Re: CFT: [build] Move fp-bit support to toplevel libgcc In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00332.txt.bz2 On Wed, 3 Aug 2011, Rainer Orth wrote: > * Even worse, there are a couple of formats/targets that do use > fp-bit.c, don't yet define QUIET_NAN_NEGATED, but have qnan_msb_set = > false: > > qnan_msb_set uses fp-bit > > mips_single_format false x > spu_single_format false x > mips_double_format false x > mips_extended_format false x > mips_quad_format false x > vax_f_format false 00 > vax_d_format false 00 > vax_g_format false 00 > arm_half_format false ? > > So such a change would mean a change of behavior for spu and arm > targets. The SPU format doesn't support NaNs, so the value of this field isn't particularly meaningful for SPU. I'm not clear why SPU is actually using fp-bit; what functions from fp-bit will actually end up getting used by code built for SPU, and how close does fp-bit get to the required semantics? arm_half_format is another no-NaN format, and fp-bit does not provide any operations for it (it's a storage format only, not an arithmetic format, and conversions are provided by config/arm/fp16.c). So there should be no behavior change for ARM at all (only the definitions for the modes used by fp-bit are relevant, and HFmode isn't one of those). But, yes, any change to avoid defining QUIET_NAN_NEGATED specially would best be kept separate. -- Joseph S. Myers joseph@codesourcery.com