Re: GNAT on GCC 10.x has build problems

Did you know it's possible to read my post and ruminate upon its meaning without responding this way? I bet you didn't know that. I'm not asking for any of your 'help', in case it wasn't obvious. I'm quite used to solving the GCC project's problems myself by now, since the GCC project seems det

Re: GNAT on GCC 10.x has build problems

On Sun, 3 Dec 2023, 18:19 Dave Blanchard, wrote: > Hello all, while bootstrapping GNAT onto my cross compiled system with GCC > 10.x I found that the make script leaves something to be desired. > > First off it doesn't add the host prefix to the cross compiler binaries; &g

GNAT on GCC 10.x has build problems

Hello all, while bootstrapping GNAT onto my cross compiled system with GCC 10.x I found that the make script leaves something to be desired. First off it doesn't add the host prefix to the cross compiler binaries; it calls gnatmake, gnatlink, gnatbind, gnatls, and gcc without the x86_64-

Re: Configuring GCC 10.3 on PPC Mac OS X 10.4.11/Tiger for build reveals problems when removing relics

Hi Pete, > On 25 Nov 2022, at 10:36, Peter Dyballa via Gcc wrote: > On Mac OS X/macOS configure scripts leave conftest.dSYM subdirectories > behind, created by dsymutil: > > checking for build system preprocessor... rm: conftest.dSYM: is a > directory > chec

Configuring GCC 10.3 on PPC Mac OS X 10.4.11/Tiger for build reveals problems when removing relics

Hello! On Mac OS X/macOS configure scripts leave conftest.dSYM subdirectories behind, created by dsymutil: checking for build system preprocessor... rm: conftest.dSYM: is a directory checking for build system executable suffix... rm: conftest.dSYM: is a directory

Re: Update of git-hooks (uses Python 3.x)?

On Mon, 3 Jan 2022, Martin Liška wrote: > Hello. > > Note that binutils updated the git-hooks, which now uses Python 3: > https://github.com/AdaCore/git-hooks > > I'm asking because we're facing again an encoding issue (spotted by Jakub): I expect this is

Update of git-hooks (uses Python 3.x)?

Hello. Note that binutils updated the git-hooks, which now uses Python 3: https://github.com/AdaCore/git-hooks I'm asking because we're facing again an encoding issue (spotted by Jakub): remote: Traceback (most recent call last): remote: File "hooks/post_receive.py", line 118, in remote:

Error for unknown spec function 'dumps' when compiling GCC 11.X

Dear GCC community, when I try to compile a 11 Version of GCC I get while compiling in the directory …./gcc-11.2.0/host-x86_64-pc-linux-gnu/gcc the following: x86_64-pc-linux-gnu-g++ -std=c++11 -fno-PIE ….. ../.././gcc/cp/g++spec.c error occurs: x86_64-pc-linux-gnu-g++: fatal error: unknown spec

[PATCH 5/5] libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x

gthr-vxworks-thread.c fails to compile for vxworks 5.x: libgcc/config/gthr-vxworks-thread.c:268:14: error: 'VX_USR_TASK_OPTIONS' undeclared (first use in this function) 268 | options &= VX_USR_TASK_OPTIONS; | ^~~ libgcc/config/gthr-vxworks-

[PATCH 4/5] libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x

The vxworks-cond.c file fails to compile for vxworks 5.x: libgcc/config/gthr-vxworks-cond.c:29: ./gthr-default.h:274:3: error: unknown type name 'TASK_ID' 274 | TASK_ID task_id; | ^~~ There is a TASK_ID typedef in our system headers, but (1) is is commented out, (2) liv

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

On 3/9/20 11:25 AM, Jakub Jelinek wrote: On Mon, Mar 09, 2020 at 10:46:31AM +0100, Tobias Burnus wrote: Hi Thomas, hi Overseers I can confirm that those are stripped off! I did sent an email with three attachments: * test.txt (text/plain) * test.diff (text/x-diff) * the company's discl

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

On Mon, 9 Mar 2020 at 10:28, Jakub Jelinek wrote: > 6) there used to be a Raw text URL to grab the raw email, now there is nothing Based on info from #overseers ... While you can't download the raw text of an individual email now, you can get the entire month's mail in a compressed archive, from

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

On Mon, 9 Mar 2020 at 19:57, Thomas König wrote: > As far as the advantages go: A per-thread view is nice, but I don't > think having it outweighs the disadvantages above. We always had a threaded view: https://gcc.gnu.org/legacy-ml/gcc-bugs/2020-03/threads.html It just wasn't the default: https:/

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

On Mon, 9 Mar 2020, Jakub Jelinek via Overseers wrote: > 5) emails used to be sanitized against harvesters, now they aren't The pipermail munging feature was unusably bad (it messed up Texinfo diffs very badly, including in the mbox version of the archive, e.g. "+@node" at the start of a line w

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

Hi, Some comments. Generally, I found the old format to be very good for navigating, and I would like to have the new one match the old one as closely as possible. 1) the by date monthly list of mails used to be ordered newest to oldest mails first, now it is oldest to newest, so when dealing

Re: text/x-* attachments stripped

On 3/9/20 1:07 PM, Jonathan Wakely wrote: On Mon, 9 Mar 2020 at 16:58, Nathan Sidwell wrote: On 3/9/20 9:57 AM, Thomas König wrote: Hi, I concur with what Jakub wrote. The new web interface is much less useful than the old one; a severe regression for developers, so to speak. OMG I've just

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline

On Mon, 9 Mar 2020 at 16:58, Nathan Sidwell wrote: > > On 3/9/20 9:57 AM, Thomas König wrote: > > Hi, > > > > I concur with what Jakub wrote. The new web interface is much less useful > > than the old one; a severe regression for developers, so to speak. > > OMG I've just looked. It's awful. Sor

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline

On Mär 09 2020, Nathan Sidwell wrote: > For example https://gcc.gnu.org/pipermail/gcc-patches/2020-March/date.html > just gives a list of emails, no dates shown. There's no indication what > the ordering is -- and apparently it is not most recent first. Heading says: Starting: Sun Mar 1 01:37:0

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline

On 3/9/20 9:57 AM, Thomas König wrote: Hi, I concur with what Jakub wrote. The new web interface is much less useful than the old one; a severe regression for developers, so to speak. OMG I've just looked. It's awful. Sorry, but No. For example https://gcc.gnu.org/pipermail/gcc-patches/20

Re: text/x-* attachments strippe

Hi - Thanks for the kind words. > Could this have gone a bit smoother? Yes. More collaborative? Maybe. We tried: the plan to migrate to mailman was included by reference from the systemwide announcement blast two weeks ago: https://sourceware.org/sourceware-wiki/MigrationStatus/ We continue to

Re: text/x-* attachments strippe

On Mon, 9 Mar 2020, Thomas König wrote: > I also seem to have missed all discussion on this change (if there was > anything). I do not understand why such a huge change was implemented > that way, and who did this. Perhaos the person(s) responsible could > speak up about this. Let's be careful

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

Hi, I concur with what Jakub wrote. The new web interface is much less useful than the old one; a severe regression for developers, so to speak. I also seem to have missed all discussion on this change (if there was anything). I do not understand why such a huge change was implemented that way,

Re: text/x-* attachments stripped

On Mär 09 2020, Jonathan Wakely wrote: > I use that to reply to mails that I don't have in my mailbox, because > I'm not sub'd to the list. With the raw text link you could download a > mailbox file of the mail, and so open it in your local MUA and reply > (with a correct In-Reply-To header, so th

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

On Mon, 9 Mar 2020 at 10:28, Jakub Jelinek wrote: > 1) the by date monthly list of mails used to be ordered newest to oldest > mails first, now it is oldest to newest, so when dealing with new stuff one > has to always scroll down You can use #end to jump to the bottom. > 6) there used to be a Ra

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

On Mon, Mar 09, 2020 at 10:46:31AM +0100, Tobias Burnus wrote: > Hi Thomas, hi Overseers > > I can confirm that those are stripped off! > > I did sent an email with three attachments: > * test.txt (text/plain) > * test.diff (text/x-diff) > * the company's discla

text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

Hi Thomas, hi Overseers I can confirm that those are stripped off! I did sent an email with three attachments: * test.txt (text/plain) * test.diff (text/x-diff) * the company's disclaimer The attachment with 'text/x-diff' MIME was removed :-( See: https://gcc.gnu.org/pipermail/

Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments)

> CC overseers. > > they are not stripped – I do see them both in my inbox and at > https://gcc.gnu.org/pipermail/fortran/2020-March/054050.html They were stripped for me :-( I even mailed Paul about the (for me) missing attachment. Not sure what is going on there, but whatever change was made

gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments)

CC overseers. they are not stripped – I do see them both in my inbox and at https://gcc.gnu.org/pipermail/fortran/2020-March/054050.html However, attachments of the "text/x-…" format (here: text/x-patch) are no longer shown inline but have to be downloaded (with the inconvenient su

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

Hi Sebastian, On 2/27/20 4:53 PM, Pop, Sebastian wrote: Hi, is somebody already working on backporting -moutline-atomics to gcc 8.x and 9.x branches? I'm not aware of such work going on. Thanks, Kyrill Thanks, Sebastian

[AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

Hi, is somebody already working on backporting -moutline-atomics to gcc 8.x and 9.x branches? Thanks, Sebastian

Re: if (x > ((2^x)-1)) optimization

: >>>>> More generally, we can rewrite >>>>> >>>>> if ( x > ((1 << z) -1)) { ...} >>>>> >>>>> as >>>>> >>>>> if ( x >> z ) { ... } >>>>> >>>>> This d

Re: if (x > ((2^x)-1)) optimization

On Sat, Jun 22, 2019 at 03:30:15PM -0600, Jeff Law wrote: > On 6/22/19 12:44 PM, Segher Boessenkool wrote: > > On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote: > >> On 6/22/19 7:55 AM, Jason Duerstock wrote: > >>> More generally, we can rewrite >

Re: if (x > ((2^x)-1)) optimization

On 6/22/19 12:44 PM, Segher Boessenkool wrote: > On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote: >> On 6/22/19 7:55 AM, Jason Duerstock wrote: >>> More generally, we can rewrite >>> >>> if ( x > ((1 << z) -1)) { ...} >>> >>>

Re: if (x > ((2^x)-1)) optimization

On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote: > On 6/22/19 7:55 AM, Jason Duerstock wrote: > > More generally, we can rewrite > > > > if ( x > ((1 << z) -1)) { ...} > > > > as > > > > if ( x >> z ) { ... } > > >

Re: if (x > ((2^x)-1)) optimization

On 6/22/19 7:55 AM, Jason Duerstock wrote: > I was starting at the assembly from some of the Python source, and > came across this (simplified) comparison: > > if (x > 2305843009213693951) {...} > > This is the same as: > > if (x > 0x1fff) {...} >

if (x > ((2^x)-1)) optimization

I was starting at the assembly from some of the Python source, and came across this (simplified) comparison: if (x > 2305843009213693951) {...} This is the same as: if (x > 0x1fff) {...} This is equivalent to: if (x >> 61) {...} More generally, we can rewrite if (

X

Sent from my iPhone

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

Again, please don't do this. As you can see (see Tom Tromey's email), others have a use to go between vtable types and the types they are attached to. We should be getting away from linkage names, not going further towards them. There are a bunch of gdb bugs this won't solve, but adding an extensio

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

I've experimented with adding DW_AT_linkage_name for composite types in LLVM. Here is impact on binary sizes (compiled with debuginfo): Original size with DW_AT_linkage_name for composites % increase clang-7.01926574256 1952846192 1.4% clang-tidy 12209

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

Ok, sounds reasonable. In case of debugger we are indeed "linking" RTTI name with name in debuginfo. I've checked LLVM docs, they generate Debuginfo from LLVM "Metadata", and metadata for types already contains mangled names in "identifier" field: https://llvm.org/docs/LangRef.html#dicompositetype

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

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 names to DW_AT_name, instead of d

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

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 GDB can match DW_AT_name against

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

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(name, NU

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

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

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

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

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

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

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

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

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

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

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

> "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,

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

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

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

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

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

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

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

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

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

On 2018-02-07 11:50, Jonathan Wakely wrote: On 7 February 2018 at 16:36, Simon Marchi wrote: 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 t

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

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

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

> That latter solution would have the advantage that you don't need to >>>> demangle anything anymore. From vtable you get to typeinfo, from there >>>> for typeinfo name, and that contains the mangled type name (without _Z >>>> prefix). >>>

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

On Wed, Feb 7, 2018 at 5:44 AM, Simon Marchi wrote: > On 2018-02-07 02:21, Daniel Berlin wrote: > >> As the person who, eons ago, wrote a bunch of the the GDB code for this >> C++ >> ABI support, and as someone who helped with DWARF support in both GDB and >> GCC, let me try to propose a useful p

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

On 7 February 2018 at 16:36, Simon Marchi wrote: > 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 >>

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

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 try to summ

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

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 issue quickly. It's now

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

fferent examples in the thread, which should be handled differently. From Roman 2/3/2018 #include struct base { virtual void print() = 0; }; template< auto IVAL> struct foo : base { decltype(IVAL) x = -IVAL; void print() override { std::cout << x << std::endl; }; };

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

On 4 February 2018 at 05:01, 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 id

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

On 7 February 2018 at 15:07, Manfred wrote: > > > On 02/07/2018 02:44 PM, Simon Marchi wrote: >> >> On 2018-02-07 02:21, Daniel Berlin wrote: >>> >>> As the person who, eons ago, wrote a bunch of the the GDB code for this >>> C++ >>> ABI support, and as someone who helped with DWARF support in bot

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

On 02/07/2018 02:44 PM, Simon Marchi wrote: On 2018-02-07 02:21, Daniel Berlin wrote: As the person who, eons ago, wrote a bunch of the the GDB code for this C++ ABI support, and as someone who helped with DWARF support in both GDB and GCC, let me try to propose a useful path forward (in the

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

On 2018-02-07 02:21, Daniel Berlin wrote: As the person who, eons ago, wrote a bunch of the the GDB code for this C++ ABI support, and as someone who helped with DWARF support in both GDB and GCC, let me try to propose a useful path forward (in the hopes that someone will say "that's horrible,

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

As the person who, eons ago, wrote a bunch of the the GDB code for this C++ ABI support, and as someone who helped with DWARF support in both GDB and GCC, let me try to propose a useful path forward (in the hopes that someone will say "that's horrible, do it this instead") Here are the constraint

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

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

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<

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 ... I

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

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

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 tem

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

l void print() = 0; }; template< auto IVAL> struct foo : base { decltype(IVAL) x = -IVAL; void print() override { std::cout << x << std::endl; }; }; int main() { base * fu = new foo<10u>(); base * fi = new foo<10>(); fu->print(); fi-

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

y on older compiler. Consider this case (Results with g++ 8.0.1) #include struct base { virtual void print() = 0; }; template< auto IVAL> struct foo : base { decltype(IVAL) x = -IVAL; void print() override { std::cout << x << std::endl; }; }; int main() { base * f

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

On Fri, 2018-02-02 at 23:54 -0500, Simon Marchi wrote: > Your problem is probably linked to these issues, if you want to follow > them: > > gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 > gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=22013 > > As Carl said, it's a good idea to t

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

2018-02-02 20:54 GMT-08:00 Simon Marchi : > > GCC changed how it outputs unsigned template parameters in the debug info > (from 2u to just 2), and it doesn't look like it's going to change it > back. So I suppose we'll have to find a way to make GDB deal with it. > Simon > I'm not so sure about

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

< int IVAL, unsigned UVAL, unsigned long long ULLVAL> >> struct derived : base { >> int x = IVAL + + UVAL + ULLVAL; >> }; >> >> int main() >> { >> base * o = new derived<1,2,3>{}; >> return 0; >> } >> >>

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

unsigned UVAL, unsigned long long ULLVAL> struct derived : base { int x = IVAL + + UVAL + ULLVAL; }; int main() { base * o = new derived<1,2,3>{}; return 0; } When compiled with g++5.4 I can read value of x in debugger. When compiled with g++7.2 gdb reports: warning: RTTI sym

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

struct base { virtual ~base(){} }; > > template< int IVAL, unsigned UVAL, unsigned long long ULLVAL> > struct derived : base { > int x = IVAL + + UVAL + ULLVAL; > }; > > int main() > { > base * o = new derived<1,2,3>{}; > return 0; > } > > When com

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

> struct derived : base { int x = IVAL + + UVAL + ULLVAL; }; int main() { base * o = new derived<1,2,3>{}; return 0; } When compiled with g++5.4 I can read value of x in debugger. When compiled with g++7.2 gdb reports: warning: RTTI symbol not found for class 'derived&

RE: loading of zeros into {x,y,z}mm registers

Cc: gcc@gcc.gnu.org Subject: loading of zeros into {x,y,z}mm registers Kirill, in an unrelated context I've stumbled across a change of yours from Aug 2014 (revision 213847) where you "extend" the ways of loading zeros into registers. I don't understand why this was

Re: loading of zeros into {x,y,z}mm registers

Hello Richard, On 01 Dec 12:44, Richard Biener wrote: > On Fri, Dec 1, 2017 at 6:45 AM, Kirill Yukhin wrote: > > Hello Jan, > > On 29 Nov 08:59, Jan Beulich wrote: > >> Kirill, > >> > >> in an unrelated context I've stumbled across a change of yours > >> from Aug 2014 (revision 213847) where you "

Re: loading of zeros into {x,y,z}mm registers

I did overlook this aspect indeed. I still think the smaller VEX > encoding should then be used for the low 16 registers. If you have a testcase where that is not the case, please file a PR with it. > Furthermore this > > typedef double __attribute__((vector_size(16))) v2df_t; >

Re: loading of zeros into {x,y,z}mm registers

double __attribute__((vector_size(16))) v2df_t; typedef double __attribute__((vector_size(32))) v4df_t; void test1(void) { register v2df_t x asm("xmm31") = {}; asm volatile("" :: "v" (x)); } void test2(void) { register v4df_t x asm("ymm31&

Re: loading of zeros into {x,y,z}mm registers

On Fri, Dec 1, 2017 at 6:45 AM, Kirill Yukhin wrote: > Hello Jan, > On 29 Nov 08:59, Jan Beulich wrote: >> Kirill, >> >> in an unrelated context I've stumbled across a change of yours >> from Aug 2014 (revision 213847) where you "extend" the ways >> of loading zeros into registers. I don't underst

Re: loading of zeros into {x,y,z}mm registers

Hello Jan, On 29 Nov 08:59, Jan Beulich wrote: > Kirill, > > in an unrelated context I've stumbled across a change of yours > from Aug 2014 (revision 213847) where you "extend" the ways > of loading zeros into registers. I don't understand why this was > done, and the patch submission mail also do

loading of zeros into {x,y,z}mm registers

Kirill, in an unrelated context I've stumbled across a change of yours from Aug 2014 (revision 213847) where you "extend" the ways of loading zeros into registers. I don't understand why this was done, and the patch submission mail also doesn't give any reason. My point is that simple VEX-encoded

RE: Backporting ARC patch to gcc7.x

> We've generally considered those clauses under the umbrella of the port > maintainers. Thank you for your guidance. I've backported the patch using the gcc guideline: >svn commit Sending. Sendinggcc/ChangeLog Sendinggcc/config.gcc Sendinglibgcc/ChangeLog Sending

Re: Backporting ARC patch to gcc7.x

On 11/15/2017 06:49 AM, Claudiu Zissulescu wrote: > Hi, > > I would like to backport patch r250097 to gcc7.x branch. It does changes > libgcc/config.host and gcc/config.gcc for ARC. Do I need to get extra > approvals for it or I just fallow the wiki on this page > (https:

Backporting ARC patch to gcc7.x

Hi, I would like to backport patch r250097 to gcc7.x branch. It does changes libgcc/config.host and gcc/config.gcc for ARC. Do I need to get extra approvals for it or I just fallow the wiki on this page (https://gcc.gnu.org/wiki/SvnMerge). Thanks, Claudiu

Re: [llvm-dev] DragonEgg for GCC v8.x and LLVM v6.x is just able to work

Dear Chris, Thanks for your kind response! The motivating of this work: 1. Clang can not build Linux https://bugs.llvm.org/show_bug.cgi?id=22830 and LLVMLinux patch was not be maintained? http://llvm.linuxfoundation.org/index.php/Main_Page 2. Clang analyzer Frontend can not static analysis

  1   2   3   4   5   6   >