On 21/10/16 16:14, Jakub Jelinek wrote: > On Fri, Oct 21, 2016 at 03:57:34PM +0100, Yao Qi wrote: >> Hi Jakub, >> >> On Thu, Oct 20, 2016 at 5:21 PM, Andre Vieira (lists) >> <andre.simoesdiasvie...@arm.com> wrote: >>> <2><8f5>: Abbrev Number: 38 (DW_TAG_member) >>> <8f6> DW_AT_specification: <0x8be> >>> <8fa> DW_AT_linkage_name: (indirect string, offset: 0x4a0): >>> _ZN6BANANA1sE >>> <8fe> DW_AT_location : 5 byte block: 3 64 bf 1 0 >>> (DW_OP_addr: 1bf64) >>> >>> I haven't tested it on other targets. >> >> I can reproduce it on x86_64 as well. > > First of all, I have a pending patch for this area: > http://gcc.gnu.org/ml/gcc-patches/2016-10/msg01183.html > so I think it doesn't really make much sense to discuss it until it gets in. > But unless you are talking about -std=c++17 or code with explicit inline > vars, I don't think anything has really changed in the debug representation > with that patch. > > Jakub >
Hi Jakub, I built gcc for the following: 1) revision r241135 2) revision r241135 + cherry-picked your patch in revision r241137 (skipped the patch in revision r241136 because that gives a build failure). 3) trunk + patch in http://gcc.gnu.org/ml/gcc-patches/2016-10/msg01183.html And compiling the member-ptr.cc file in the gdb testsuite without -std=c17 (see https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/testsuite/gdb.cp/member-ptr.cc;h=4b7da34d3a77e3b5c045bd76d1f0a01514a039d7;hb=HEAD) leads to the following behavior: 1) expected behavior, debug of information of objects of 'class A' looks fine. 2) new debug information for objects of 'class A' breaking the test. 3) same as 2) As you can see the file has no explicit inline vars and I do not compile it with -std=c++17. So I'm suspecting your patch changes this behavior in an unexpected way. Regards, Andre
