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

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

Re: Resolving LTO symbols for static library boundary

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 bound

Re: Debugging optimizer problems

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 furth

Copyright Assignment

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 cop

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

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

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

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

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/

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

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 partic

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

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-mingw

Re: Resolving LTO symbols for static library boundary

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 gene

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

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 ty

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

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

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

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

Re: Debugging optimizer problems

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: >> >>

Resolving LTO symbols for static library boundary

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 e

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

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 par

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

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 >>> templat

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

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