• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

stillwater-sc / universal / 36205058783
87%
master: 84%

Build:
Build:
LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran 26 Sep 2026 12:55AM UTC
Jobs 1
Files 676
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

26 Sep 2026 12:29AM UTC coverage: 85.992%. Remained the same
36205058783

push

github

web-flow
fix(cfloat): xtndd is the x87 80-bit format, not double's range in 80 bits (#1610)

* fix(cfloat): xtndd is the x87 80-bit format, not double's range in 80 bits

xtndd was cfloat<80,11>. es = 11 is double's exponent field, so an 80-bit
container held a value that never exceeded what a 64-bit duble holds: maxpos was
1.798e308 and everything above it overflowed to inf, where a real x87 long
double is finite across another 4600 orders of magnitude. Sixteen bits of the
encoding bought precision and none bought range.

At es = 15 it matches native x87 exactly:

                       es  fbits  exponent range      maxpos
  xtndd was            11     68  -1021 .. 1024       1.798e+308
  xtndd now            15     64  -16381 .. 16384     1.190e+4932
  native x87 ld        15     64  -16381 .. 16384     1.18973e+4932

It is still not bit-compatible, and that part is structural rather than an
oversight. x87 stores an EXPLICIT integer bit, spending one of its 80 bits on
the significand's leading 1, so it carries 64 bits of precision. cfloat's
leading bit is implicit, so the same 80 bits give 64 fraction bits plus the
implicit one -- 65 bits, one more than x87. Closing that needs
explicit-integer-bit support in cfloat, which is a larger change than an alias.
So xtndd agrees with an x87 long double on range and on which values overflow,
and can differ in the last bit. The regression asserts exactly that, requiring
L::digits == long double digits + 1 on a host whose long double IS x87.

sqrt_precision.cpp needed more than a parameter swap. It defines its own oracle,
and XtnddW was cfloat<144,13> with max_exponent 4096. Squaring the new maxpos
reaches scale 32768, so that oracle would have answered inf at exactly the
argument the suite exists to cover -- the trap already recorded in that file's
comments from an earlier round. Widened to es = 17, which is what QuadW uses for
the same es = 15 subject.

Worth recording a side effect: at es = 11 xtndd's maxpos WAS do... (continued)

45514 of 52928 relevant lines covered (85.99%)

9401796.06 hits per line

Jobs
ID Job ID Ran Files Coverage
1 36205058783.1 26 Sep 2026 12:55AM UTC 676
85.99
GitHub Action Run
Source Files on build 36205058783
  • Tree
  • List 676
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #36205058783
  • e54aa580 on github
  • Prev Build on main (#36197995566)
  • Next Build on main (#36208611327)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc