Sanitize non-NaN-boxed operands in divsqrt to return canonical qNaN#27
Open
emiliengnr wants to merge 1 commit into
Open
Sanitize non-NaN-boxed operands in divsqrt to return canonical qNaN#27emiliengnr wants to merge 1 commit into
emiliengnr wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello, here is a pull request for a bug I found.
fpnew_divsqrt_multideclares theis_boxed_iinput but never uses it, so a scalarfdiv.sorfsqrt.swhose source operand is not properly NaN-boxed is computed on the raw low 32 bits and returns an arithmetically wrong result with no trap, where the RISC-V D extension requires the canonical quiet NaN of the destination format. The fix substitutes the canonical qNaN for a badly boxed operand before the divsqrt pipeline, and skips the unused second operand onfsqrt.sso the square-root path stays correct. Found by differential testing of a cva6 + ara configuration against spike.Severity: Architectural correctness. Every
fdiv.s/fsqrt.swhose source FP register is not properly NaN-boxed returns a silently wrong result.