From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id iAHMHfFzGGQcFAAASxT56A (envelope-from ) for ; Mon, 20 Mar 2023 15:55:45 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id qDfQHfFzGGR5DQAA9RJhRA (envelope-from ) for ; Mon, 20 Mar 2023 15:55:45 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1A117F71A for ; Mon, 20 Mar 2023 15:55:40 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1679324141; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=NLIjzotEFRChD88aneSTgrfgZxNZ/Z4Xs/gftVL6tDM=; b=mzmTat/4Sg/fd6u+AHgaXcBUX/T6Lj28FOGdXeJrCVTAJFidP17s0ty6ph347vbO5qGOyg PfrdQNpqTL9yNXgAUM2yXtGhZzvo7BTH+WIdG+UoGznKWvqJN5cBJ0XluXjwz/R2cV7W/N nZ3sErq5gEdrKtPAH9m5C2Gl4dxmjZdr9dqrAKG/P0UmHQkcr+65O5LFbM7bYShWgWSi0k S+LN6hx4bt0/zQ69q/bxy0FltMxxsQzkbriB4oFocZwI2x5UYP7coPKcEJDc6VLd3lJWxt +P5wv2Dn4lkqLrVtuv8b4OH4abijqk5mzVzBp6f7i4Ww0wNoAy27M7HKTLoQDg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1679324141; a=rsa-sha256; cv=none; b=mcDP+wWp0VvzTvLtAJTxZ/eOmHk8D0PXqGBW+0TqGN1/Vv7hiopUZVLWC93I1hHUrMt1NU rKV89P2x4DFb7Gl98gXXXqgo0CHONAPmpJCCYwBxcPgwHxIZHhZGba/IgEcR333BsBaU0n n4VyAyi67WUQNNuBXmKGsj+mUcYNpt6DIeSevlNQJOB80S6xhRqVJTOnlUAt5yAvCqj8OM UG+sh4yATlYsEeUuqOoHQ79X2U8vuqSl7bTxOT1gyc/RSWoIBBQvb1MYXvj8zf4Ya/yDcy 2oXH3xwm0AaG3s9VZ/gWZJm3En/RPJmfpTHKEMMQ5xCHbYcmIGDvaAUotjDBmg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1peGug-0008Nu-Oh; Mon, 20 Mar 2023 10:55:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1peGud-0008Ne-Hf for guix-devel@gnu.org; Mon, 20 Mar 2023 10:55:03 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1peGub-0003Ad-1N for guix-devel@gnu.org; Mon, 20 Mar 2023 10:55:02 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id EDAB41B49; Mon, 20 Mar 2023 15:54:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9oBL1_y7Jdj; Mon, 20 Mar 2023 15:54:54 +0100 (CET) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id A3EDF333; Mon, 20 Mar 2023 15:54:54 +0100 (CET) Date: Mon, 20 Mar 2023 15:54:53 +0100 From: Andreas Enge To: Michael Schierl Cc: guix-devel@gnu.org Subject: Re: Procps in core-updates Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="q2qMYh7Y/44Ye03h" Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=185.233.100.1; envelope-from=andreas@enge.fr; helo=hera.aquilenet.fr X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: X-Migadu-Queue-Id: 1A117F71A X-Spam-Score: -3.56 X-Migadu-Spam-Score: -3.56 X-Migadu-Scanner: scn0.migadu.com List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-TUID: vxocUjEJeJy1 --q2qMYh7Y/44Ye03h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello Michael, Am Sun, Mar 19, 2023 at 06:36:09PM +0100 schrieb Michael Schierl: > At the first printf, GCC knows that val still resides in some floating > point register of your CPU (be it SSE, MMX or x87 registers, depending > on the processor models your gcc targets). > Hardware floating point registers on x86 are a mess, and they usually do > not have the same precision as the IEEE floating point values that are > stored in variables (e.g. on the stack or heap), but are slightly more > precise. this is an interesting guess, and at least gives a hint of why things happen. I am attaching a simplified C file and the corresponding assembly output; which I cannot read, but there are differences between the two invocations of fprintf. Now to me this still looks like a GCC bug, which is supposed to honour the IEEE 754 standard for floating point as specified in the C99 standard (the compiler flag -std=gnu99 was used to compile the file) at least for "simple" operations. Comparisons should be exact. But I found this: https://gcc.gnu.org/wiki/FloatingPointMath "Note on x86 and m68080 floating-point math For legacy x86 processors without SSE2 support, and for m68080 processors, GCC is only able to fully comply with IEEE 754 semantics for the IEEE double extended (long double) type." So this appears to be a bug with a "wontfix" tag... And as indicated there, the compiler option -ffloat-store makes the problem go away! The weirdest thing is that actually the value is the integer 123. So it should be stored in any kind of register exactly. Thanks for making me learn something new! Actually I also found an upstream patch: https://gitlab.com/procps-ng/procps/-/issues/271 which I will apply now. Andreas --q2qMYh7Y/44Ye03h Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test_strtod_nol.c" #include #include #include "strutils.h" struct strtod_tests { char *string; long double result; }; struct strtod_tests tests[] = { {"123", 123.0}, }; int main(int argc, char *argv[]) { long double val; val = strtod_nol_or_err(tests[0].string, "Cannot parse number"); fprintf(stderr, "CMP %i\n", val != tests[0].result); fprintf(stderr, "CMP %i\n", val != tests[0].result); return EXIT_FAILURE; } --q2qMYh7Y/44Ye03h Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test_strtod_nol.o" ELF?J?l??_?W?Yo?-??5??N S?}r?t?}7??"??7?P?Z?(]aE@???OxI^@J+??C8:?3n?v??]??? ?('f???{????1Ru(?????F???????????{?KZed??/q?E'?????,gf_?k?6???>?/