disagreement in converting float32 result to float64 on 32-bit platform about julia HOT 15 CLOSED

Might this have anything to do with the gcc optimization bug mentioned in the fdlibm readme?

from julia.

Very likely. I tried the libm version and it doesn't have this issue.

from julia.

Jeff, can you check if this is fixed by compiling fdlibm with -O1 instead of -O2?

from julia.

-O1 did not fix this, but it did fix the other one.

from julia.

What am I smoking, it can't be the same bug, since this is calling logf, the float32 version, which already has the pointer cast bug fixed.

from julia.

OK, this is just the classic extended precision issue. I can fix it by replacing

return y;

with

volatile float x;
x=y; return x;

in the fdlibm code.
Inside ndigf's llvm-generated code the result stays in an extended-precision register and so can be converted to float64 without first rounding to float32.
So what should we do? I could modify our code generator to force rounding of results returned by C functions.

from julia.

I think always rounding is the right thing to do. Consistency and determinism is more important than keeping extra bits around. This same issue has already caused both Java and PHP to have DOS bugs in the past few months, let's learn the lesson from them.

from julia.

I agree that let's go for consistency. That crlibm presentation discusses this issue.

Best to also check with Alan on this issue. He is probably not reading this thread.

-viral

On Jun 15, 2011, at 12:41 PM, StefanKarpinski wrote:

I think always rounding is the right thing to do. Consistency and determinism is more important than keeping extra bits around. This same issue has already caused both Java and PHP to have DOS bugs in the past few months, let's learn the lesson from them.

Reply to this email directly or view it on GitHub:
#41 (comment)

from julia.

He can't actually read this thread — this is private and AFAIK, Alan doesn't have a GitHub account.

from julia.

Thanks for adding the test. Alas on i386 systems, using bitcast instead of the volatile store/load sequence flunks the test. I'll poke around some more.

from julia.

We should bring this up on the llvm list.

from julia.

I concur, and sent a note to [email protected].

from julia.

Maybe try bitcasting through an int32?

from julia.

I think we're going to end up wanting to take different actions depending upon whether the target has excess precision, with the goal of presenting least obfuscated code to the LLVM optimizer. I'm guessing that we can detect the presence of excess precision from LLVM somehow since Clang must detect it to set FLT_EVAL_METHOD for C99.

[pao: fixed link to FLT_EVAL_METHOD]

from julia.

It seems this is not an issue at all on 64-bit, so maybe the first move is just to disable this hack on anything x86-64.

from julia.