From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32565 invoked by alias); 31 May 2013 18:50:27 -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 32532 invoked by uid 48); 31 May 2013 18:50:23 -0000 From: "daniel.kruegler at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit. Date: Fri, 31 May 2013 18:50: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.3 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.kruegler at googlemail dot com 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: 2013-05/txt/msg02271.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57484 --- Comment #1 from Daniel Kr=C3=BCgler --- I haven't checked your bit arithmetics, but I have checked the full bit patterns of the resulting NaNs in hex on my mingw-64 bit system. What I'm getting for are the following results: 1) gcc 4.7.2/4.9.0 20130519 (experimental) -m32: Signaling NaN's of "f" is 7fa00000 Quiet NaN's of "f" is 7fc00000 Signaling NaN's of "d" is 7ff4000000000000 Quiet NaN's of "d" is 7ff8000000000000 2) gcc 4.7.2/4.9.0 20130519 (experimental) -m64: Signaling NaN's of "f" is 7fa00000 Quiet NaN's of "f" is 7fc00000 Signaling NaN's of "d" is 7ff4000000000000 Quiet NaN's of "d" is 7ff8000000000000 All values look consistent with valid sNaN/qNaN patterns according to the ranges listed here: http://www.doc.ic.ac.uk/~eedwards/compsys/float/nan.html What are the full bit patterns that you get by printing the signaling_NaN.bits/quiet_NaN.bits values in hex? >>From gcc-bugs-return-423599-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 31 19:32:06 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 3737 invoked by alias); 31 May 2013 19:32:05 -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 3638 invoked by uid 48); 31 May 2013 19:32:00 -0000 From: "tromey at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/57487] New: vterminate.cc local variable optimized out Date: Fri, 31 May 2013 19:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tromey at gcc dot gnu.org 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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-05/txt/msg02272.txt.bz2 Content-length: 1207 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57487 Bug ID: 57487 Summary: vterminate.cc local variable optimized out Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org I built git master gcc today (317121db1372a50999ab1cba75aa59df0f2eff7c) using the default arguments on my x86-64 Fedora 18 machine. Then I compiled this program with the new g++ and ran it in gdb: int main() { throw 5; } Then, at the crash, I went up until I was in the verbose terminate handler frame. At this point I looked at the locals: #2 0x00007ffff7d59515 in __gnu_cxx::__verbose_terminate_handler () at ../../../../gcc/libstdc++-v3/libsupc++/vterminate.cc:95 95 abort(); (gdb) info local terminating = true t = Here, it is unfortunate that 't' is optimized out. If it were not, then the thrown exception type would be obvious from the stack trace. As it is, this information is written to stderr but otherwise lost -- for example, ABRT cannot easily pick it up.