Bug 54970 - Missing DW_OP_GNU_implicit_pointer in debuginfo
Summary: Missing DW_OP_GNU_implicit_pointer in debuginfo
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 4.7.1
: P3 normal
Target Milestone: 4.8.0
Assignee: Jakub Jelinek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-18 08:44 UTC by Jakub Jelinek
Modified: 2018-10-19 04:44 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-10-18 00:00:00


Attachments
gcc48-pr54970.patch (792 bytes, patch)
2012-10-18 08:55 UTC, Jakub Jelinek
Details | Diff
gcc48-pr54970.patch (1.51 KB, patch)
2012-10-18 09:26 UTC, Jakub Jelinek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2012-10-18 08:44:44 UTC
/* { dg-do run } */
/* { dg-options "-g" } */

#include "../nop.h"

int
main ()
{
  int a[] = { 1, 2, 3 };        /* { dg-final { gdb-test 12 "a\[1\]" "2" } } */
  int *p = a + 2;               /* { dg-final { gdb-test 12 "a\[2\]" "3" } } */
  int *q = a + 1;               /* { dg-final { gdb-test 12 "*p" "3" } } */
  asm volatile ("NOP");         /* { dg-final { gdb-test 12 "*q" "2" } } */
  *p += 10;                     /* { dg-final { gdb-test 16 "a\[1\]" "2" } } */
                                /* { dg-final { gdb-test 16 "a\[2\]" "13" } } */
                                /* { dg-final { gdb-test 16 "*p" "13" } } */
  asm volatile ("NOP");         /* { dg-final { gdb-test 16 "*q" "2" } } */
  *q += 10;                     /* { dg-final { gdb-test 20 "a\[1\]" "12" } } */
                                /* { dg-final { gdb-test 20 "a\[2\]" "13" } } */
                                /* { dg-final { gdb-test 20 "*p" "13" } } */
  asm volatile ("NOP");         /* { dg-final { gdb-test 20 "*q" "12" } } */
  return 0;
}

fails, apparently because we have # DEBUG p => &MEM[(void *)&a + 8B]
and we fail to expand that as (plus (debug_implicit_ptr a) (const_int 8)).
The reason for that is that we don't want (mem (debug_implicit_ptr x)) to appear
in debug insns, that confuses aliasing.  When expanding &a, we expand it as DEBUG_IMPLICIT_PTR, but when returning to MEM, we return NULL, as that is not appropriate thing to construct.
Comment 1 Jakub Jelinek 2012-10-18 08:55:02 UTC
Created attachment 28478 [details]
gcc48-pr54970.patch

Untested fix.
Comment 2 Jakub Jelinek 2012-10-18 09:26:54 UTC
Created attachment 28479 [details]
gcc48-pr54970.patch

The testcase still fails with -m32 -Os, the problem is that DECL_DEBUG_EXPR isn't created for the replacements in that case.  This patch adds needed tree-sra.c and var-tracking.c/dwarf2out.c changes to handle MEM_REFs with ADDR_EXPR in it too.
Comment 3 Jakub Jelinek 2012-10-26 19:19:30 UTC
Author: jakub
Date: Fri Oct 26 19:19:25 2012
New Revision: 192860

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192860
Log:
	PR debug/54970
	* cfgexpand.c (expand_debug_expr): Expand &MEM_REF[&var, n]
	as DEBUG_IMPLICIT_PTR + n if &var expands to DEBUG_IMPLICIT_PTR.
	* tree-sra.c (create_access_replacement): Allow also MEM_REFs
	with ADDR_EXPR first operand in DECL_DEBUG_EXPR expressions.
	* var-tracking.c (track_expr_p): Handle MEM_REFs in DECL_DEBUG_EXPR
	expressions.
	* dwarf2out.c (add_var_loc_to_decl): Likewise.

	PR debug/54971
	* gcc.dg/guality/pr54970.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/guality/pr54970.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/dwarf2out.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-sra.c
    trunk/gcc/var-tracking.c
Comment 4 Jakub Jelinek 2012-11-05 14:36:52 UTC
Author: jakub
Date: Mon Nov  5 14:36:47 2012
New Revision: 193162

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193162
Log:
	PR debug/54970
	PR debug/54971
	* gcc.dg/guality/pr54970.c: Use NOP instead of "NOP" in inline-asm.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/guality/pr54970.c
Comment 5 Jakub Jelinek 2012-12-04 13:16:05 UTC
Fixed.
Comment 6 Steven Bosscher 2013-03-12 17:09:14 UTC
This test case fails on powerpc64 with fc18.
The *p and *q stores are optimized away.
Comment 7 Jakub Jelinek 2013-03-12 17:50:49 UTC
The stores are of course optimized away, everywhere, that is the point of the testcase.
The problems that cause the debug info to be insufficient on some targets are tracked e.g. in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54971#c13
There is no point to keep this PR open for that.
Comment 8 Steven Bosscher 2013-03-12 18:55:19 UTC
(In reply to comment #7)
> The stores are of course optimized away, everywhere, that is the point
> of the testcase.

I am talking about the debug_stmts for the stores, sorry if that was not
clear.  On x86_64 the test case passes, but on powerpc64 esra does something
it doesn't do on x86_64 and it makes the test case fail.  Is there a known
bug for that already, also?

This is 176 FAILs on powerpc64.  If it's "supposed to not work" there, then
the test case should be XFAIL'ed there.