From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations? Date: Sat, 04 Jul 2020 17:05:20 -0400 Message-ID: References: <3A9CC2A3-8307-47B2-8D80-795C0AF020E1@acm.org> <0433A879-C98D-4B1A-B85C-A15DA9289099@acm.org> <1621669100.2102667.1593639091621@mail.yahoo.com> <775819003.2516724.1593687594435@mail.yahoo.com> <5F2B4684-34D1-4474-8909-9F435369FE54@acm.org> <705260433.2731607.1593698199171@mail.yahoo.com> <6CF8EE58-9A49-40E7-AA86-48AB39BF94BA@acm.org> <28B19D86-343C-4126-B95F-1F38735F73F2@acm.org> <1288c6a5-545b-f68c-ff6b-7683db3e54c1@cs.ucla.edu> <0AF276D8-FB28-4745-AAE4-DC30E0441F89@acm.org> <793d67e0-68a0-fc53-89a9-0902747d6389@cs.ucla.edu> <83zh8ftfwr.fsf@gnu.org> <672f15b0-04f9-e884-4815-85ca1d1af9bb@cs.ucla.edu> <6d8ba3b1-86b8-3dc8-3d80-17222d436b80@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26481"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: mattiase@acm.org, Paul Eggert , andrea_corallo@yahoo.it, 42147@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 04 23:28:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jrphm-0006lk-7q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jul 2020 23:28:14 +0200 Original-Received: from localhost ([::1]:48066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrphl-0000D9-8B for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jul 2020 17:28:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jrphb-0000Ag-K6 for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2020 17:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48213) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jrphb-0003Bm-B1 for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2020 17:28:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jrpMH-0008Ti-JN for bug-gnu-emacs@gnu.org; Sat, 04 Jul 2020 17:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jul 2020 21:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42147 X-GNU-PR-Package: emacs Original-Received: via spool by 42147-submit@debbugs.gnu.org id=B42147.159389673332554 (code B ref 42147); Sat, 04 Jul 2020 21:06:01 +0000 Original-Received: (at 42147) by debbugs.gnu.org; 4 Jul 2020 21:05:33 +0000 Original-Received: from localhost ([127.0.0.1]:59750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrpLo-0008T0-Si for submit@debbugs.gnu.org; Sat, 04 Jul 2020 17:05:33 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrpLl-0008Sm-W3 for 42147@debbugs.gnu.org; Sat, 04 Jul 2020 17:05:31 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 840EF80599; Sat, 4 Jul 2020 17:05:24 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7E772806CD; Sat, 4 Jul 2020 17:05:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1593896722; bh=eDjE6Ou0HnIZRINfBI6K8bCGLthZmIlWZems7kb+2k0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=oq6D01TX2/OFg1MU0IKlJzNWnWzq8txqR491drLDRbw04aTmEfZ94CeWgeN4wtd7v GzGep7hOIFGbxUV734Sr82ewioKgeY5kEOwlteJ8KkR6ZfQMWWf5ePY/fHm/91WWL8 NLSj5zdUqeMEayfUbnAeqtKUW+gfunw+weXsfeEQmPkyqnZvVYptIpCvAXj16uLkGv 4aCbbdyjD8v/Tm3lr4d9uuSl8n5cTgGI5cXVIit7JNUObyCvRLIt0GF5hwJgYRGUcC Rzt3vxgdho1GrVJc9zvziNc4iMt0lUWjaLU+35tDzUtUOZeN5ifJrQ4v5EHNrtaoO4 9QxrvoCkHt1nw== Original-Received: from alfajor (unknown [157.52.0.200]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2E0AA120873; Sat, 4 Jul 2020 17:05:22 -0400 (EDT) In-Reply-To: (Pip Cet's message of "Sat, 4 Jul 2020 18:37:16 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:182718 Archived-At: > So it's a GCC bug? Wouldn't it be better to fix that? Not really, no: the x87 hardware makes it difficult to get the exact behavior of 64bit floats, so either you live with "almost" the right behavior or you don't use the x87 hardware (which on pre-SSE2 hardware implies a massive slow down on floating point operations). >> Several GNU/Linux distributions have already dropped support for x86-only >> hardware like the circa-2001 Intel Mobile Pentium III-M in your laptop. On the >> distributions that still support i686, you can still build and run Emacs on your >> laptop (which has SSE but not SSE2) by configuring with CFLAGS='-msse >> -mfpmath=sse -fexcess-precision=standard'; this should avoid some (but not all) >> of the rounding problems. If I need to change the flags, then I'm much more likely to just use the "normal" compilation option: I actually couldn't care less about the potential differences in rounding. I'm actually not completely sure why we care about those minor rounding differences. After all, even if we use SSE2, there's no guarantee that the output of `sin` in one version of Emacs will be exactly the same as in another version of Emacs. And while I know that there's some hope that those differences will disappear in some distant future (since someone finally figured out how to implement `sin` efficiently with perfect rounding), I don't think we'll be able to rely on that any time soon, and I don't see why `+` should not be allowed to vary wile `sin` is. Stefan