From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C024D385B51C; Mon, 5 Dec 2022 09:42:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C024D385B51C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1670233353; bh=CTERoPjlPKJvj5wZMG+8DEO23BcBSnK6KyaSVqc8ukM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oxW5Bf9R+sC63nbksKBma3TMxorE27S3y1RgqrWOG6Ikoumyn8yWg04jl2p2U2X2L AlUQLQYBdiNX5ueG4IPxOlJqzgUPWrygd25GYEng3plDVWYcapxwkI+HajvNFvBy4l yexIy4iCBsWeSJ5+g5Rzl00QtyAPfYUakrceQ/0U= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures Date: Mon, 05 Dec 2022 09:42:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed 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: redi at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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_status everconfirmed component cf_reconfirmed_on cc 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107965 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|libstdc++ |debug Last reconfirmed| |2022-12-05 CC| |jason at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- (In reply to Richard Biener from comment #3) > so gdb has no idea that x only becomes live after the call to the CTOR > (or during that). Instead GCC says it lives throughout the whole > function on the frame. That's clearly a GCC bug then, because that is not how C++ works. > Even the original IL from the frontend has no > hint that would allow the middle-end to emit different DWARF. So let's change component to 'debug'. There's definitely nothing the libstd= c++ printers can do here. (In reply to Richard Biener from comment #4) > I would suggest to make the pretty-printers more robust with respect to > memory errrors (can those errors be catched and the printing avoided > somehow?) There's no single type of error reported in such cases (e.g. the OverflowEr= ror shown above depends on the specific values of the uninitialized bytes, even= the same printer won't fail with the same error every time). The only way to be more robust is to catch *all* exceptions, and swallow all errors from any p= oint in the printers. That then hides real errors, and makes them impossible to develop/debug. It would mean changes in at least 50 places, which would all have to be individually disabled to allow real errors to propagate when try= ing to debug or improve the printers. I don't want to do that.=