public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dc.delia at protonmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/105158] New: ftree-ccp drops DWARF const value attribute at -Og/-O1/-O2/-O3 Date: Tue, 05 Apr 2022 10:20:19 +0000 [thread overview] Message-ID: <bug-105158-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158 Bug ID: 105158 Summary: ftree-ccp drops DWARF const value attribute at -Og/-O1/-O2/-O3 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dc.delia at protonmail dot com Target Milestone: --- In this code, variable l_171 is displayed optimized out at every stepped line when debugging, including line 10 where it is used as a call argument to an externally defined function. We tested with -Og/O1/O2/O3 and the issue is present at all these levels. Apparently, -ftree-ccp drops the const value attribute in the DWARF DIE for l_171 while the final compiled code stays the same. By turning it off, the debugger can display the value of the variable. We found this issue on gcc commit 500d3f0a302 using gdb 11.2 and the behavior seems consistent with prior gcc versions (e.g., 6.4, 7.5, 8.4, 9.3, 10.3, 11.1). $ cat a.c int a; void b() { int l_169, l_174 = 0, l_188 = 0, l_191 = 0, l_240 = 1; short l_171 ; l_171 = (l_169 = 0) && a; for (; l_169 <= 9; l_169 = l_169 + 3) { int l_187 = 0, l_189 = 0, l_190 = 8; test(l_169, l_171, l_174, l_188, l_191, l_240, l_187, l_189, l_190); } } int main () { b(); } $ cat lib.c #include <stdio.h> void test(int l_169, int l_171, int l_174, int l_188, int l_191, int l_240, int l_187, int l_189, int l_190) { printf("%d %d %d %d %d %d %d %d %d", l_169, l_171, l_174, l_188, l_191, l_240, l_187, l_189, l_190); } GDB trace: $ gcc -O1 -g a.c lib.c -o opt $ gdb -q opt Reading symbols from opt... (gdb) b 10 Breakpoint 1 at 0x4004fc: file a.c, line 10. (gdb) r Starting program: /tmp/opt Breakpoint 1, b () at a.c:10 10 test(l_169, l_171, l_174, l_188, l_191, l_240, l_187, l_189, l_190); (gdb) info locals l_187 = 0 l_189 = 0 l_190 = 8 l_169 = 0 l_174 = 0 l_188 = 0 l_191 = 0 l_240 = 1 l_171 = <optimized out> Code at -O1: 00000000004004f6 <b>: 4004f6: 53 push %rbx 4004f7: bb 00 00 00 00 mov $0x0,%ebx 4004fc: 48 83 ec 08 sub $0x8,%rsp 400500: 6a 08 pushq $0x8 400502: 6a 00 pushq $0x0 400504: 6a 00 pushq $0x0 400506: 41 b9 01 00 00 00 mov $0x1,%r9d 40050c: 41 b8 00 00 00 00 mov $0x0,%r8d 400512: b9 00 00 00 00 mov $0x0,%ecx 400517: ba 00 00 00 00 mov $0x0,%edx 40051c: be 00 00 00 00 mov $0x0,%esi 400521: 89 df mov %ebx,%edi 400523: b8 00 00 00 00 mov $0x0,%eax 400528: e8 26 00 00 00 callq 400553 <test> 40052d: 83 c3 03 add $0x3,%ebx 400530: 48 83 c4 20 add $0x20,%rsp 400534: 83 fb 0c cmp $0xc,%ebx 400537: 75 c3 jne 4004fc <b+0x6> 400539: 5b pop %rbx 40053a: c3 retq The code at higher optimization levels is very similar, besides where strength reduction, we suppose, kicks in (e.g. mov $0, %edi => xor %edi, %edi). DWARF at -O1: 0x000000e8: DW_TAG_variable DW_AT_name ("l_171") DW_AT_decl_file ("/tmp/a.c") DW_AT_decl_line (5) DW_AT_decl_column (0x0b) DW_AT_type (0x00000167 "short int") If we add -fno-tree-ccp to the compilation command line used above, the code of function b remains unchanged but the DWARF const value information is preserved for the variable, meaning its value 0 is visible when debugging throughout its whole lifetime. DWARF at -O1 with -fno-tree-ccp: 0x000000e8: DW_TAG_variable DW_AT_name ("l_171") DW_AT_decl_file ("/tmp/a.c") DW_AT_decl_line (5) DW_AT_decl_column (0x0b) DW_AT_type (0x00000167 "short int")
next reply other threads:[~2022-04-05 10:20 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-05 10:20 dc.delia at protonmail dot com [this message] 2022-04-05 12:48 ` [Bug debug/105158] ftree-ccp (CFG cleanup) " rguenth at gcc dot gnu.org 2022-04-05 13:27 ` rguenth at gcc dot gnu.org 2022-04-05 13:27 ` rguenth at gcc dot gnu.org 2022-04-07 12:47 ` rguenth at gcc dot gnu.org 2022-05-04 7:52 ` cvs-commit at gcc dot gnu.org 2022-05-04 7:53 ` rguenth at gcc dot gnu.org 2022-11-15 6:13 ` pinskia 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-105158-4@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).