From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53261 invoked by alias); 10 Dec 2019 18:39:20 -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 53253 invoked by uid 89); 10 Dec 2019 18:39:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: fmax/fmin sNaN compatibility question To: joseph@codesourcery.com (Joseph Myers) Date: Tue, 10 Dec 2019 18:39:00 -0000 From: "Ulrich Weigand" Cc: libc-alpha@sourceware.org In-Reply-To: from "Joseph Myers" at Dec 10, 2019 06:05:30 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 19121018-0012-0000-0000-00000373954B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19121018-0013-0000-0000-000021AF691E Message-Id: <20191210183910.D50BBD80305@oc3748833570.ibm.com> X-SW-Source: 2019-12/txt/msg00334.txt.bz2 Joseph Myers wrote: > On Tue, 10 Dec 2019, Ulrich Weigand wrote: > > > Joseph Myers wrote: > > > On Mon, 9 Dec 2019, Ulrich Weigand wrote: > > > > Do you know why the sample implementation was even updated then? > > > > If FP_SNANS_ALWAYS_SIGNAL is false, shouldn't the C11 method then > > > > still be OK? > > > > > > The canonicalize call is needed in general to avoid propagating > > > noncanonical DFP encodings, though not relevant for binary FP. > > > > But it does change the behavior for binary FP as well, as far > > as I can see: e.g. if both inputs are sNaNs, the C11 method > > would return one of those sNaNs unchanged, while the C2x method > > will return a qNaN (as the canonicalize call will quiet the > > sNaN it receives as input), right? > > The handling of sNaN is explicitly implementation-defined when > FE_SNANS_ALWAYS_SIGNAL is not defined, so that example implementation > should not be used to infer anything about how sNaN should be handled. OK, got it. I think it starts making sense now :-) Thanks for your help! Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com