-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
disagreement in converting float32 result to float64 on 32-bit platform #41
Comments
Might this have anything to do with the gcc optimization bug mentioned in the fdlibm readme? |
Very likely. I tried the libm version and it doesn't have this issue. |
Jeff, can you check if this is fixed by compiling fdlibm with -O1 instead of -O2? |
-O1 did not fix this, but it did fix the other one. |
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. |
OK, this is just the classic extended precision issue. I can fix it by replacing return y; with volatile float x; in the fdlibm code. |
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. |
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:
|
He can't actually read this thread — this is private and AFAIK, Alan doesn't have a GitHub account. |
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. |
We should bring this up on the llvm list. |
I concur, and sent a note to |
Maybe try bitcasting through an int32? |
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] |
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. |
…ence only on 32-bit X86.
…g#41 to use volatile store/load on 32-bit x86 only.
…g#41 to use volatile store/load on 32-bit x86 only.
…g#41 to use volatile store/load on 32-bit x86 only.
Fix atbash-cipher test sets indentation
Fix world age problems when running tests
Without this change, the compiler fails to notice that `env_threads isa Int` in the fall-through case, leading to a union-split with a branch that is in fact unreachable: ``` 43 ┄ %109 = φ (#41 => %105, #42 => %108)::Union{Nothing, Int64} │ %110 = (%109 isa Int64)::Bool └─── goto #45 if not %110 ... 45 ─ %126 = π (%109, Nothing) │ Base.convert(Int64, %126)::Union{} └─── unreachable ``` Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
Without this change, the compiler fails to notice that `env_threads isa Int` in the fall-through case, leading to a union-split with a branch that is in fact unreachable: ``` 43 ┄ %109 = φ (#41 => %105, #42 => %108)::Union{Nothing, Int64} │ %110 = (%109 isa Int64)::Bool └─── goto #45 if not %110 ... 45 ─ %126 = π (%109, Nothing) │ Base.convert(Int64, %126)::Union{} └─── unreachable ``` After this change, the union-split is eliminated. Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
Without this change, the compiler fails to notice that `env_threads isa Int` in the fall-through case, leading to a union-split with a branch that is in fact unreachable: ``` 43 ┄ %109 = φ (JuliaLang#41 => %105, JuliaLang#42 => %108)::Union{Nothing, Int64} │ %110 = (%109 isa Int64)::Bool └─── goto JuliaLang#45 if not %110 ... 45 ─ %126 = π (%109, Nothing) │ Base.convert(Int64, %126)::Union{} └─── unreachable ``` After this change, the union-split is eliminated. Co-authored-by: Jeff Bezanson <jeff.bezanson@gmail.com>
This was seen on a 32-bit Xeon system:
The last answer is correct, the middle one is the float64 conversion of the correctly-rounded float32 answer, and the first one is something strange.
Looks like the float64 answer with the last 13 bits zero'd.
Happens with some functions, e.g. log and sin, but not with sqrt.
The text was updated successfully, but these errors were encountered: