From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19335 invoked from network); 1 Jan 2024 17:47:53 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2024 17:47:53 -0000 Received: (qmail 26236 invoked by uid 550); 1 Jan 2024 17:46:41 -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 26204 invoked from network); 1 Jan 2024 17:46:40 -0000 Date: Mon, 1 Jan 2024 12:47:53 -0500 From: Rich Felker To: John M , musl@lists.openwall.com Message-ID: <20240101174752.GL4163@brightrain.aerifal.cx> References: <20240101134309.GN1427497@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240101134309.GN1427497@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Wrong rounding in printf when precision is not set to max On Mon, Jan 01, 2024 at 02:43:09PM +0100, Szabolcs Nagy wrote: > * John M [2024-01-01 10:11:09 +0100]: > > I noticed printf rounding wrongly when FPU Control Word[PC] != 11. > > > > I do not think my workaround is a fix, it just serves to show where the > > reduced precision breaks the rounding. > > > > Do you consider this a bug? > > the precision control setting of x87 on i386 and x86-64 is ABI > and on linux must be double extended (64bit pc=0b11, not 53bit > pc=0b10 nor 24bit pc=0b00) > > if you change the setting then the behaviour is undefined, it's > not just the libc that may misbeahave, but the compiler and > other libraries too. Exactly. It's UB to call any standard library code (regardless of whether you expect it uses floating point or not) if the fpu control word is set to a non-ABI-conforming value. If anything wants to use alternate modes that don't match the ABI, it needs to save/reset/restore the value around every point at which it uses library functions. Note that, even then, there are lots of gotchas. The x87's "single" and "double" modes are not actually IEEE single and double, but nonstandard types with the IEEE significand precision but excess exponent range that's truncated via double-rounding whenever the intermediate is spilled to memory. This will induce UB-like runaway wrong behavior in code generated by a compiler that's not aware of these issues, since it will effectively be able to prove 1.0==0.0. So it is probably strongly advisable never to set these modes at all. Rich