From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13549 invoked by alias); 2 Jun 2014 23:37:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 13520 invoked by uid 48); 2 Jun 2014 23:37:11 -0000 From: "vincent-gcc at vinc17 dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/61399] New: LDBL_MAX is incorrect with IBM long double format / overflow issues near large values Date: Mon, 02 Jun 2014 23:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 4.7.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vincent-gcc at vinc17 dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg00117.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61399 Bug ID: 61399 Summary: LDBL_MAX is incorrect with IBM long double format / overflow issues near large values Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net On PowerPC, which uses the IBM long double format for the type long double,= one gets: LDBL_MANT_DIG =3D 106 (this is the precision of the FP model), LDBL_MAX_EXP =3D 1024 (this is the maximum exponent of the FP model). Even though the IBM long double format, a.k.a. double-double format, is not= a floating-point format, it is some superset of a floating-point format as specified by the C standard (see C11, =C2=A75.2.4.2.2 from p1 to p3), where= p =3D 106 and emax =3D 1024. By definition, for radix b =3D 2, LDBL_MAX is the value (1 - 2^(-p)) * 2^em= ax (see =C2=A75.2.4.2.2p12), which is the largest value representable in the floating-point model. However, with GCC 4.7.2 20121109 (Red Hat 4.7.2-8), I get: LDBL_MAX =3D 0x1.fffffffffffff7ffffffffffff8p+1023 instead of 0x1.ffffffffffffffffffffffffff8p+1023. The following program shows that this is not a display bug: #include #include int main (void) { long double dmax =3D DBL_MAX; printf ("%La\n", LDBL_MAX); printf ("%La\n", LDBL_MAX - dmax); printf ("%La\n", dmax + dmax * DBL_EPSILON / 4); printf ("%La\n", dmax + dmax * DBL_EPSILON / 2); return 0; } It outputs: 0x1.fffffffffffff7ffffffffffff8p+1023 0x1.ffffffffffffep+969 0x1.fffffffffffff7ffffffffffffcp+1023 inf also showing that the arithmetic is buggy. I suppose that the high double is the value rounded to double precision, but this rule is incorrect near the largest values, due to the overflow. 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= odel would need to be changed; otherwise some values are not representable, as s= hown above. >>From gcc-bugs-return-453036-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 03 00:07:58 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 32021 invoked by alias); 3 Jun 2014 00:07:58 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 31996 invoked by uid 48); 3 Jun 2014 00:07:53 -0000 From: "vincent-gcc at vinc17 dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values Date: Tue, 03 Jun 2014 00:07:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 4.7.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vincent-gcc at vinc17 dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg00118.txt.bz2 Content-length: 841 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61399 --- Comment #1 from Vincent Lef=C3=A8vre --- (In reply to Vincent Lef=C3=A8vre 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 model would need to be changed; otherwise some values are = not > representable, as shown above. By "the floating-point model would need to be changed", I mean, for instanc= e, choose LDBL_MAX_EXP =3D 1023. I think that this would be correct. A possible drawback is that one would have LDBL_MAX_EXP < DBL_MAX_EXP, but I don't thi= nk that this is a problem (note that one already has LDBL_MIN_EXP > DBL_MIN_EX= P). This would just mean that one has "not normalized" values outside the normal range. >>From gcc-bugs-return-453037-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 03 00:18:45 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 12932 invoked by alias); 3 Jun 2014 00:18:44 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 12884 invoked by uid 48); 3 Jun 2014 00:18:40 -0000 From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list Date: Tue, 03 Jun 2014 00:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.7.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: jason at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to target_milestone Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg00119.txt.bz2 Content-length: 521 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #12 from Jason Merrill --- Fixed on trunk so far.