the "gcc.c-torture/execute/ieee/20000320-1.c" test case fails if compiled with sx-gcc

[GoogleCodeExporter]

Currently, the "gcc.c-torture/execute/ieee/20000320-1.c" test case fails
even if optimization is turned off (i.e. the "-O0" switch is used).

It looks like this issue is contributed to the fact that the SX's "cvs"
instruction for converting double to float behaves a little different than
the gcc expects.

Original issue reported on code.google.com by nou...@gmail.com on 15 Dec 2008 at 12:53

[GoogleCodeExporter]

If I replace the "cvs" instruction with the "__truncdfsf2" function from soft-fp
library. The test case above passes.

Do you think it would make sense to replace the "cvs" instruction with the
"__truncdfsf2" function?

Original comment by nou...@gmail.com on 15 Dec 2008 at 12:56

[GoogleCodeExporter]

how differently? truncating IEEE754 DF to IEEE754 SF should be a rather 
standardised
procedure. why is cvs result wrong?

I mean, we can't really use sw arithmetic all over - why have FP support in hw 
at
all, then?

Original comment by jmoc...@gmail.com on 15 Dec 2008 at 1:15

[GoogleCodeExporter]

Well if we truncate the "0x3690000000000001" hex representation of double (this 
hex
equals to the "7.0064923216240870e-46" double) to float we get the following 
results:
* we get "0x00000000" if we use "cvs" SX instruction (test FAILS)
* we get "0x00000001" if we use the "__truncdfsf2" function from soft-fp

I believe the issue lies in the fact that the "7.0064923216240870e-46" number 
is too
small to be represented with floats (we get underflow). By playing a little 
with the
online IEEE fp converter (a very useful tool when working with IEEE floating 
point
numbers) on http://babbage.cs.qc.edu/IEEE-754/, I noticed that 
"0x3690000000000001"
double is converted to "0x00000000" when no rounding is used and is converted to
"0x00000001" when rounding is used.

So the "cvs" most likely doesn't use rounding when converting DF to SF which is 
why
it gets different result as "__truncdfsf2".

Another thing: judging by the comments int the test case "20000320-1.c", its 
purpose
is to "test rounding numbers to the nearest representable mode, the most common 
IEEE
rounding".

Original comment by nou...@gmail.com on 15 Dec 2008 at 2:01

[GoogleCodeExporter]

From the "Chapter 3: Data Format and Arithmetic Operations" of the "SX-8 CPU
Functional Description Manual" I got the following paragraph:

    "The floating-point data format of the SX architecture is different from the 
    format of the IEEE754 standards in the aspect that each of the denormal numbers 
    (E=0 and F0) is handled as zero in the SX architecture."

This is why the test fails: gcc expects the denormal floats to be rounded 
whereas
SX's "cvs" instruction treats them as zero.

Original comment by nou...@gmail.com on 17 Dec 2008 at 4:25

[GoogleCodeExporter]

This issue is fixed in r182.

Original comment by nou...@gmail.com on 19 Dec 2008 at 1:56

• Changed state: Fixed