Comments (15)
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.
Related Issues (20)
- We should have no throw `setindex!` for existing indices. HOT 2
- whether `Core.checked_dims` decides to throw depends on dimension order (for empty arrays) HOT 2
- colonful `reshape` may spuriously throw `DivideError`
- GC and multithreading. Strange behaviour. HOT 3
- Update main entry-point docs to use lowercase `args` HOT 2
- Segmentation fault with Distributed when --threads is set HOT 2
- Julia is incorrectly passing arguments to C on Apple M1 HOT 11
- Strange code generation with `unsafe_trunc` and dynamic dispatch HOT 15
- Segfault during push!() if using a large struct in 1.10 due to elsize overflow HOT 7
- segfault in `jl_datatype_layout` while constructing `Memory` HOT 5
- Slow/delays in REPL upon start HOT 3
- Creating struct instances is slow when another inner constructor returns `undef` fields HOT 4
- Possible bug when constructing a string from an array of characters HOT 4
- Too long stack traces at the REPL shell mode HOT 1
- 'make test' fails for julia-1.11.0-beta1 HOT 6
- Identical calls to getindex not optimised out HOT 6
- 20x slowdown when using `Int32` instead of `Int16` HOT 2
- Segfault during `eval` HOT 6
- `supertype` is documented to only accept a DataType when it also accepts other types HOT 2
- `det` inexact for complex skew symmetric matrix HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from julia.