C program
In my laptop,it shows gcc is not recognized as internal or external command
Re: gdb 8.x - g++ 7.x compatibility
On 2/4/2018 6:01 AM, 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. I was merely reporting the wording of the standard, which would be the authority to follow. I may agree that not specifying type identity may lead to unexpected results. Personally I would prefer the standard to say "identical value and type" here (and it appears from your findings below that quality compilers already handle it this way), but this is only an opinion. 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. Indeed. 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? Probably so. Simon [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78165
Re: gdb 8.x - g++ 7.x compatibility
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 const
gcc-8-20180204 is now available
Snapshot gcc-8-20180204 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180204/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 257367 You'll find: gcc-8-20180204.tar.xzComplete GCC SHA256=e289b8cd0f7b35948fc6170391ecc92ae8b36bd22f87df4d18662bc6f9ba3930 SHA1=cd9613c4a6279c06d9880d6d329bb505adaed978 Diffs from 8-20180128 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: C program
On 4 February 2018 at 14:34, Rakshitha H wrote: > In my laptop,it shows gcc is not recognized as internal or external command Then you probably need to install it. https://gcc.gnu.org/wiki/InstallingGCC
Re: gdb 8.x - g++ 7.x compatibility
Hi Martin,
Thanks for the reply.
On 2018-02-04 02:17 PM, Martin Sebor wrote:
> 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.
This is the part I don't understand. In Roman's example, spelling
foo<10> and foo<10u> resulted in two different instantiations of the
template, with different code. So that means it can make a difference,
can't it?
> 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.
Ok, I understand.
> 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.
Well, it seems like using decltype on a template constant value is
a way to make the type of constants important, in addition to their
value. I know the standard seems to say otherwise (what Manfred
quoted), but the reality seems different. I'm not a language expert
so I can't tell if this is a deficiency in the language or not.
> That said, it wasn't my intention to make things difficult for
> the debugger.
I hope so :).
> 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.
As I said earlier, there are probably ways to make GDB cope with it.
The only solution I saw (I'd like to hear about other ones) was to make
GDB ignore the template part in DW_AT_name and re-build it from the
DW_TAG_template_* DIEs in the format it expects. It can already do
that somewhat, because, as you said, some compilers don't emit
the template part in DW_AT_name.
Doing so would cause major slowdowns in symbol reading, I've tried it
for the sake of experimentation/discussion. I have a patch available
on the "users/simark/template-suffix" branch in the binutils-gdb
repo [1]. It works for Roman's example, but running the GDB testsuite
shows that, of course, the devil is in the details.
Consider something like this:
template
struct foo { virtual ~foo() {} };
int n;
int main ()
{
foo<&n> f;
}
The demangled name that GDB will be looking up is "foo<&n>". The
debug info about the template parameter only contains the resulting
address of n (the value of &n):
<2>: Abbrev Number: 11 (DW_TAG_template_value_param)
DW_AT_name: P
DW_AT_type: <0x1ac>
DW_AT_location: 10 byte block: 3 34 10 60 0 0 0 0 0 9f
(DW_OP_addr: 601034; DW_OP_stack_value)
I don't see how GDB could reconstruct the "&n" in the template, so
that's where my idea falls short.
Simon
[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/template-suffix
