This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail
- From: "mark at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 21 Dec 2017 22:16:32 +0000
- Subject: [Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail
- Auto-submitted: auto-generated
- References: <bug-83157-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157
Mark Wielaard <mark at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at gcc dot gnu.org
--- Comment #6 from Mark Wielaard <mark at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #4)
> I am attaching a simplified preprocessed file that exhibits the problem.
> Perhaps someone with more debug-fu can comment here.
>
> [tl;dr: Shouldn't local variables in a cloned variable have their own
> location lists?].
In this case it seems the answer is yes.
The location code range(s) of the abstract origin don't make sense in the
cloned code since it doesn't cover the new cloned code range.
Also, since it seems we know the cloned variable is always 1 maybe it could
just simply have a DW_AT_const_value 1 instead of a DW_AT_location?