From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60839 invoked by alias); 4 Feb 2018 19:17:10 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 60813 invoked by uid 89); 4 Feb 2018 19:17:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:1b58e2d, H*i:sk:1b58e2d, setups X-HELO: mail-ot0-f173.google.com Received: from mail-ot0-f173.google.com (HELO mail-ot0-f173.google.com) (74.125.82.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 04 Feb 2018 19:17:07 +0000 Received: by mail-ot0-f173.google.com with SMTP id 73so15906348oti.12 for ; Sun, 04 Feb 2018 11:17:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KlaDozKIf2iisHCVyukCOg7Yryg4hbR92T1sMkua6Go=; b=RK7Kx1AwAf1usKAbWYLEym8PVhFGHpw+FAwSiN0pwO/9Kkv59P5VMwESJKWX5OULkW vA8UtJmc+FS8VK8HIkunQ1mlte6ezw76jLNJqGtcsFX924mETRw7BRjD2+CAduO1k8Z5 nOsAqElPadIT5LJY1iL4G6RlTg88lkopx9IhqzHUTna9DJT6p8SlF2JNgq44Exlw+b4X 0sk7rmjbzbJf/GLpSQiLWyYDH7Vb6cIa7n732bPKnlZTcHQbjqru78g5Tft1UInsXali 0h0njwcVeAgFWsuNC3ReoS+z0Rwu26ek4w7p3CvKkzBV2TzQeSzTIF+WoaQAnmmiwcpm VrKQ== X-Gm-Message-State: AKwxytd1Y1DXtJ+3skb6vR5YcCvAd4mIHNrJh9dD9DNL1EvKjm6qp9qN 5Nqnf6hsM/tG/4lrGuZKD+UfZQ== X-Google-Smtp-Source: AH8x225Ifs4xXuWKaUfHJ2oM8BwDQIXDqlECSWVaDbX5K234RJoa7E+R3vgm4gjiV5I4+f7DwfG44Q== X-Received: by 10.157.36.137 with SMTP id z9mr12941697ota.175.1517771825964; Sun, 04 Feb 2018 11:17:05 -0800 (PST) Received: from localhost.localdomain (75-171-255-194.hlrn.qwest.net. [75.171.255.194]) by smtp.gmail.com with ESMTPSA id f31sm3421646otj.14.2018.02.04.11.17.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 11:17:04 -0800 (PST) Subject: Re: gdb 8.x - g++ 7.x compatibility To: Simon Marchi , Manfred References: <1517667601.3405.123.camel@gnu.org> <1b58e2df-5425-4f22-510c-d2e9f51040ba@polymtl.ca> Cc: gdb@sourceware.org, gcc@gcc.gnu.org From: Martin Sebor Message-ID: <39845077-6bdf-f60d-9bfc-a491e7fa4fc7@gmail.com> Date: Sun, 04 Feb 2018 19:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1b58e2df-5425-4f22-510c-d2e9f51040ba@polymtl.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-02/txt/msg00018.txt.bz2 On 02/03/2018 10:01 PM, Simon Marchi wrote: > 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. Readability was a factor but it wasn't the main motivation for the change. Printing the suffix is unhelpful because it leads to unnecessary differences in diagnostics (even in non-template contexts). For templates with non-type template parameters there is no difference between, say A<1>, A<1U>, A<(unsigned) 1>, or even A when Green is an enumerator that evaluates to 1, so including the suffix serves no useful purpose. In the GCC test suite, it would tend to cause failures due to differences between the underlying type of common typedefs like size_t and ptrdiff_t. Avoiding these unnecessary differences was the main motivation for the change. Not necessarily just in the GCC test suite but in all setups that process GCC messages. > 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? I think this message would be the most meaningful if the "auto" part were replaced with the deduced type. With that, the suffix of the constant isn't important, just as in other contexts. I didn't consider the use of auto as a template parameter but I don't think it changes anything. There, just like in other contexts, what's important is the deduced types and the values of constants, not the minute details of how they are spelled. That said, it wasn't my intention to make things difficult for the debugger. But changing GCC back to include the suffix, even just in the debug info, isn't a solution. There are other compilers besides GCC that don't emit the suffixes, and there even are some that prepend a cast to the number, so if GDB is to be usable with all these kinds of producers it needs to be able to handle all of these forms. Martin