-
Notifications
You must be signed in to change notification settings - Fork 180
Out of range float casts miscompilation #635
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
Labels
Comments
mathstuf
added a commit
to mathstuf/gccrs
that referenced
this issue
Nov 1, 2021
The set of inline modules is required to find the expected location of a module file. Track this information with an RAII object (`InlineModuleStackScope`) and pass it down to any out-of-line modules so that, when requested, the set of inline modules can be added to the search path. Fixes: Rust-GCC#635 Signed-off-by: Ben Boeckel <[email protected]>
I think the code to check for this is in the GCC TREE_OVERFLOW flags |
@bjorn3 I have a branch of code to fix this but the part about Saturating to f32::INFINITY I might leave out for the first PR, I have code to catch this case but I wonder is there documentation that I can reference on this saturating to infinity? |
philberty
added a commit
that referenced
this issue
Jan 5, 2022
This checks that the literal value is within the bounds of their respective types. I have ommited code fixing the other issue in the bug report that overflow/max_val integers should be saturated to infinity when cast to REAL_TYPE's this seems like something we really should have documentation to reference in the code as to why this is the correct Rust behaviour. Addresses #635
This is the PR which originallt changed it from UB to saturating: rust-lang/rust#71269 |
philberty
added a commit
that referenced
this issue
Jan 5, 2022
This checks that the literal value is within the bounds of their respective types. I have ommited code fixing the other issue in the bug report that overflow/max_val integers should be saturated to infinity when cast to REAL_TYPE's this seems like something we really should have documentation to reference in the code as to why this is the correct Rust behaviour. Addresses #635
philberty
added a commit
that referenced
this issue
Jan 6, 2022
This checks that the literal value is within the bounds of their respective types. I have ommited code fixing the other issue in the bug report that overflow/max_val integers should be saturated to infinity when cast to REAL_TYPE's this seems like something we really should have documentation to reference in the code as to why this is the correct Rust behaviour. Addresses #635
bors bot
added a commit
that referenced
this issue
Jan 7, 2022
860: Add overflow checking on LiteralExpression r=philberty a=philberty This checks that the literal value is within the bounds of their respective types. I have omitted code fixing the other issue in the bug report that overflow/max_val integers should be saturated to infinity when cast to REAL_TYPE's this seems like something we really should have documentation to reference in the code as to why this is the correct Rust behaviour. Addresses #635 Co-authored-by: Philip Herron <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tried this code:
I expected to see this happen: Saturating to
f32::INFINITY
Instead, this happened: 9223372000000000000.0 is returned
Another case is
which should give an out of range error, but returns 0.0.
Meta
The text was updated successfully, but these errors were encountered: