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: Mattias Engdegård <mattiase <at> acm.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 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, 4 Jul 2020 21:01:44 +0200

4 juli 2020 kl. 19.00 skrev Paul Eggert <eggert <at> cs.ucla.edu>:

> Not as far as I know. GCC's -fexcess-precision=standard option tries to do that,
> by causing GCC to convert 80-bit results to 64-bit results after every 80-bit
> operation.

Not quite after every operation:

  y = x * a + b;

With -fexcess-precision=standard, the 80-bit result of the multiplication will be used in the addition. With -ffloat-store, a 64-bit store and reload will take place between the two operations, forcing excess fraction bits to be discarded.

Another option is to set the Precision Control field in the x87 control word to 53-bit precision; that pretty much eliminates double rounding, but still uses the extended exponent range (only matters in overflow and underflow cases). And it may confuse libc's carefully crafted floating-point functions.
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.