[92] in Pthreads mailing list archive
Re: Linux ELF
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Thu Aug 17 15:09:10 1995
Date: Thu, 17 Aug 1995 14:48:43 -0400
From: Ken Raeburn <raeburn@cygnus.com>
To: hjl@nynexst.com (H.J. Lu)
Cc: pthreads@MIT.EDU
In-Reply-To: hjl@nynexst.com's message of Thu, 17 Aug 95 9:29:58 EDT
From: hjl@nynexst.com (H.J. Lu)
Date: Thu, 17 Aug 95 9:29:58 EDT
> I have, although I did use 2.6.3, an early ELF version from HJ Lu. Kernel
> versions I tested are 1.2.8,1.3.8 and 1.3.14. Only the floating point test
> fails to complete.
Fails to *complete* (i.e., runs forever), or completes with a failure
indication?
The reason of that failure is 10 byte long double is used internally
in x87. In any case, it is not recommended to use
double x, y;
.....
if (x == y)
{
...
}
What that test *should* be checking is that floating point state
(registers and fpu internal state) for each thread is preserved. I
couldn't see how to test that in a CPU-independent way without making
the assumption that a calculation could be run more than once and
still produce the same result. In this case, I think the equality
test is the only reasonable test to perform. *Any* difference
indicates something strange happening.
It may be the case, though, that truncation is only being performed in
some paths and not in others. It may even be the case that ANSI
permits that behavior.
I think the extra calls to sin() just before the comparison are an
attempt to flush out any register values, but since sin is just
another instruction on the x87, it probably isn't working. Perhaps a
"volatile double" value on the stack or in heap should be used for
storing the values; that ought to be enough to force the compiler to
store (and thus truncate) and re-load the value.
Ken
