From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 12 06:49:58 2023 Received: (at 61586) by debbugs.gnu.org; 12 Mar 2023 10:49:58 +0000 Received: from localhost ([127.0.0.1]:59279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbJH4-0007pd-Bs for submit@debbugs.gnu.org; Sun, 12 Mar 2023 06:49:58 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:46920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbJH2-0007pL-8b for 61586@debbugs.gnu.org; Sun, 12 Mar 2023 06:49:57 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id E09E2A03; Sun, 12 Mar 2023 11:49:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr 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 lTSwdhYMApJR; Sun, 12 Mar 2023 11:49:49 +0100 (CET) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 41A8857C; Sun, 12 Mar 2023 11:49:49 +0100 (CET) Date: Sun, 12 Mar 2023 11:49:47 +0100 From: Andreas Enge To: Liliana Marie Prikler Subject: Re: BinaryEn Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61586 Cc: 61586@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Am Sun, Mar 12, 2023 at 09:16:45AM +0100 schrieb Liliana Marie Prikler: > Am Samstag, dem 11.03.2023 um 23:48 +0100 schrieb Andreas Enge: > > Hello Liliana, > Hi Andreas, please don't forget to add me in CC. ah, I thought that debbugs would automatically redispatch the mail to everybody who contributed to the report. > The problem here is that expressions like: > double a, b, c; > c = sqrt(a * a, b * b); > can use 80 bit intermediaries on x87 chips, which they don't when using > SSE2 – hence the precision argument. You would have to redefine all > basic operations for your floating point (which would still be doable > in C++ due to operator overloading, but be a major pain in the butt to > do correctly and well-tested, hence the deference to SSE2, I believe). Hm, I thought that when using gcc and glibc, floating point operations now followed the IEEE-754 standard. Then it would not matter what the internal format is (except for special functions). Still, I wonder if it would not be possible to change the configure test so that the package compiles on 32 bit platforms; otherwise we would have to take them out from the supported systems. And that would not be better (assuming that the package passes its tests on these platforms, of course). Andreas