Open GoogleCodeExporter opened 9 years ago
Well, as it turns out, the source of the problem isn't in assigning the values
to
"long double". The incorrect printout is there due to the disability of
SuperUX's
"printf" function to print "long double" (on SuperUX, "long double" are
represented
as 64-bit numbers).
Well, the "22_locale/num_get/get/char/10.cc" test case still fails due to the
incorrect handling of "long double" numbers. Wil have to search somewhere else
for
the cause.
Original comment by nou...@gmail.com
on 30 Jun 2009 at 12:04
Once again, I have correct myself... :)
The SuperUX's "printf" function does support the printout of "long double"
values,
but not in the standard IEEE format for quad precision numbers, but in SX's
format,
which is described in the "3.1.2 Floating-Point Data" section of the "SX-8 CPU
Functional Description Manual".
If we compile the program below with sx-gcc, it prints "SX IEEE QUAD PRECISON
ld =
1.000000" if executed on SuperUx.
Original comment by nou...@gmail.com
on 30 Jun 2009 at 12:59
Oh yeah, here is the proggie... :)
{{{
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
long double ld;
char* __sanity;
long *pld = &ld;
pld[0] = 0x3ff0000000000000;
pld[1] = 0x3cb0000000000000;
printf("SX IEEE QUAD PRECISON ld = %Lf\n", ld);
return 0;
}
}}}
Original comment by nou...@gmail.com
on 30 Jun 2009 at 1:01
As expected, this issue is fixed if we switch from the "FLOAT_MODE (TF, 16,
ieee_quad_format);" representation of quad precision floating point values to
"FLOAT_MODE (TF, 16, sx_quad_format);" in the "gcc/config/sx/sx-modes.def" file.
However before actually commit this change to the repository, we will hav to
perform
additional tests to make sure that we don't break something else.
Original comment by nou...@gmail.com
on 30 Jun 2009 at 4:24
test and fix for release. check if quad insns are implemented properly.
Original comment by jmoc...@gmail.com
on 9 Oct 2009 at 9:28
Original issue reported on code.google.com by
nou...@gmail.com
on 19 Jun 2009 at 1:53