From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63020 invoked by alias); 4 Feb 2018 05:01:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 62941 invoked by uid 89); 4 Feb 2018 05:01:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*f:sk:1517667, H*f:sk:v4mbAO5, H*f:CAATAM3H2V53F, 10u X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 04 Feb 2018 05:01:44 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w1451aB1001076 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 4 Feb 2018 00:01:41 -0500 Received: from [10.0.0.11] (192-222-251-162.qc.cable.ebox.net [192.222.251.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 61F1B1E093; Sun, 4 Feb 2018 00:01:36 -0500 (EST) From: Simon Marchi Subject: Re: gdb 8.x - g++ 7.x compatibility To: Manfred Cc: gdb@sourceware.org, gcc@gcc.gnu.org References: <1517667601.3405.123.camel@gnu.org> Message-ID: <1b58e2df-5425-4f22-510c-d2e9f51040ba@polymtl.ca> Date: Sun, 04 Feb 2018 05:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Sun, 4 Feb 2018 05:01:36 +0000 X-SW-Source: 2018-02/txt/msg00018.txt.bz2 On 2018-02-03 13:35, Manfred wrote: > n4659 17.4 (Type equivalence) p1.3: > > Two template-ids refer to the same class, function, or variable if > ... > their corresponding non-type template arguments of integral or > enumeration type have identical values > ... > > It looks that for non-type template arguments the template type > equivalence is based on argument /value/ not /type/ (and value), so > IMHO gcc is correct where it considers foo<10u> and foo<10> to be the > same type, i.e. "refer to the same class" > > FWIW, type_info reports the same class name for both templates, which > appears to be correct as per the above. > > I would think someone from gcc might be more specific on why both > templates print 4294967286, and what debug info is actually stored by > -g in this case. I think that Roman's example clearly shows that they are not equivalent in all cases. Building Roman's example with g++ 7.3 results in a single instantiated type. You can see that both "new foo<10>()" and "new foo<10u>()" end up calling the same constructor. It seems like which type is instantiated depends on which template parameter (the signed or unsigned one) you use first. So with this: base * fi = new foo<10>(); base * fu = new foo<10u>(); the output is -10 for both, and with base * fu = new foo<10u>(); base * fi = new foo<10>(); the output is 4294967286 for both. But it's probably a bogus behavior. I tested with clangd, it instantiates two different types, so you get 4294967286 for the <10u> case and -10 for the <10> case. I also just built gcc from master, and it also instantiates two types, so it seems like that was fixed recently. So let's see what debug info gcc master generates for these two instances of foo (clang master generates the equivalent). <1><9257>: Abbrev Number: 66 (DW_TAG_structure_type) <9258> DW_AT_name : (indirect string, offset: 0x8455): foo<10> <925c> DW_AT_byte_size : 16 <925d> DW_AT_decl_file : 1 <925e> DW_AT_decl_line : 7 <925f> DW_AT_decl_column : 8 <9260> DW_AT_containing_type: <0x92fd> <9264> DW_AT_sibling : <0x92f8> ... <1><93be>: Abbrev Number: 66 (DW_TAG_structure_type) <93bf> DW_AT_name : (indirect string, offset: 0x8455): foo<10> <93c3> DW_AT_byte_size : 16 <93c4> DW_AT_decl_file : 1 <93c5> DW_AT_decl_line : 7 <93c6> DW_AT_decl_column : 8 <93c7> DW_AT_containing_type: <0x92fd> <93cb> DW_AT_sibling : <0x945f> If there are two types with the same name, how is gdb expected to differentiate them? If we can't rely on the DW_AT_name anymore to differentiate templated types, then the only alternative I see would be to make GDB ignore the template part of the DW_AT_name value, and reconstruct it in the format it expects (with the u) from the DW_TAG_template_value_param DIEs children of DW_TAG_structure_type (there's already code to do that in dwarf2_compute_name). Their types correctly point to the signed int or unsigned int DIE, so we have the necessary information. However, that would mean reading many more full DIEs early on, when just building partial symbols, which would slow done loading the symbols of pretty much any C++ program. >From what I understand from the original change that caused all this [1], removing the suffixes was meant to make the error messages more readable for the user. However, since foo<10>::print() and foo<10u>::print() are not the same function, I think it would actually be more confusing if an error message talked about the instantiation with the unsigned type, but mentioned "foo<10>::print()". For example, if you put a static_assert (std::is_signed::value); in the print method, this is the error message from gcc: test.cpp: In instantiation of 'void foo::print() [with auto IVAL = 10]': test.cpp:24:1: required from here test.cpp:12:22: error: static assertion failed static_assert (std::is_signed::value); ^~~ Wouldn't the message make more sense with a u suffix? Simon [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78165