M.Drochner@fz-juelich.de said:
> gcc fails to emit instuctions which set the i387 floating point
> control word to 64-bit rounding where "long double" data types are
> used
After some research I came to the conclusion that gcc doesn't
intend to do so. (It might kill performance anyway.)
It does instead live with the fact that the FPU does only
provide IEEE "double" accuracy, even with "long double"
variables. Since the standards (ISO C and IEEE754) do not
require that "long double" is any better that "double", this
is legal.
> setting TARGET_96_ROUND_53_LONG_DOUBLE
> in the gcc configuration doesn't help
What this does is to dumb down compile time calculations
on "long double" types to use 53-bit accuracy (while using
the 80/96-bit format where data are put to .data).
So this should be set for NetBSD/i386 (and amd64) for
consistency between compile-time and runtime calculations,
otherwise we might see different behaviour depending on
eg optimization levels.
> Try the program below (taken from an sqlite3 selftest).
sqlite3's assumption that use of "long double" will fix
the flaws of the conversion algorithm is not portable.
I've filed a bug report there (#2570).
This further means for NetBSD/i386:
-Use of "long double" is just a waste of memory, and memory
bandwidth.
+It is almost as easy to implement expl(), logl() and all the other
"long double" variants of math functions on i386 as it is for
platforms where "long double" is identical to "double": just
use wrappers which convert arguments, no need to implement
algorithms which provide higher accuracies.
best regards
Matthias
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Baerbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)