From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 48D24385781A; Mon, 22 Mar 2021 07:53:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 48D24385781A From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/66728] [5 Regression] CONST_WIDE_INT causes corrupted DWARF debug info Date: Mon, 22 Mar 2021 07:53:31 +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: 5.1.1 X-Bugzilla-Keywords: wrong-debug X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.3 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-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 07:53:31 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66728 --- Comment #13 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954 commit r11-7757-gfc9c4e5fc50c7fcbd27d6cb3dd372f7da8216954 Author: Jakub Jelinek Date: Mon Mar 22 08:52:04 2021 +0100 debug: Fix __int128 handling in dwarf2out [PR99562] The PR66728 changes broke __int128 handling. It emits wide_int numbers in their minimum unsigned precision rather than in their full precision. The problem is then that e.g. the DW_OP_implicit_value path: int_mode =3D as_a (mode); loc_result =3D new_loc_descr (DW_OP_implicit_value, GET_MODE_SIZE (int_mode), 0); loc_result->dw_loc_oprnd2.val_class =3D dw_val_class_wide_int; loc_result->dw_loc_oprnd2.v.val_wide =3D ggc_alloc = (); *loc_result->dw_loc_oprnd2.v.val_wide =3D rtx_mode_t (rtl, int_mode); emits invalid DWARF. In particular this patch fixes there multiple occurences of: .byte 0x9e # DW_OP_implicit_value .uleb128 0x10 .quad 0xffffffffffffffff + .quad 0 .quad .LVL46 # Location list begin address (*.LLST40) .quad .LFE14 # Location list end address (*.LLST40) where we said the value has 16 byte size but then only emitted 8 byte value. My understanding is that most of the places that use val_wide expect the precision they chose (the one of the mode they want etc.), the only exception is the add_const_value_attribute case where it deals with VOIDmode CONST_WIDE_INTs, for that I agree when we don't have a mode we need to fallback to minimum precision (not sure if maximum of min_precision UNSIGNED and SIGNED wouldn't be better, then consumers would know if it is signed or unsigned by looking at the MSB), but that code already computes the precision, just decided to create the wide_int with much larger precision (e.g. 512 bit on x86_64). 2021-03-22 Jakub Jelinek PR debug/99562 PR debug/66728 * dwarf2out.c (get_full_len): Use get_precision rather than min_precision. (add_const_value_attribute): Make sure add_AT_wide argument has precision prec rather than some very wide one.=