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
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
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
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
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::_
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
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
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
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
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.
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
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
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;
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
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
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:
16 matches
Mail list logo