public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/103046] [11/12 Regression] Incorrect debug info for uint128 bit shift in gcc 11.2 Date: Fri, 05 Nov 2021 09:23:21 +0000 [thread overview] Message-ID: <bug-103046-4-Mgujg49XSd@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103046-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103046 --- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:155f6b2be421b0f84e478e34fbf72ee0bb9e36bc commit r12-4933-g155f6b2be421b0f84e478e34fbf72ee0bb9e36bc Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Nov 5 10:20:10 2021 +0100 dwarf2out: Fix up CONST_WIDE_INT handling once more [PR103046] My last change to CONST_WIDE_INT handling in add_const_value_attribute broke handling of CONST_WIDE_INT constants like ((__uint128_t) 1 << 120). wi::min_precision (w1, UNSIGNED) in that case 121, but wide_int::from creates a wide_int that has 0 and 0xff00000000000000ULL in its elts and precision 121. When we output that, we output both elements and thus emit 0, 0xff00000000000000 instead of the desired 0, 0x0100000000000000. IMHO we should actually pass machine_mode to add_const_value_attribute from callers, so that we know exactly what precision we want. Because hypothetically, if say mode is OImode and the CONST_WIDE_INT value fits into 128 bits or 192 bits, we'd emit just those 128 or 192 bits but debug info users would expect 256 bits. On typedef unsigned __int128 U; int main () { U a = (U) 1 << 120; U b = 0xffffffffffffffffULL; U c = ((U) 0xffffffff00000000ULL) << 64; return 0; } vanilla gcc incorrectly emits 0, 0xff00000000000000 for a, 0xffffffffffffffff alone (DW_FORM_data8) for b and 0, 0xffffffff00000000 for c. gcc with the previously posted PR103046 patch emits 0, 0x0100000000000000 for a, 0xffffffffffffffff alone for b and 0, 0xffffffff00000000 for c. And with this patch we emit 0, 0x0100000000000000 for a, 0xffffffffffffffff, 0 for b and 0, 0xffffffff00000000 for c. So, the patch below certainly causes larger debug info (well, 128-bit integers are pretty rare), but in this case the question is if it isn't more correct, as debug info consumers generally will not know if they should sign or zero extend the value in DW_AT_const_value. The previous code assumes they will always zero extend it... 2021-11-05 Jakub Jelinek <jakub@redhat.com> PR debug/103046 * dwarf2out.c (add_const_value_attribute): Add MODE argument, use it in CONST_WIDE_INT handling. Adjust recursive calls. (add_location_or_const_value_attribute): Pass DECL_MODE (decl) to new add_const_value_attribute argument. (tree_add_const_value_attribute): Pass TYPE_MODE (type) to new add_const_value_attribute argument.
next prev parent reply other threads:[~2021-11-05 9:23 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-02 14:11 [Bug debug/103046] New: " liyd2021 at gmail dot com 2021-11-02 15:46 ` [Bug debug/103046] [11/12 Regression] " jakub at gcc dot gnu.org 2021-11-05 9:23 ` cvs-commit at gcc dot gnu.org [this message] 2021-11-05 13:38 ` [Bug debug/103046] [11 " rguenth at gcc dot gnu.org 2021-11-29 8:49 ` cvs-commit at gcc dot gnu.org 2021-11-29 9:08 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-103046-4-Mgujg49XSd@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).