GNU bug report logs - #42147
28.0.50; pure vs side-effect-free, missing optimizations?

Previous Next

Package: emacs;

Reported by: Andrea Corallo <andrea_corallo <at> yahoo.it>

Date: Tue, 30 Jun 2020 22:28:02 UTC

Severity: normal

Found in version 28.0.50

Done: Mattias EngdegÄrd <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Pip Cet <pipcet <at> gmail.com>
Cc: mattiase <at> acm.org, Paul Eggert <eggert <at> cs.ucla.edu>, andrea_corallo <at> yahoo.it, 42147 <at> debbugs.gnu.org
Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?
Date: Sat, 04 Jul 2020 17:05:20 -0400
> 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





This bug report was last modified 4 years and 282 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.