[General]: FP87::Round drops the explicit integer bit on significand carry
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Domain
- documentation
Research direction
Start with the FP87::Round definition linked in the issue and review its published carry branch, using the pinned definitions.xml.gz commit for context. Reproduce the supplied Binary80 case with exponent 0x3fff, all-ones mantissa, R=1 and S=1; done means the result is 0x4000:8000000000000000 while preserving the carry/rounded-up indication.
Written by the indexing model from the issue text.
Description
Problem
When rounding increments an all-ones significand, Round increments the exponent and writes a zero significand. Binary80 stores its integer bit explicitly, so this creates an unsupported unnormal encoding instead of the next normal number.
Concrete case
Call Round on a positive normal F80 value with exponent 0x3fff and mantissa 0xffffffffffffffff, using round-to-nearest and round/sticky inputs R=1, S=1. The rounding decision is upward. Expected result: exponent 0x4000, mantissa 0x8000000000000000 (2). The source returns exponent 0x4000, mantissa zero.
Expected behavior and references
References use Intel SDM 325462-093, checked on 2026-10-01. PDF page numbers below refer to the combined manual.
- Vol. 1 Table 4-3, double-extended encodings; combined PDF page 96
- Vol. 1 §8.2.2, unsupported unnormal encodings; combined PDF page 222
Source
Source checked at Intel SDM repository commit b5218b0f1cf512304d4b3cb364433a08fcee47cb.
The helper links are the readable current pages. Their reviewed definitions are in the compressed definition database at the pinned commit.
Suggested correction
Set the explicit integer bit when a significand carry increments the exponent. Preserve the carry/rounded-up indication.
Evidence
Direct calculation from the published carry branch with the input above produces exponent 0x4000 and significand zero. In the binary80 encoding table, a nonzero finite exponent with a clear explicit integer bit is unsupported. Setting that bit produces 0x4000:8000000000000000, the normal encoding of the required result 2.
AI disclosure
Assisted by Codex
- Dominant language
- HTML
- Stars
- 40
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from intel/SDM
-
Executable specification issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Executable specification issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Executable specification issue
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
SDM PDF issue
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
SDM PDF issue SDM Volume 1
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Similar issues
-
billion-context-pi
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
ranxianglei/billion-context#2521 · 3 comments ·
Maintainers usually reply within 1 day
-
agent-research agent-review-finding chore
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
jordansmall/spindrift#4922 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
nocodb/nocodb#14806 · 1 comment ·
Maintainers usually reply within 1 day
-
documentation v2
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
modelcontextprotocol/python-sdk#3662 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
aws-samples/sample-per-model-bedrock#123 ·
Maintainers usually reply within 1 day