-Original Message-
From: Andrew Pinski
Sent: Friday, July 12, 2024 1:20 PM
To: Dalbey, Keith
Cc: Jonathan Wakely ; gcc@gcc.gnu.org
Subject: Re: [EXTERNAL] Re: g++12 broke my system of overloaded operator<<
On Fri, Jul 12, 2024 at 12:10 PM Dalbey, Keith via Gcc wrote:
>
>
On Fri, 12 Jul 2024 at 20:08, Dalbey, Keith wrote:
>
> The means by which this FIX was implemented caused OTHER problems
>
> template
> std::ostream& operator<<(std::ostream& os, const std::pair& pr)
> {
> os << "(" << pr.first << ", " << pr.second << ")";
> return os;
> }
>
> Wil
eed to forward declare some of the contents of the .cpp
> file ahead of including this header file)
>
> But really a header file that can't be included in other header files and can
> only be included as the absolute last header file in a .cpp file is a
> unreasonable set of hoops
On Fri, 12 Jul 2024 at 20:08, Dalbey, Keith wrote:
>
> The means by which this FIX was implemented caused OTHER problems
>
> template
> std::ostream& operator<<(std::ostream& os, const std::pair& pr)
> {
> os << "(" << pr.first << ", " << pr.second << ")";
> return os;
> }
>
> Wil
On Fri, 12 Jul 2024 at 17:58, Dalbey, Keith via Gcc wrote:
>
> I'm not going to argue about the change for CONCRETE operators, I'm going to
> argue about the loss of power/flexibility for TEMPLATED operators, because it
> defeats the whole purpose of TEMPLATED functions/operators otherwise
This
But really a header file that can't be included in other header files and can
only be included as the absolute last header file in a .cpp file is a
unreasonable set of hoops to jump through to get TEMPLATED operator<< 's to
work, which should just work BECAUSE THEY'RE TEMP
On Fri, 12 Jul 2024 at 01:03, Dalbey, Keith via Gcc wrote:
>
> So I'm on redhat 7 and just got devtoolsset-12 and code (a system of
> overloaded<< operators) that was working with devtoolset-10 now break
> (because of ordering)
>
> To not bury the lead..
>
> My code relies on the version 11 or o
albey, Keith
Sent: Friday, July 12, 2024 10:58 AM
To: Andrew Pinski
Cc: gcc@gcc.gnu.org
Subject: RE: [EXTERNAL] Re: g++12 broke my system of overloaded operator<<
I'm not going to argue about the change for CONCRETE operators, I'm going to
argue about the loss of power/flexibility fo
operator<<'s SHOULD still just work without undoing your fix
for CONCRETE operators
Not sure how the compiler would know whether the current file was the FIRST
file or not, but it seems like the same problem that had to be solved for class
declarations/definitions when there are method
On Thu, Jul 11, 2024 at 5:04 PM Dalbey, Keith via Gcc wrote:
>
> So I'm on redhat 7 and just got devtoolsset-12 and code (a system of
> overloaded<< operators) that was working with devtoolset-10 now break
> (because of ordering)
>
> To not bury the lead..
>
> My code relies on the version 11 or
So I'm on redhat 7 and just got devtoolsset-12 and code (a system of
overloaded<< operators) that was working with devtoolset-10 now break (because
of ordering)
To not bury the lead..
My code relies on the version 11 or older behavior (see below), and I don't see
how anyone could call the new
Hello,
This mailing list is for discussion the development of GCC itself.
Please use the gcc-help mailing list for help questions. Please send
any replies to that list instead of this one, thanks.
On Thu, 28 Mar 2024 at 09:35, shaoben zhu via Gcc wrote:
>
> I compile my program using g++
I compile my program using g++ 4.8.5, I find that when my program exits, it
first deconstructs the static member variables of class A, and then
deconstructs a global object of class A. This caused an error in my program.
Could you tell me how can I avoid this problem?Upgrade compiler
version
On Sat, Feb 10, 2024 at 07:35:22PM +0100, Marc Glisse wrote:
> On Sat, 10 Feb 2024, Steve Kargl via Gcc wrote:
>
> > So, how does one biulding all parts of gcc with "-O -g"?
> >
> > In my shell script, I have
> >
> > CFLAGS="-O -g"
> &g
On Sat, 10 Feb 2024, Steve Kargl via Gcc wrote:
So, how does one biulding all parts of gcc with "-O -g"?
In my shell script, I have
CFLAGS="-O -g"
export CFLAGS
CXXFLAGS="-O -g"
export CXXFLAGS
BOOT_CFLAGS="-O -g"
export BOOT_CFLAGS
../gcc/configure
So, how does one biulding all parts of gcc with "-O -g"?
In my shell script, I have
CFLAGS="-O -g"
export CFLAGS
CXXFLAGS="-O -g"
export CXXFLAGS
BOOT_CFLAGS="-O -g"
export BOOT_CFLAGS
../gcc/configure --prefix=$HOME/work --enable-languages=c,c++,
Hi Ben,
This has fallen between the cracks.
On Mon, 9 Oct 2023, Ben Boeckel wrote:
> On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> > I'm seeing these tracebacks for several cases across the G++ testsuite:
> >
> > Executing on host: pyth
tring a = f(a);
}
Compile and run (no warning):
$ g++ -o uninit_obj uninit_obj.cpp -std=c++23 -Wall -Wpedantic -
Wextra
&& ./uninit_obj
Segmentation fault (core dumped)
No difference whether using -O0 (or 1 2 3)
As I understand it, -Wmaybe-uninitialized is purely intraprocedural
i.e
end("x");
> return s;
> }
> int main() {
> std::string a = f(a);
> }
>
> Compile and run (no warning):
>
> $ g++ -o uninit_obj uninit_obj.cpp -std=c++23 -Wall -Wpedantic -
> Wextra
> && ./uninit_obj
> Segmentation fault (core dumped)
&
uld have generated a warning, which have saved some
head-scratching.
Code to reproduce:
#include
std::string f(std::string &s) {
s.append("x");
return s;
}
int main() {
std::string a = f(a);
}
Compile and run (no warning):
$ g++ -o uninit_obj uninit_obj.cpp -std=c++23 -Wall -
On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> Hi,
>
> I'm seeing these tracebacks for several cases across the G++ testsuite:
>
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)"
>(timeout = 300)
> spa
On Mon, Oct 09, 2023 at 19:46:37 -0400, Paul Koning wrote:
>
>
> > On Oct 9, 2023, at 7:42 PM, Ben Boeckel via Gcc wrote:
> >
> > On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> >> I'm seeing these tracebacks for several cases across t
> On Oct 9, 2023, at 7:42 PM, Ben Boeckel via Gcc wrote:
>
> On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
>> I'm seeing these tracebacks for several cases across the G++ testsuite:
>>
>> Executing on host: python3 -c "import sys;
On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> I'm seeing these tracebacks for several cases across the G++ testsuite:
>
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)"
>(timeout = 300)
> spawn -ignore SIG
Hi,
I'm seeing these tracebacks for several cases across the G++ testsuite:
Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)"
(timeout = 300)
spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
rules/0/primary-ou
3 09:22, Thomas Schwinge wrote:
Hi!
On 2023-09-20T07:08:25+0200, François Dumont via Gcc wrote:
I've configured libstdc++ with --enable-symvers=gnu-versioned-namespace
I can't comment on that option...
and run make check-c++.
A number of failures are like this one:
/home/fdumont/de
Hi!
On 2023-09-20T07:08:25+0200, François Dumont via Gcc wrote:
> I've configured libstdc++ with --enable-symvers=gnu-versioned-namespace
I can't comment on that option...
> and run make check-c++.
>
> A number of failures are like this one:
>
> /home/fdumont/dev/
I've configured libstdc++ with --enable-symvers=gnu-versioned-namespace
and run make check-c++.
A number of failures are like this one:
/home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C:
In function 'coro1 f()':
/home/fdumont/dev/gcc/git/
On Thu, 16 Mar 2023 at 17:45, oszibarack korte via Gcc wrote:
>
> *An unsolved problem for more than a decade!*
> *Dear GNU Compiler Collection development team!*
>
> *There is a problem with the gcc and g++ compilers for Linux operating
> systems!*
> *Here are 3 pieces o
On Thu, Mar 16, 2023 at 10:46 AM oszibarack korte via Gcc
wrote:
>
> *An unsolved problem for more than a decade!*
> *Dear GNU Compiler Collection development team!*
>
> *There is a problem with the gcc and g++ compilers for Linux operating
> systems!*
> *Here are 3 pieces o
*An unsolved problem for more than a decade!*
*Dear GNU Compiler Collection development team!*
*There is a problem with the gcc and g++ compilers for Linux operating
systems!*
*Here are 3 pieces of C and 3 pieces of C++ source code.*
*- Please compile them on any LINUX!- Run it!- Compare the
Hello. We use g++ to compile our big project and we use many 3rd party
libraries and frameworks inside(like Qt or Poco). Some of these
frameworks generate many warnings, so we use flag isystem to mark them
as system to suppress 3dparty warnings. But it seems not all warnings
suppressing by
rmats, like
> DWARF have a number in their name (dwarf2) that might not reflect
> actually reflext the version of that format (except for it being not-
> dwarf1). That is why I was suggesting to use -fdwarf(32|64) instead of
> -gdwarf(32|64) to use for 32 bits vs 64 bits offsets in dw
too many -gdwarf[number] options.
The idea of having any of the -fs not imply -g and having
any of the -gs imply -g seems a good one.
But in general I think these suboptions are all a bit nonsense though.
They are great for tinkering and playing with corner cases of the
debugging format. But I
r
> > Mark Mitchell added the first one. I'm not sure why we didn't rename it
> right
> > then. I'll bet there are other -foptions that don;t match my
> comfortable world
> > view :)
>
> Appreciate the perspective, for sure!
>
> It sounds like s
tions that don;t match my comfortable
> world
> view :)
Appreciate the perspective, for sure!
It sounds like some folks who've worked on this a fair bit (at least
myself, Eric Christopher, and Cary Coutant) have had a different
perspective for quite a while - that -g flags generally turn on de
d many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
A non-complete list of GCC supported debug options is documented here at
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
I think there options belong to 3 categories:
(a)
On Thu, Jul 9, 2020 at 12:03 PM Fangrui Song wrote:
>
> Both GCC and Clang have implemented many debugging options under -f and
> -g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
>
> A non-complete list of GCC supported debug options is documented
Fix email addresses:)
On 2020-07-09, Fangrui Song wrote:
Both GCC and Clang have implemented many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
A non-complete list of GCC supported debug options is documented here at
https
Both GCC and Clang have implemented many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
A non-complete list of GCC supported debug options is documented here at
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
I think there
Sent from my iPhone
Your question is inappropriate on this mailing list, and I already
answered it on the gcc-help list anyway.
On Thu, 28 May 2020 at 18:22, kiran kumar vangara via Gcc
wrote:
>
> Team,
>
> We have been compiling cpp files with g++ compiler on Redhat Linux OS
> machine and as p
Team,
We have been compiling cpp files with g++ compiler on Redhat Linux OS
machine and as part of this -mt option was given for g++ and it produced
required binary in case # 1 but produced an error in case#2 , I'm sharing
g++ version and the Redhat Linux OS version being used to compile th
On Thu, 16 Apr 2020 at 21:02, Baumanns via Gcc wrote:
>
> Hello gcc Team,
>
> currently I work on some very modern c++ projects based on c++20. For my
> tests I would like to compile my code with all three major compilers: g++,
> msvc and llvm/clang to test the latest featu
Hello gcc Team,
currently I work on some very modern c++ projects based on c++20. For my
tests I would like to compile my code with all three major compilers: g++,
msvc and llvm/clang to test the latest features (like co_yield).
Furthermore I have problems with unicode header names
有各种发票可幵出电+微:13 7\644【 有 】↓【3%-13%】【 増 】各【 发 】【 稙 】种【 票 】【 税 】真【 幵 】
如果你不想再收到该产品的推荐邮件, 请点击这里退订
提供各种发票幵:1 3 6;922 275 95张【 有 】↓【3%-13%】【 増 】各【 发 】 【 稙 】种【 票 】【 税 】真【 幵 】
如果你不想 再收到该产品的推荐邮件, 请点击这里退订
您好，我司我司可以代理各种税票（公司做账报税，业务出差报销等），票据可拿到当地税务验证，或者官网上查询后付款！咨询小林微信：UFO66808（微信同号）
林经理低点数就能【开-真-票】
On 12 June 2018 at 06:49, 刘超杰 wrote:
> Hi:
> When I was using g++, I found a problem, maybe which is a bug or not.
This is the wrong mailing list for your question. Please use the
gcc-h...@gcc.gnu.org list for help and questions about GCC.
> It is about the order of object files neede
Hi:
When I was using g++, I found a problem, maybe which is a bug or not. It is
about the order of object files needed to link, if you change the order of
files, the result is different. I can duplicate the problem, and I have write
an example, whose git address is:
https://github.com/Erician
This problem turned out to be because the objects in
libasan.a of gcc-6-branch are built with -fPIC / -DPIC :
if 'PIC' is defined, the code in asan_linux.c is
assuming it has been dynamically loaded , and so
does not allow libasan.so NOT to be the first
required dynamic library. But adding '-lasa
To me it looks like the definition of 'real_sigaction'
in 'asan_interceptors.cc' is actually going to
recursively call itself - so I tried patching
libsanitizer:
{BEGIN PATCH:
Index: asan/asan_interceptors.cc
===
--- asan/asan_interc
Good day -
Attempts to build latest GCC gcc-6-branch version from SVN ( Revision
260441 ), with the GCC 6.4.1 from the last time I built it ( git
commit starting '4f2cbe2' ), now fail in 'make check' , on a Linux
x86_64 host (RHEL 7.5, glibc 2.17) :
When 'pr59063-2.c' is built with the '-static-
On Tue, May 01, 2018 at 12:53:45PM -0700, Chengnian Sun wrote:
> Does gcc have a requirement about the impact of emitting debug info on the
> generated code? Should the code be the same no matter whether '-g' is
> specified?
Yes (except for selective scheduling, but that w
Hi,
Does gcc have a requirement about the impact of emitting debug info on the
generated code? Should the code be the same no matter whether '-g' is
specified?
Thank you.
--
Best Regards.
Chengnian
On 04/24/2018 01:05 AM, Jakub Jelinek wrote:
On Mon, Apr 23, 2018 at 10:15:57PM -0600, Sandra Loosemore wrote:
Can somebody remind me why using -g doesn't also enable -fvar-tracking by
default? At least for -g2, which is supposed to emit debug information
about local variables? It seems
On Mon, Apr 23, 2018 at 10:15:57PM -0600, Sandra Loosemore wrote:
> Can somebody remind me why using -g doesn't also enable -fvar-tracking by
> default? At least for -g2, which is supposed to emit debug information
> about local variables? It seems kind of counterintuit
Can somebody remind me why using -g doesn't also enable -fvar-tracking
by default? At least for -g2, which is supposed to emit debug
information about local variables? It seems kind of counterintuitive to
me that specifying a -O option enables a pass to collect better debug
informatio
01 13:03 GMT-08:00 Jason Merrill :
>
> > On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski wrote:
> > > On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov
> wrote:
> > >> Is there any progress on this problem?
> > >>
> > >> I'm not fami
> hard to propagate it to object file.
>
> I will ask on LLVM maillist if they can emit it.
>
>
> 2018-03-01 13:03 GMT-08:00 Jason Merrill :
>
>> On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski wrote:
>> > On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov wrote:
>
Popov wrote:
> >> Is there any progress on this problem?
> >>
> >> I'm not familiar with G++ , but I have little experience with LLVM. I
> can
> >> try make LLVM emitting mangled names to DW_AT_name, instead of demangled
> >> ones.
> >
On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski wrote:
> On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov wrote:
>> Is there any progress on this problem?
>>
>> I'm not familiar with G++ , but I have little experience with LLVM. I can
>> try make LLVM emitting mangled
On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov wrote:
> Is there any progress on this problem?
>
> I'm not familiar with G++ , but I have little experience with LLVM. I can
> try make LLVM emitting mangled names to DW_AT_name, instead of demangled
> ones.
> This way G
Is there any progress on this problem?
I'm not familiar with G++ , but I have little experience with LLVM. I can
try make LLVM emitting mangled names to DW_AT_name, instead of demangled
ones.
This way GDB can match DW_AT_name against RTTI. And for display it can
call abi::__cxa_demangle
On Mon, Feb 5, 2018 at 6:06 AM, 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-t
On 8 February 2018 at 14:05, Paul Smith wrote:
> Isn't the problem with the mangled name, which otherwise would be just
> what we wanted since it's easy to match and is unique in just the way
> we want it to be, that mangling is not standardized?
No, because mangling is standardized:
http://itaniu
On Thu, 2018-02-08 at 11:26 +, Michael Matz wrote:
> As I said upthread, the mangled name of a type (sans _Z prefix) is what is
> stored as the type name for RTTI purposes (i.e. std::type_info::name()).
>
> It's just that the debug info currently doesn't have any reference to that
> definite
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
> On 2018-02-07 12:30, Jonathan Wakely wrote:
> >> Ah ok, the class name appears mangled in other entities' mangled name. But
> >> from what I understand there's no mangled name for the class such that
> >>
> >> echo | c++filt
> >>
> >> outputs the
On 02/07/2018 12:11 PM, Daniel Berlin wrote:
Note that the ABI is explicitly designed so that type identity can be done
by address comparison.
correct, but be aware that lots of dynamic objects seem to step outside
the ABI by building shared objects with -Bsymbolic[1], or the equivalent
vis
> "Dan" == Daniel Berlin writes:
Dan> If there are multiple types named Foo<2u>, DWARF needs to be extended to
Dan> allow a pointer from the vtable debug info to the class type debug info
Dan> (unless they already added one).
This is what we did for Rust.
Rust doesn't have a stable ABI yet,
On 2018-02-07 12:30, Jonathan Wakely wrote:
Ah ok, the class name appears mangled in other entities' mangled name.
But
from what I understand there's no mangled name for the class such that
echo | c++filt
outputs the class name (e.g. "Foo<10>"). That wouldn't make sense,
since
there's n
template argument of another type, or in the
std::type_info::name() for the type etc. etc.
$ g++ -o test.o -c -x c++ - <<< 'struct X {}; void f(X) {}
template struct Y { }; void g(Y) {}' && nm
--defined-only test.o
T _Z1f1X
0007 T _Z1g1YI1XE
T
u need a name for linkage purposes, such as in a function
>> signature, or as a template argument of another type, or in the
>> std::type_info::name() for the type etc. etc.
>>
>> $ g++ -o test.o -c -x c++ - <<< 'struct X {}; void f(X) {}
>> temp
std::type_info::name() for the type etc. etc.
$ g++ -o test.o -c -x c++ - <<< 'struct X {}; void f(X) {}
template struct Y { }; void g(Y) {}' && nm
--defined-only test.o
T _Z1f1X
0007 T _Z1g1YI1XE
The mangled name for X is "X" and th
think we have some issues
even before that, like how to support g++ 7.3 and up. I'll try to
summarize the issue quickly. It's now possible to end up with two
templated classes with the same name that differ only by the
signedness
of their non-type template parameter. One is Foo and the
>
>
> This avoids the problem of the demangler gdb is using getting a different
> name than the producer used. It also should always give you the right one.
> If the producer calls the type "vtable fo Foo<2u>" here and "Foo<2>"
> elsewhere, yes, that's a bug. It should be consistent.
>
>
This shoul
t;>
>>>> On Wed, 7 Feb 2018, Simon Marchi wrote:
>>>>
>>>>> This addresses the issue of how to do good software design in GDB to
>>>>> support different producers cleanly, but I think we have some issues
>>>>> even before that,
ften slow come from.
>> If we just detected and said "this is gcc 6, it behaves like this", we
>> wouldn't need to do that)
>>
>> In case you are worried, you will discover this is how a bunch of stuff is
>> done and already contains a ball of hacks.
&
producers cleanly, but I think we have some issues
>>> even before that, like how to support g++ 7.3 and up. I'll try to
>>> summarize the issue quickly. It's now possible to end up with two
>>> templated classes with the same name that differ only by the signed
On 2018-02-07 11:26, Michael Matz wrote:
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
This addresses the issue of how to do good software design in GDB to
support different producers cleanly, but I think we have some issues
even before that, like how to support g++ 7.3 and up. I'll t
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
> This addresses the issue of how to do good software design in GDB to
> support different producers cleanly, but I think we have some issues
> even before that, like how to support g++ 7.3 and up. I'll try to
> summarize the is
before that, like how to support g++ 7.3 and up. I'll try to summarize the
issue quickly. It's now possible to end up with two templated classes with
the same name that differ only by the signedness of their non-type template
parameter. One is Foo and the other is Foo (the 10
is unsigned).
d 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 bot
detected and said "this is gcc 6, it behaves like this", we
>>> wouldn't need to do that)
>>>
>>> In case you are worried, you will discover this is how a bunch of stuff
>>> is
>>> done and already contains a ball of hacks.
>>>
>
s the issue of how to do good software design in GDB to
support different producers cleanly, but I think we have some issues
even before that, like how to support g++ 7.3 and up. I'll try to
summarize the issue quickly. It's now possible to end up with two
templated classes with th
e design in GDB to
support different producers cleanly, but I think we have some issues
even before that, like how to support g++ 7.3 and up. I'll try to
summarize the issue quickly. It's now possible to end up with two
templated classes with the same name that differ only by the sign
>> 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
>>
n 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
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 wor
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.
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.cpprefe
rantees 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
> alg
everal 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
e 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 expe
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
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
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
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
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<
me 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
1 - 100 of 1182 matches
Mail list logo
