https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-10-22
Component|debug |tree-optimization
Known to work|8.1.1 |4.8.5
Summary|[7 Regression] Missing |[7/8/9/10 Regression]
|DW_TAG_lexical_block PC |Missing
|range |DW_TAG_lexical_block PC
| |range
Ever confirmed|0 |1
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
The difference in debug info between GCC 7 (failing) and GCC 8 (passing) is
that GCC 8 has the test UNSUPPORTED because:
pr55665.gdb:3: Error in sourced command file:^M
No symbol "p" in current context.^M
UNSUPPORTED: g++.dg/guality/pr55665.C -O2 line 23 p == 40
while with GCC 7 setting the break-point works. The above error happens
with trunk as well.
The lexical block range is present but what seems to be missing is
the fact that 'p' is not yet updated in memory at the point of the
breakpoint but the store was delayed and the updated value is only
available in a register.
Now - that's wrong-code since concurrent execution from a different thread
doesn't see the initialization then. The issue is that 'p' doesn't have
its address taken and thus we do not consider it aliased by the
__cxa_guard_acquire/__cxa_guard_release functions - which is correct - but
we rely on aliasing to implement storage barriers... :/
The fact that gdb looks at memory instead of a register is probably both
an artifact of
<3><de>: Abbrev Number: 11 (DW_TAG_variable)
<df> DW_AT_name : p
<e1> DW_AT_decl_file : 1
<e2> DW_AT_decl_line : 22
<e3> DW_AT_decl_column : 14
<e4> DW_AT_type : <0x68>
<e8> DW_AT_location : 9 byte block: 3 8 0 0 0 0 0 0 0 (DW_OP_addr: 8)
as well as us not tracking memory in var-tracking.
That it worked with GCC 4.8 is because didn't optimize this to
a register.
