From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id A954220FF4 for ; Wed, 29 May 2024 17:13:55 +0200 (CEST) Received: (qmail 19778 invoked by uid 550); 29 May 2024 15:13:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19683 invoked from network); 29 May 2024 15:13:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716995622; x=1717600422; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3d3znEcAy8Oi3+n1oHWiaCMdaCHryWqJZaOwZBmVWyU=; b=L+8iZ/IVjtJNVpeu+9uLbQPyueeTsDX/VAqqz3yWVpGc2bLNF0vMn49nf/IJVwbRb2 hIgbzpS0WtlGmkn/IX2ek02/Ve+LT6MpFbP0k5X949vphyhDTbnIrLsv9BoD/oM2ZUGr uvCXbZXYcLihWVWIPHd9VIJobPoS67DDhYNWjTgw1D3xqoUqBx8LJhqMJPuonzKKZHkx tWsXO+GqWyIr8bciWoQO+CVxPQJ9ci+xB2Wj+6E2o1SCglCmcDf5W0LXpA5iXMk0+W0M FDk89Uyw7k99BUNEUUlMafwFVTLijJd14ugnSN9HT82LN06OPCihlGIl7LK/18CKG4yh 8n6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716995622; x=1717600422; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3d3znEcAy8Oi3+n1oHWiaCMdaCHryWqJZaOwZBmVWyU=; b=O7H4904cpiy0j3rSFZVi/8EMpFkIRQPOIj+MCc0CBAarobouDsrm4mWvqouNsUa6+G 4dODntvMfiZwNYsJaJykOUsM/32LrGEborXRCuf5JspEJ/rr1HVCmUAMXDfwWTgaCEfy mzdV4jrF4X6YnxV+WuW9RmKGhZ2PgLqKrnmhmxcRGhhcXs6YO8B6YDv7bsjzlNqm0i0g pW2grolUCJKa7rN07AoT6lPhapgYBTfgyJYrLlf9sFYIyRUWMWXNLWirUn5m78YNcYM1 kWw9r87W0CsVv0Y9Oo/cUJTQPhpr4NJ2/pqcfCSkBacEUi3/vQ3Sn1MqsFGVpHIi5P0o 0p0Q== X-Gm-Message-State: AOJu0YyEQp1dRKH171evD+RxmQixxgzJyKNUX3kjDJVMXR2QIn1G7CU9 Lx17HjGNk2QmCsnaHckjbc7Ddv20WIjh+9U4+tEd+A7ecsqWyfOcrAk8RCm3/fj5i4vfeM6tiP1 6rkbCMOVBO0Pracf58v56CbyksezIXGMzO2Vhasz0QzswBxSrJ7SHqpI= X-Google-Smtp-Source: AGHT+IGZNmrwghCB4nr/4Y954sJsqgk1oArqam9s5SdP5JM2YVyPBoVEguhHJAYbsYc8Fotin+fLqDM2Vq1nXB3x5eA= X-Received: by 2002:a05:622a:2483:b0:43f:7b35:c5e2 with SMTP id d75a77b69052e-43fe0f636e1mr3368381cf.16.1716995621535; Wed, 29 May 2024 08:13:41 -0700 (PDT) MIME-Version: 1.0 References: <724090dc-83e7-4f40-9ff2-1a60196b9966@gmail.com> <20240529013411.GF10433@brightrain.aerifal.cx> <20240529125904.GC31267@brightrain.aerifal.cx> In-Reply-To: <20240529125904.GC31267@brightrain.aerifal.cx> From: James Y Knight Date: Wed, 29 May 2024 11:13:12 -0400 Message-ID: To: musl@lists.openwall.com Cc: Nikolaos Chatzikonstantinou Content-Type: multipart/alternative; boundary="0000000000001ab58a061999321d" Subject: Re: [musl] Re: Implementing csqrtl() --0000000000001ab58a061999321d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 29, 2024 at 8:58=E2=80=AFAM Rich Felker wrote= : > existing > compilers all just wrongly reorder things with respect to fenv access > and break it and don't care to fix this (probably because it would hurt their benchmarks to fix it the right way). FWIW (not that it changes the recommendation in this instance), Clang has put a bunch of work into addressing this and other floating-point compliance issues over the past decade. It *is* considered an important thing to implement correctly, and I believe it generally is working on the common architectures, since a few years ago. Unfortunately it's not yet implemented on every architecture. There is no impact on benchmarks by implementing fenv correctly, because, per the C standard, it is undefined behavior to access the floating-point status flags or to execute any code with non-default floating-point control modes in effect unless "fenv_access" is enabled -- either using "#pragma STDC FENV_ACCESS ON" in the code, or via an implementation-defined mechanism to set the default to on (in clang, the command-line option "-ffp-model=3Dstrict"). Because it's opt-in, only the code which actually requires it takes the performance hit. --0000000000001ab58a061999321d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 29, 2024 at 8:58=E2=80=AF= AM Rich Felker <dalias@libc.org&g= t; wrote:
existi= ng
compilers all just wrongly reorder things with respect to fenv access
and break it and don't care to fix this (probably because it would=C2= =A0
hurt thei= r benchmarks to fix it the right way).

FWIW= (not that it changes the recommendation in this instance), Clang has put a= bunch of work into addressing this and other floating-point compliance iss= ues over the past decade. It is considered an important thing to imp= lement correctly, and I believe it generally is working on the common archi= tectures,=C2=A0since a few years ago. Unfortunately it's not yet implem= ented on every architecture.

There is no impact on= benchmarks by implementing fenv correctly, because, per the C standard, it= is undefined behavior to access the floating-point status flags or to exec= ute any code with non-default floating-point control modes in effect unless= "fenv_access" is enabled -- either using "#pragma STDC FENV= _ACCESS ON" in the code, or via an implementation-defined mechanism to= set the default to on=C2=A0(in clang, the command-line option "-ffp-m= odel=3Dstrict"). Because it's opt-in, only the code which actually= requires it takes the performance hit.
--0000000000001ab58a061999321d--