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