Re: [PATCH] Fix gdb printers for std::string

2022-10-01 Thread François Dumont via Gcc-patches
I had forgotten to re-run tests after I removed the #define _GLIBCXX_USE_CXX11_ABI 0. The comment was misleading, it could also impact output of std::list. I am also restoring the correct std::string alias for std::__cxx11::basic_string, even if with my workaround it doesn't really matter as

Re: [PATCH] Process unsigned overflow relations for plus and minus in range-ops.

2022-10-01 Thread Bernhard Reutner-Fischer via Gcc-patches
On Thu, 29 Sep 2022 18:38:10 -0400 Andrew MacLeod via Gcc-patches wrote: > diff --git a/gcc/range-op.cc b/gcc/range-op.cc > index 9bb04c361d0..830c64bd6b9 100644 > --- a/gcc/range-op.cc > +++ b/gcc/range-op.cc > @@ -1305,22 +1305,123 @@ operator_plus::wi_fold (irange &r, tree type, >value_ran

[PATCH] OpenACC: Fix struct-component-kind-1.c test

2022-10-01 Thread Julian Brown
This patch is a minimal fix for the recently-added struct-component-kind-1.c test (which is currently failing to emit one of the errors it expects in scan output). This fragment was erroneously omitted from the second version of the patch posted previously: https://gcc.gnu.org/pipermail/gcc-pat

Re: [PATCH] OpenACC: Fix struct-component-kind-1.c test

2022-10-01 Thread Jakub Jelinek via Gcc-patches
On Sat, Oct 01, 2022 at 12:56:59AM -0700, Julian Brown wrote: > This patch is a minimal fix for the recently-added > struct-component-kind-1.c test (which is currently failing to emit one > of the errors it expects in scan output). This fragment was erroneously > omitted from the second version of

Re: [PATCH] Fix gdb printers for std::string

2022-10-01 Thread Jonathan Wakely via Gcc-patches
On Sat, 1 Oct 2022 at 08:20, François Dumont via Libstdc++ wrote: > > I had forgotten to re-run tests after I removed the #define > _GLIBCXX_USE_CXX11_ABI 0. > > The comment was misleading, it could also impact output of std::list. > > I am also restoring the correct std::string alias for > std::_

Re: [PATCH] Fix gdb printers for std::string

2022-10-01 Thread François Dumont via Gcc-patches
On 01/10/22 12:06, Jonathan Wakely wrote: On Sat, 1 Oct 2022 at 08:20, François Dumont via Libstdc++ wrote: I had forgotten to re-run tests after I removed the #define _GLIBCXX_USE_CXX11_ABI 0. The comment was misleading, it could also impact output of std::list. I am also restoring the corre

Re: [PATCH] testsuite: Windows paths use \ and not /

2022-10-01 Thread Torbjorn SVENSSON via Gcc-patches
Hi, I'm really sorry for the mess. I did test my patch, but I just looked for the PASS/FAIL for the excess errors and missed that there was an error with the pattern. In the end, the patch that you pushed is much better. Thanks for fixing the issue in my absence. Kind regards, Torbjörn On 20

Re: [PATCH] or1k: Only define TARGET_HAVE_TLS when HAVE_AS_TLS

2022-10-01 Thread Stafford Horne via Gcc-patches
On Thu, Sep 29, 2022 at 03:57:40PM +0100, Stafford Horne wrote: > This was found when testing buildroot with linuxthreads enabled. In > this case, the build passes --disable-tls to the toolchain during > configuration. After building the OpenRISC toolchain it was still > generating TLS code seque

Re: [PATCH] Fix gdb printers for std::string

2022-10-01 Thread Jonathan Wakely via Gcc-patches
On Sat, 1 Oct 2022 at 11:43, François Dumont wrote: > > On 01/10/22 12:06, Jonathan Wakely wrote: > > On Sat, 1 Oct 2022 at 08:20, François Dumont via Libstdc++ > > wrote: > >> I had forgotten to re-run tests after I removed the #define > >> _GLIBCXX_USE_CXX11_ABI 0. > >> > >> The comment was mis

Re: [Buildroot] [PATCH] or1k: Only define TARGET_HAVE_TLS when HAVE_AS_TLS

2022-10-01 Thread Yann E. MORIN via Gcc-patches
Stafford, All, On 2022-10-01 11:35 +, Stafford Horne spake thusly: > On Thu, Sep 29, 2022 at 03:57:40PM +0100, Stafford Horne wrote: > > This was found when testing buildroot with linuxthreads enabled. In > > this case, the build passes --disable-tls to the toolchain during > > configuration.

Adding a new thread model to GCC

2022-10-01 Thread LIU Hao via Gcc-patches
Greetings. After some years I think it's time to put on this topic again. This patch series is an attempt to add a new thread model basing on the mcfgthread library (https://github.com/lhmouse/mcfgthread), which provides efficient implementations of mutexes, condition variables, once flags, et

[PATCH] libstdc++: Use ///< for inline documentation

2022-10-01 Thread Arsen Arsenović via Gcc-patches
I accidentally that some variables were misdocumented when using trailing comment for documentation. I ran a search with a relatively simple regex[1] to look for any ///s following some code that did not have a <, and came up with these instances only. [1]: \s*([^ ]+\s*)+///[^<].*$ libstdc++-v3

Re: [committed] More gimple const/copy propagation opportunities

2022-10-01 Thread Bernhard Reutner-Fischer via Gcc-patches
On Fri, 30 Sep 2022 17:32:34 -0600 Jeff Law wrote: > + /* This looks good from a CFG standpoint. Now look at the guts > + of PRED. Basically we want to verify there are no PHI nodes > + and no real statements. */ > + if (! gimple_seq_empty_p (phi_nodes (pred))) > +return false;

Re: [RFA] Avoid unnecessary load-immediate in coremark

2022-10-01 Thread Jeff Law via Gcc-patches
On 9/29/22 01:44, Richard Biener wrote: On Tue, Sep 27, 2022 at 9:54 PM Jeff Law wrote: This is another minor improvement to coremark. I suspect this only improves code size as the load-immediate was likely issuing with the ret statement on multi-issue machines. Basically we're failing t

Re: [RFA] Avoid unnecessary load-immediate in coremark

2022-10-01 Thread Jeff Law via Gcc-patches
On 9/30/22 04:47, Richard Sandiford wrote: Jeff Law writes: This is another minor improvement to coremark.   I suspect this only improves code size as the load-immediate was likely issuing with the ret statement on multi-issue machines. Basically we're failing to utilize conditional equival

Re: Adding a new thread model to GCC

2022-10-01 Thread Bernhard Reutner-Fischer via Gcc-patches
On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches wrote: >Greetings. >The first patch is necessary because somewhere in libgfortran, `pthread_t` is >referenced. If the thread model is not `posix`, it fails to compile. One of several shortcomings mentioned already on Sun, 02 Sep 2018 15: