From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38670 invoked by alias); 29 Jan 2018 18:26:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 38657 invoked by uid 89); 29 Jan 2018 18:26:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=resulted, him X-HELO: mail-pf0-f174.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=DKnh8ObYC1yyl8AR8wjeaUo027LW094cUNnxssWiMUE=; b=S7NHVZHwVWODpAMRpS51kQsFBEG5oOCh24L10xng8f0EdNp/A6cIC4/PgElfVJwChi eJnMHZ7LXYyO/O8ghDgWSbrlvMdFHiH3ZCqSODGzMKoM+UMzfWvCxhePWLM0efCE4Yrj MfRQ1VvWYTF96HuVzEGwSoeiw7wXe41wp56wjNT8LlyZ4wAkZahIAfbaRrdyoyJCkVzh 0Yfn+Pju4fI8IraK9CPJPELh7mQWYyXMPP74DkiHe0XnkFXuzgzxj131q9W4j7vAaWj2 UemkDyJW5X2bZoVilnFK0M+10k8RpsaEmT8hAzFjnO6WFjOIdASkWhc5/8KrWmySFooj KGkQ== X-Gm-Message-State: AKwxyte7lH/HRJ5QgUIA1u+P0yjKY10YPElv7Isj2cGSAyNzfp6B3yj1 ZivYx0Ja3kyp+wmkF+4+pR4UtLtcPbY= X-Google-Smtp-Source: AH8x224rlxNr9dOxu5UVlNZR/Jg1R3IY27dobunFkrsZDbRSfIfoT8x8m4fVaevN5HNnwwqSyO0Dzw== X-Received: by 2002:a17:902:68ca:: with SMTP id x10-v6mr22121049plm.367.1517250377269; Mon, 29 Jan 2018 10:26:17 -0800 (PST) Date: Mon, 29 Jan 2018 22:01:00 -0000 X-Google-Original-Date: Mon, 29 Jan 2018 10:21:24 PST (-0800) Subject: Re: RISC-V glibc port, v7 In-Reply-To: CC: libc-alpha@sourceware.org From: Palmer Dabbelt To: joseph@codesourcery.com, Andrew Waterman Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-01/txt/msg01094.txt.bz2 On Mon, 29 Jan 2018 07:52:35 PST (-0800), joseph@codesourcery.com wrote: > Please commit with the changes requested in review of patches 5 and 6 > (note the latter applies to more patches than just patch 6) - and no other > changes. Do not send a v8 patch series. Any further changes should be > sent separately once the initial port has been committed, and are subject > to the usual subsystem maintainer rules. OK, makes sense. > Once you've committed v7 with the fixes noted, here are some further > questions that may require followup patches: > > * An earlier set of test results posted had strfromf failures, which then > disappeared in a later set of test results without any strfromf-related > patches that I could see. My understanding was that those failures > probably resulted from the RISC-V rule that most floating-point > instructions with NaN results produce a canonical NaN with positive sign - > thus, where strfromf converts a float argument to double (in order to use > printf code that doesn't handle float arguments) it loses the sign of the > original float NaN. Did I misunderstand this rule in the RISC-V ISA > manual? I was expecting that you'd need e.g. a hook for the strfromf > conversion from float to double (inline function in a new sysdeps header) > where the generic version just does a trivial conversion but the RISC-V > version handles NaNs specially to preserve the sign. We fixed a handful of NaN-related issues in both GCC and QEMU, so it's possible one of these made the failures go away (and possible erroneously). I'll take a closer look. > * You're using fmax and fmin instructions to implement the corresponding > libm functions. As far as I can see, this would be correct by the > semantics of those instructions in the v2.2 ISA manual - but the current > git version of the ISA manual changes the instruction semantics so that > they would no longer be correct for those functions (and would instead be > correct for fmaximum_num and fminimum_num, in the proposed changes to TS > 18661-1 to support IEEE 754-2018, but we don't have those functions in > glibc). Now, if hardware may implement either v2.2 or v2.3 semantics, > that makes those instructions fairly useless for glibc, in the absence of > a way to mark a glibc binary as requiring a particular ISA version; if > hardware implements only v2.3, the instructions are still inappropriate > for fmax/fmin/fmaxf/fminf (but could be used in future for fmaximum_num > and fminimum_num, if and when those are added to C2x and to glibc). I think this is a question for Andrew. I'd added him to the email in case he wasn't looking.