[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #13 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #12) > That isn't representable in the GCC internal representation, which pretends > the type has fixed 106 bit precision [...] So, if I understand correctly, this

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #12 from Jakub Jelinek --- (In reply to Vincent Lefèvre from comment #11) > In addition to the maximum exponent issue, for LDBL_MAX following the defect > report, instead of > > 0x1.f78p+1023 > > I would ex

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #11 from Vincent Lefèvre --- In addition to the maximum exponent issue, for LDBL_MAX following the defect report, instead of 0x1.f78p+1023 I would expect 0x1.f7cp+1023 = DBL_MAX +

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #10 from Vincent Lefèvre --- (In reply to jos...@codesourcery.com from comment #9) > That wording defines what "normalized" is, so that values with maximum > exponent in this case don't count as normalized because not all values > w

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #9 from joseph at codesourcery dot com --- On Tue, 20 Jun 2017, vincent-gcc at vinc17 dot net wrote: > > The current proposed wording for DR#467 > > changes > > "ma

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #8 from Vincent Lefèvre --- It seems that the choice emin = -968, emax = 1024, p = 106 had been made originally because all normalized values in this floating-point system (as specified by 5.2.4.2.2p2) are representable as a sum of tw

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #7 from Vincent Lefèvre --- (In reply to jos...@codesourcery.com from comment #6) > The current proposed wording for DR#467 > changes > "maximum representable finite

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #6 from joseph at codesourcery dot com --- The current proposed wording for DR#467 changes "maximum representable finite floating-point number, [ math formula ]" to

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 Vincent Lefèvre changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 Vincent Lefèvre changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #3 from Vincent Lefèvre --- The variable precision is unavoidable with this format (this is even a feature, despite the drawbacks). But the fact that the variable precision is problematic by itself isn't a reason not to try to solve o

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #1 from Vincent Lefèvre --- (In reply to Vincent Lefèvre from comment #0) > One may choose to keep the behavior, i.e. consider that the high double is > the value rounded to double precision, but this means that the > floating-point m