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)