Re: gdb 8.x - g++ 7.x compatibility

[Martin Sebor]

On 02/05/2018 09:59 AM, Simon Marchi wrote:

On 2018-02-05 11:45, Martin Sebor wrote:

Yes, with auto, the type of the constant does determine the type
of the specialization of the template in the source code.

In non-type template arguments, and more to the point I was making,
in diagnostics, the suffix shouldn't or doesn't need to be what
distinguishes the type of the template, even with auto.  The part
"with auto IVAL = 10" in the message

  'void foo::print() [with auto IVAL = 10]':

would be far clearer if auto were replaced by the deduced type,
say along these lines:

  'void foo::print() [with int IVAL = 10]':

rather than relying on the suffix alone to distinguish between
different specializations of the template.  That seems far too
subtle to me.  But I think the diagnostic format is (or should
be) independent of the debug info.


That makes sense.


With respect to the suffix, I keep coming back to the reality
that even if GCC were to change to emit a format that GDB can
interpret easily and efficiently, there still are other
compilers that emit a different format.  So the conclusion
that a general solution that handles more than just one format
(at least for non-type template arguments without auto) seems
unescapable.


If there are other compilers we wanted to support for which we can't
trust the template format, we could always ignore the template part of
DW_AT_name specifically for them.  But since g++ and gdb are part of the
same project and are expected to work well and efficiently together, I
would have hoped that we could agree on a format so that gdb would not
have to do the extra work when parsing a g++-generated file
(consequently the same format that libiberty's demangler produces).

Given the problem I illustrated in my previous mail, I don't have a
general solution to the problem to propose.


Okay, let me talk to Jason to see what he thinks.  I'm open
to restoring the suffix for the debug info as long as it doesn't
adversely affect the diagnostics.  I agree that if GCC can help
make GDB more efficient it's worth putting effort into.  (I do
still think that GDB should work with other providers besides
GCC, even if perhaps not necessarily as efficiently.)

Martin

Re: Resolving LTO symbols for static library boundary

[Jan Hubicka]

Dne 2018-02-05 18:44, Richard Biener napsal:

On February 5, 2018 12:26:58 PM GMT+01:00, Allan Sandfeld Jensen
 wrote:

Hello GCC

In trying to make it possible to use LTO for distro-builds of Qt, I
have again
hit the problem of static libraries. In Qt in general we for LTO rely
on a
library boundary, where LTO gets resolved when generating the library
but no
LTO-symbols are exported in the shared library. This ensure the 
library

has a
well defined binary compatible interface and gets LTO optimizations
within
each library. For some private libraries we use static libraries
however,
because we don't need binary compatibility, but though we don't need 
BC


between Qt versions, the libraries should still be linkable with
different gcc
versions (and with different compilers). However when LTO is enabled
the
static libraries will contain definitions that depend on a single gcc
version
making it unsuitable for distribution.

One solution is to enable fat-lto object files for static libraries 
but

that
is both a waste of space and compile time, and disables any LTO
optimization
within the library. Ideally I would like to have the static library do
LTO
optimizations internally just like a shared library, but then exported
as
static library.

I suspect this is more of gcc task than ar/ld task, as it basically
boils down
to gcc doing for a static library what it does for shared library, but
maybe
export the result as a single combined .o file, that can then be ar'ed
into a
compatible static library.

Is this possible?


Hmm. I think you could partially link the static archive contents into
a single relocatable object. Or we could add a mode where you do a
1to1 LTO link of the objects and stop at the ltrans object files. You
could stuff those into an archive again.

I'm not sure how far Honza got partial LTO linking to work?


Parital linking of lto .o files into single non-lto .o file should work 
and it will get you cross-module optimization done. The problem is that 
without resolution info compiler needs to assume that all symbols 
exported by object files are possibly referneced by the later 
incremental link and thus the code quality will definitly not be 
comparable with what you get for LTO on final binary or DSO. Still 
should be better than non-lto build.

I would be curious if it is useful for you in practice.

Honza


Richard.


Best regards
'Allan Jensen

Re: Debugging optimizer problems

[Martin Sebor]

On 02/02/2018 12:29 PM, jacob navia wrote:

Hi

I am confronted with a classical problem: a program gives correct
results when compiled with optimizations off, and gives the wrong ones
with optimization (-O2) on.

I have isolated the probem in a single file but now there is no way that
I can further track down the problem to one of the many functions in
that file.


The approach that usually works reasonably well is to use a tool
like delta or creduce to shrink the size of the problem to a small
test case.  https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction.

FWIW, the trick I've successfully used in the past is to add
an assert or some such conditional close to the point where
you see the wrong results being computed in the debugger.  Then
take the entry point into the file (whatever function eventually
leads to the bad behavior) and create a main that calls it with
the right values of all the arguments to trigger the bug.
Linking that into an executable typically causes many unresolved
references to symbols defined elsewhere in the file.  Provide
dummy definitions for those symbols in the same file so that
the program eventually links while still exhibiting the problem.
(Doing the same for other functions in the same file helps speed
up the whole process).  Then create a shell script that compiles
and links the file (treating all warnings as errors to avoid bad
changes from masking the problem) and runs the program looking
for the same failed assertion.  Let it run under delta for a few
hours or a day until the size is small enough so you understand
exactly what triggers the problem.

Martin



I have in my small C compiler introduced the following construct:

#pragma optimize(on/off,push/pop)

to deal with optimizer bugs.

#pragma optimize(off)

turns OFF all optimizations until a #pragma optimize(on) is seen or
until the end of the compiulation unit. If

#pragma optimize(off,push)

is given, the optimization state can be retrieved with a

#pragma optimize(pop), or

#pragma optimize(on)

This has three advantages:

1) Allows the user to reduce the code area where the problem is hiding.

2) Provides a work around to the user for any optimizer bug.

3) Allows gcc developers to find bugs in a more direct fashion.

These pragmas can only be given at a global scope, not within a function.

I do not know gcc internals, and this improvement could be difficult to
implement, and I do not know either your priorities in gcc development
but it surely would help users. Obviously I think that the problem is in
the code I am compiling, not in gcc, but it *could* be in gcc. That
construct would help enormously.

Thanks in advance for your time.

jacob

Copyright Assignment

[Tim van Deurzen]

Hi,

I've written to this list previously to mention I'm working on
implementing p0515 (the spaceship operator) for C++. Although I'm still
far from finished I'd like to make sure that when I am, I will be able
to contribute my changes to GCC. Please tell me what I should do to take
care of the copyright assignment.


Thank you!

Tim.

Re: gdb 8.x - g++ 7.x compatibility

[Roman Popov]

Well, if ABI has specification for type naming, why not to put this name to
debug_info so debugger can use it?

In this case argument that "each producer has its own naming conventions"
no longer works.  Any producer for given ABI must use ABI-specified names.



2018-02-05 12:12 GMT-08:00 Jonathan Wakely :

> On 5 February 2018 at 20:10, Roman Popov wrote:
> > Do you mean that g++ guarantees uniqueness of mangled names for types?
> And
>
> Of course. The mangled name is determined by the ABI and must be
> stable, predictable and unique, so that linking works.
>
> > uses name compare for operator==  ?
>
> Yes.
>

Re: gdb 8.x - g++ 7.x compatibility

[Jonathan Wakely]

On 5 February 2018 at 20:10, Roman Popov wrote:
> Do you mean that g++ guarantees uniqueness of mangled names for types? And

Of course. The mangled name is determined by the ABI and must be
stable, predictable and unique, so that linking works.

> uses name compare for operator==  ?

Yes.

Re: gdb 8.x - g++ 7.x compatibility

[Roman Popov]

Do you mean that g++ guarantees uniqueness of mangled names for types? And
uses name compare for operator==  ?

2018-02-05 12:08 GMT-08:00 Jonathan Wakely :

> On 5 February 2018 at 17:44, Roman Popov wrote:
> > Interestingly RTTI name also gives no guarantees:
> > http://en.cppreference.com/w/cpp/types/type_info/name
> >
> > << Returns an implementation defined null-terminated character string
> > containing the name of the type. No guarantees are given; in particular,
> > the returned string can be identical for several types and change between
> > invocations of the same program. >>
> >
> > It probably makes sense to look how g++ implements
> > std::type_info::operator== . Probably there are some hints that GDB
> > algorithm can utilize.
> > Operator std::type_info::operator== must return true for equivalent
> types.
>
> It's the mangled name.
>

Re: gdb 8.x - g++ 7.x compatibility

[Jonathan Wakely]

On 5 February 2018 at 17:44, Roman Popov wrote:
> Interestingly RTTI name also gives no guarantees:
> http://en.cppreference.com/w/cpp/types/type_info/name
>
> << Returns an implementation defined null-terminated character string
> containing the name of the type. No guarantees are given; in particular,
> the returned string can be identical for several types and change between
> invocations of the same program. >>
>
> It probably makes sense to look how g++ implements
> std::type_info::operator== . Probably there are some hints that GDB
> algorithm can utilize.
> Operator std::type_info::operator== must return true for equivalent types.

It's the mangled name.

ICE in stage 2 during libgcc configure on x86_64-w64-mingw32, rev. 257390

[Rainer Emrich]

Today I get an ICE during configuration of libgcc in stage 2 on 
x86_64-w64-mingw32. That's rev. 257390.

configure:3688: 
/opt/devel/SCRATCH/tmp.Sbg1TmFqa7/gcc-8.0.0/gcc-8.0.0/./gcc/xgcc 
-B/opt/devel/SCRATCH/tmp.Sbg1TmFqa7/gcc-8.0.0/gcc-8.0.0/./gcc/ 
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/x86_6
4-w64-mingw32/lib 
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/mingw/lib
 -isystem 
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/x86_64-w64-mingw32/include
-isystem 
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/mingw/include
 
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/x86_64-w64-mingw32/bin/
 -B/opt/devel/gnu/
gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/x86_64-w64-mingw32/lib/
 -isystem 
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/x86_64-w64-mingw32/include
 -isystem /opt/devel/g
nu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-8.0.0/x86_64-w64-mingw32/sys-include
-c -g -O2  conftest.c >&5
during GIMPLE pass: cfg
conftest.c: In function 'main':
conftest.c:11:1: internal compiler error: Segmentation fault
 main ()
 ^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3692: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3706: error: in 
`/opt/devel/SCRATCH/tmp.Sbg1TmFqa7/gcc-8.0.0/gcc-8.0.0/x86_64-w64-mingw32/libgcc':


Does somebody else sees this?



signature.asc
Description: OpenPGP digital signature

Re: Resolving LTO symbols for static library boundary

[Richard Biener]

On February 5, 2018 12:26:58 PM GMT+01:00, Allan Sandfeld Jensen 
 wrote:
>Hello GCC
>
>In trying to make it possible to use LTO for distro-builds of Qt, I
>have again 
>hit the problem of static libraries. In Qt in general we for LTO rely
>on a 
>library boundary, where LTO gets resolved when generating the library
>but no 
>LTO-symbols are exported in the shared library. This ensure the library
>has a 
>well defined binary compatible interface and gets LTO optimizations
>within 
>each library. For some private libraries we use static libraries
>however, 
>because we don't need binary compatibility, but though we don't need BC
>
>between Qt versions, the libraries should still be linkable with
>different gcc 
>versions (and with different compilers). However when LTO is enabled
>the 
>static libraries will contain definitions that depend on a single gcc
>version 
>making it unsuitable for distribution.
>
>One solution is to enable fat-lto object files for static libraries but
>that 
>is both a waste of space and compile time, and disables any LTO
>optimization 
>within the library. Ideally I would like to have the static library do
>LTO 
>optimizations internally just like a shared library, but then exported
>as 
>static library.
>
>I suspect this is more of gcc task than ar/ld task, as it basically
>boils down 
>to gcc doing for a static library what it does for shared library, but
>maybe 
>export the result as a single combined .o file, that can then be ar'ed
>into a 
>compatible static library.
>
>Is this possible?

Hmm. I think you could partially link the static archive contents into a single 
relocatable object. Or we could add a mode where you do a 1to1 LTO link of the 
objects and stop at the ltrans object files. You could stuff those into an 
archive again. 

I'm not sure how far Honza got partial LTO linking to work? 

Richard. 

>Best regards
>'Allan Jensen

Re: gdb 8.x - g++ 7.x compatibility

[Roman Popov]

Interestingly RTTI name also gives no guarantees:
http://en.cppreference.com/w/cpp/types/type_info/name

<< Returns an implementation defined null-terminated character string
containing the name of the type. No guarantees are given; in particular,
the returned string can be identical for several types and change between
invocations of the same program. >>

It probably makes sense to look how g++ implements
std::type_info::operator== . Probably there are some hints that GDB
algorithm can utilize.
Operator std::type_info::operator== must return true for equivalent types.


2018-02-05 8:59 GMT-08:00 Simon Marchi :

> On 2018-02-05 11:45, Martin Sebor wrote:
>
>> Yes, with auto, the type of the constant does determine the type
>> of the specialization of the template in the source code.
>>
>> In non-type template arguments, and more to the point I was making,
>> in diagnostics, the suffix shouldn't or doesn't need to be what
>> distinguishes the type of the template, even with auto.  The part
>> "with auto IVAL = 10" in the message
>>
>>   'void foo::print() [with auto IVAL = 10]':
>>
>> would be far clearer if auto were replaced by the deduced type,
>> say along these lines:
>>
>>   'void foo::print() [with int IVAL = 10]':
>>
>> rather than relying on the suffix alone to distinguish between
>> different specializations of the template.  That seems far too
>> subtle to me.  But I think the diagnostic format is (or should
>> be) independent of the debug info.
>>
>
> That makes sense.
>
> With respect to the suffix, I keep coming back to the reality
>> that even if GCC were to change to emit a format that GDB can
>> interpret easily and efficiently, there still are other
>> compilers that emit a different format.  So the conclusion
>> that a general solution that handles more than just one format
>> (at least for non-type template arguments without auto) seems
>> unescapable.
>>
>
> If there are other compilers we wanted to support for which we can't trust
> the template format, we could always ignore the template part of DW_AT_name
> specifically for them.  But since g++ and gdb are part of the same project
> and are expected to work well and efficiently together, I would have hoped
> that we could agree on a format so that gdb would not have to do the extra
> work when parsing a g++-generated file (consequently the same format that
> libiberty's demangler produces).
>
> Given the problem I illustrated in my previous mail, I don't have a
> general solution to the problem to propose.
>
> Simon
>

Re: gdb 8.x - g++ 7.x compatibility

[Simon Marchi]

On 2018-02-05 11:45, Martin Sebor wrote:

Yes, with auto, the type of the constant does determine the type
of the specialization of the template in the source code.

In non-type template arguments, and more to the point I was making,
in diagnostics, the suffix shouldn't or doesn't need to be what
distinguishes the type of the template, even with auto.  The part
"with auto IVAL = 10" in the message

  'void foo::print() [with auto IVAL = 10]':

would be far clearer if auto were replaced by the deduced type,
say along these lines:

  'void foo::print() [with int IVAL = 10]':

rather than relying on the suffix alone to distinguish between
different specializations of the template.  That seems far too
subtle to me.  But I think the diagnostic format is (or should
be) independent of the debug info.


That makes sense.


With respect to the suffix, I keep coming back to the reality
that even if GCC were to change to emit a format that GDB can
interpret easily and efficiently, there still are other
compilers that emit a different format.  So the conclusion
that a general solution that handles more than just one format
(at least for non-type template arguments without auto) seems
unescapable.


If there are other compilers we wanted to support for which we can't 
trust the template format, we could always ignore the template part of 
DW_AT_name specifically for them.  But since g++ and gdb are part of the 
same project and are expected to work well and efficiently together, I 
would have hoped that we could agree on a format so that gdb would not 
have to do the extra work when parsing a g++-generated file 
(consequently the same format that libiberty's demangler produces).


Given the problem I illustrated in my previous mail, I don't have a 
general solution to the problem to propose.


Simon

Re: gdb 8.x - g++ 7.x compatibility

[Martin Sebor]

On 02/04/2018 10:06 PM, Simon Marchi wrote:

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?


Yes, with auto, the type of the constant does determine the type
of the specialization of the template in the source code.

In non-type template arguments, and more to the point I was making,
in diagnostics, the suffix shouldn't or doesn't need to be what
distinguishes the type of the template, even with auto.  The part
"with auto IVAL = 10" in the message

  'void foo::print() [with auto IVAL = 10]':

would be far clearer if auto were replaced by the deduced type,
say along these lines:

  'void foo::print() [with int IVAL = 10]':

rather than relying on the suffix alone to distinguish between
different specializations of the template.  That seems far too
subtle to me.  But I think the diagnostic format is (or should
be) independent of the debug info.


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.


I'm afraid I know too little about the internals of GDB to
fully appreciate the importance of this problem or have
an idea how it could be handled.

With respect to the suffix, I keep coming back to the reality
that even if GCC were to change to emit a format that GDB can
interpret easily and efficiently, there still are other
compilers that emit a different format.  So the conclusion
that a general solution that handles more than just one format
(at least for non-type template arguments without auto) seems
unescapable.

For auto, since it's new, a viable alternative might be to
standardize the debug info format so that eventually all
producers will converge on it. But even that approach won't
help users of existing compilers.

Martin



Simon

[1] 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/te

Re: Debugging optimizer problems

[David Brown]

On 02/02/18 23:03, jacob navia wrote:
> Le 02/02/2018 à 22:11, Florian Weimer a écrit :
>> * jacob navia:
>>
>>> I have in my small C compiler introduced the following construct:
>>>
>>> #pragma optimize(on/off,push/pop)
>> Not sure what you are after.  GCC has something quite similar:
>>
>> 
>>
> 
> Great!
> 
> I had never seen it, and the docs in my machine weren't very explicit
> about that.
> 
> I apologize for the noise and thank you for pointing me to that doc.
> 
> jacob
> 
> 

You will find gcc manuals for many versions of the tools at
.

In your debugging, I find the most common causes of "it works when
optimisation is disabled" to be aliasing problems, integer overflow
issues, or missing volatiles (that is more common in my world of
embedded programming, rather than PC software).  So rather than just:

#pragma GCC optimize("-O2")

and

#pragma GCC optimize("-O0")

I'd recommend testing with

#pragma GCC optimize("-fno-strict-aliasing")

and

#pragma GCC optimize("-fwrapv")

to see if that helps you isolate your problems quickly.

And if you have a reasonably modern gcc, try out the -fsanitize options
- they can be a great help in spotting bugs at run-time.

Resolving LTO symbols for static library boundary

[Allan Sandfeld Jensen]

Hello GCC

In trying to make it possible to use LTO for distro-builds of Qt, I have again 
hit the problem of static libraries. In Qt in general we for LTO rely on a 
library boundary, where LTO gets resolved when generating the library but no 
LTO-symbols are exported in the shared library. This ensure the library has a 
well defined binary compatible interface and gets LTO optimizations within 
each library. For some private libraries we use static libraries however, 
because we don't need binary compatibility, but though we don't need BC 
between Qt versions, the libraries should still be linkable with different gcc 
versions (and with different compilers). However when LTO is enabled the 
static libraries will contain definitions that depend on a single gcc version 
making it unsuitable for distribution.

One solution is to enable fat-lto object files for static libraries but that 
is both a waste of space and compile time, and disables any LTO optimization 
within the library. Ideally I would like to have the static library do LTO 
optimizations internally just like a shared library, but then exported as 
static library.

I suspect this is more of gcc task than ar/ld task, as it basically boils down 
to gcc doing for a static library what it does for shared library, but maybe 
export the result as a single combined .o file, that can then be ar'ed into a 
compatible static library.

Is this possible?

Best regards
'Allan Jensen

Re: gdb 8.x - g++ 7.x compatibility

[Jonathan Wakely]

On 4 February 2018 at 19:17, Martin Sebor wrote:
> 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.

The change is a little unfortunate, I pointed out the problems for
debuginfo and template recently in another context:
https://sourceware.org/bugzilla/show_bug.cgi?id=21492#c1

As I said there, simply comparing strings from the debuginfo is
insufficient for Clang anyway. Now it is for GCC too.

Re: gdb 8.x - g++ 7.x compatibility

[Jonathan Wakely]

On 5 February 2018 at 09:16, Stephan Bergmann wrote:
> On 05.02.2018 06:06, Simon Marchi wrote:
>>
>> 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?
>
>
> Yes, for non-type template parameters whose type contains a placeholder type
> (i.e., "auto IVAL" in the earlier example), which is a new feature of C++17.

Right, for C++14 saying foo<2> is entirely unambiguous because the
type of the template parameter is fixed. For C++17 a template declared
as "template class foo" can be instantiated with different
types, so foo<2> and foo<2u> don't refer to the same specialiation.

> My understanding is that printing the suffix would be essential in such
> cases.

Not sufficient, it doesn't help distinguish foo<(short)2>, foo<(int)2>
or foo<(signed char)2> because there is no suffix for signed/unsigned
short or signed/unsigned char.

Re: gdb 8.x - g++ 7.x compatibility

[Stephan Bergmann]

On 05.02.2018 06:06, Simon Marchi wrote:

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?


Yes, for non-type template parameters whose type contains a placeholder 
type (i.e., "auto IVAL" in the earlier example), which is a new feature 
of C++17.


My understanding is that printing the suffix would be essential in such 
cases.