From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62167 invoked by alias); 12 Jan 2017 23:30:33 -0000 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 Received: (qmail 62141 invoked by uid 89); 12 Jan 2017 23:30:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=riscv*-*-linux*, riscv**linux*, telf, sNaN X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jan 2017 23:30:17 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1cRoou-0000LT-Iu from joseph_myers@mentor.com ; Thu, 12 Jan 2017 15:30:12 -0800 Received: from digraph.polyomino.org.uk (137.202.0.87) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 12 Jan 2017 23:30:08 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1cRoon-0006rK-7n; Thu, 12 Jan 2017 23:30:05 +0000 Date: Thu, 12 Jan 2017 23:30:00 -0000 From: Joseph Myers To: Palmer Dabbelt CC: , Andrew Waterman , Subject: Re: [PATCH 3/6] RISC-V Port: libgcc In-Reply-To: <20170112023038.13449-4-palmer@dabbelt.com> Message-ID: References: <20170112023038.13449-1-palmer@dabbelt.com> <20170112023038.13449-4-palmer@dabbelt.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-01/txt/msg00875.txt.bz2 On Wed, 11 Jan 2017, Palmer Dabbelt wrote: > +riscv*-*-linux*) > + tmake_file="${tmake_file} t-softfp-sfdf riscv/t-softfp${host_address} t-softfp riscv/t-elf riscv/t-elf${host_address}" > + extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o crtendS.o crtbeginT.o" > + md_unwind_header=riscv/linux-unwind.h > + ;; > +riscv*-*-*) > + tmake_file="${tmake_file} t-softfp-sfdf riscv/t-softfp${host_address} t-softfp riscv/t-elf riscv/t-elf${host_address}" > + extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o" > + ;; This looks like you're building soft-fp functions into libgcc for all types whether or not you have hardware floating point support for them. If your ABIs are such that hardware and software floating point are ABI compatible at the function call level, then both copies of libgcc (the shared library, at least) should indeed have the same ABI (so a soft-float program can run with a hard-float copy of libgcc) - but for the hardware types, it's better to use t-hardfp. If they are not ABI compatible, it's best for libgcc to contain only the functions that are actually needed. That is, in general, it only needs to contain functions that are not implemented in hardware, or are implemented in hardware but might not be implemented in hardware for some configurations using the same ABI (and in the latter case, the t-hardfp implementations are preferred). > +#define _FP_NANFRAC_S ((_FP_QNANBIT_S << 1) - 1) > +#define _FP_NANFRAC_D ((_FP_QNANBIT_D << 1) - 1), -1 > +#define _FP_NANFRAC_Q ((_FP_QNANBIT_Q << 1) - 1), -1, -1, -1 This is different from the default NaN the specification says is used by hardware (all mantissa bits clear except for the MSB used to indicate a quiet NaN). I'd expect the soft-fp configuration to make the same choices here as hardware. > +#define _FP_NANFRAC_S ((_FP_QNANBIT_S << 1) - 1) > +#define _FP_NANFRAC_D ((_FP_QNANBIT_D << 1) - 1) > +#define _FP_NANFRAC_Q ((_FP_QNANBIT_Q << 1) - 1), -1 Likewise. > +#define _FP_KEEPNANFRACP 1 And since the hardware semantics don't propagate payloads I'd expect this to be zero, and ... > +/* From my experiments it seems X is chosen unless one of the > + NaNs is sNaN, in which case the result is NANSIGN/NANFRAC. */ > +#define _FP_CHOOSENAN(fs, wc, R, X, Y, OP) \ ... this to use a canonical NaN unconditionally, so that again you do the same as hardware (the comment here is actively misleading in this case as it describes something contrary to the hardware specification as being what experiments show hardware does). > +#define FP_ROUNDMODE (_fcw >> 5) I'm unclear from the specification whether the high 24 bits of fcsr are architecturally defined always to read as zero, or whether that's only the case in present architecture versions and they are reserved for possible future feature additions. If the latter, it would seem desirable to mask the result of shifting so existing binaries using the soft-fp code continue to work on future hardware that might set some of the high bits. > +#define __LITTLE_ENDIAN 1234 > +#define __BIG_ENDIAN 4321 > + > +#if defined __big_endian__ > +# define __BYTE_ORDER __BIG_ENDIAN > +#else > +# define __BYTE_ORDER __LITTLE_ENDIAN > +#endif As far as I can tell the port is always little-endian and there is no __big_endian__ macro, so that #if should not be there. -- Joseph S. Myers joseph@codesourcery.com