Tested x86_64-linux. Pushed to trunk.
--> 8--
We can't define endpoints and resolvers without the relevant OS support.
If IPPROTO_TCP and IPPROTO_UDP are both udnefined then we won't need
basic_endpoint and basic_resovler anyway, so make them depend on those
macros.
libstdc++-v3/ChangeLog:
On Fri, 9 Jun 2023 at 10:09, Jakub Jelinek wrote:
> On Fri, Jun 09, 2023 at 11:02:48AM +0200, Richard Biener via Gcc-patches
> wrote:
> > > Currently both gcc-13 and trunk are at the same library version,
> > > libstdc++.so.6.0.32
> > >
> > > But with this addition to trunk we need to bump that
Tested x86_64-linux, powerpc64le-linux, sparcv9-solaris. Pushed to
trunk.
There's no new GLIBCXX_3.4.33 symbol version yet, because we have
nothing to put in it. The bump is because of the new CXXABI_1.3.15
version.
-- >8 --
The addition of __cxa_call_terminate@@CXXABI_1.3.15 on trunk means we
Tested powerpc64le-linux. Pushed to trunk.
I'll backport it to gcc-13 later.
-- >8 --
I had intended to support the P2510R3 proposal unconditionally in C++20
mode, but I left it half implemented. The parse function supported the
new extensions, but the format function didn't.
This adds the
Tested powerpc64le-linux. Pushed to trunk.
This makes sense to backport after some soak time on trunk.
-- >8 --
As reported in PR libstdc++/110167, std::to_array compiles extremely
slowly for very large arrays. It needs to instantiate a very large
specialization of std::index_sequence and then
On Fri, 9 Jun 2023 at 10:03, Richard Biener
wrote:
> On Thu, Jun 8, 2023 at 3:14 PM Jonathan Wakely via Gcc-patches
> wrote:
> >
> > On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote:
> >
> > >
> > >
> > > On Wed, 24 May 2023 at 19:56, Jason
I'm fairly confident these emplace member functions work correctly, but
it's still nice to actually test them!
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
Our existing tests for std::deque::emplace, std::list::emplace and
std::vector::emplace are poor. We only have compile tests for PR
On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote:
>
>
> On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> Middle-end folks: any thoughts about how best to make the change
>> described in
>> the last pa
post its compiled and/or preprocessed code publicly. I assume RedHat has
> SPEC CPU2017 license, and I can post details to you privately.
>
> Kind regards,
>
> --
> Maxim Kuvyrkov
> https://www.linaro.org
>
>
>
>
> > On Jun 1, 2023, at 19:09, Jonathan Wakel
On Thu, 8 Jun 2023 at 09:58, Maxim Kuvyrkov
wrote:
> Hi Jonathan,
>
> Interestingly, this increases code-size of -O3 code on aarch64-linux-gnu
> on SPEC CPU2017's 641.leela_s benchmark [1].
>
> In particular, FastBoard::get_nearby_enemies() grew from 1444 to 2212
> bytes. This seems like a
On Wed, 7 Jun 2023 at 18:26, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023, 18:17 Jakub Jelinek via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
>
>> Hi!
>>
>> This test apparently contains 3 problematic floating point constants,
>> 1e126, 4.91e
On Wed, 7 Jun 2023, 18:17 Jakub Jelinek via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Hi!
>
> This test apparently contains 3 problematic floating point constants,
> 1e126, 4.91e-6 and 5.547e-6. These constants suffer from double rounding
> when -fexcess-precision=standard evaluates double
On Wed, 7 Jun 2023 at 16:19, Andreas Schwab wrote:
> On Jun 07 2023, Jonathan Wakely via Gcc-patches wrote:
>
> > Let's just revert it then. The manual says we should use AS_IF, but what
> we
> > had previously was working well enough. I'll figure out what happened
> her
On Wed, 7 Jun 2023 at 12:51, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023 at 10:08, Thomas Schwinge
> wrote:
>
>> Hi!
>>
>> On 2023-06-07T09:12:31+0100, Jonathan Wakely wrote:
>> > On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
>>
On Wed, 7 Jun 2023 at 09:06, Jonathan Wakely wrote:
> On Wed, 7 Jun 2023 at 05:43, François Dumont wrote:
>
>>
>> On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote:
>> > Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
>> >
>> &
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
In r14-1583-g192665feef7129 I meant to add CXXABI_1.3.15 but instead I
replaced CXXABI_1.3.14 with it. This restores the CXXABI_1.3.14 version.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_abi.cc
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/18_support/nested_exception/rethrow_if_nested-term.cc:
Require effective target exceptions_enabled instead of using
dg-skip-if.
*
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/duration/cons/2.cc: Use values that aren't
affected by rounding.
* testsuite/20_util/from_chars/5.cc: Cast arithmetic result to
double
On Wed, 7 Jun 2023 at 15:54, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023 at 15:42, Hans-Peter Nilsson wrote:
>
>> > Date: Tue, 6 Jun 2023 16:30:12 +0100
>> > From: Jonathan Wakely via Gcc-patches
>>
>> > On Thu, 1 Jun 2023 at 16:59
On Wed, 7 Jun 2023 at 15:42, Hans-Peter Nilsson wrote:
> > Date: Tue, 6 Jun 2023 16:30:12 +0100
> > From: Jonathan Wakely via Gcc-patches
>
> > On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
> > libstd...@gcc.gnu.org> wrote:
> >
> > &
On Wed, 7 Jun 2023 at 10:08, Thomas Schwinge
wrote:
> Hi!
>
> On 2023-06-07T09:12:31+0100, Jonathan Wakely wrote:
> > On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
> >> On 2023-06-06T20:31:21+0100, Jonathan Wakely
> wrote:
> >> > On Tu
On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
> Hi!
>
> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
> > wrote:
> >> This issue comes up in context of me working on C++ support for GCN and
> >
On Wed, 7 Jun 2023 at 05:43, François Dumont wrote:
>
> On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote:
> > Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > Add the recently added CXXABI_1.3.15 version. Als
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
Add the recently added CXXABI_1.3.15 version. Also remove two "frozen"
versions from the latestp list, as no more symbols should be added to
those now.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_abi.cc
Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
-- >8 --
This redefines std::numeric_limits<__float128> so that it works with
non-GCC compilers. The previous definition didn't work with Clang, due
to it not supporting __builtin_high_valq, __builtin_nanq, and
__builtin_nansq. It also
On Tue, 6 Jun 2023 at 15:14, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Last part to resolve test failure introduced with PR109822.
>
> OK for master and backports (gcc-11 doesn't have __builtin_shufflevector,
> though)?
>
Yep, OK.
>
> Tested on x86_64-pc-linux-gnu and
On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested x86_64-linux. I'd appreciate a second set of eyeballs on this
> before I push it.
>
Pushed to trunk now.
>
> -- >8 --
>
> This ensures that anything that depend
On Tue, 6 Jun 2023 at 13:34, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This is the first part of a fix for the failure of the new simd test on
> non-
> VSX POWER targets. There are more casts to unavailable vectors of 64-bit
> element types to be rewritten.
>
> OK for master
On Tue, 6 Jun 2023 at 13:26, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> OK for master and backports?
>
OK for trunk and branches
> Tested on x86_64-pc-linux-gnu
>
> - >8 -
>
> The call to the base implementation sometimes didn't find a matching
> signature because
Tested x86_64-linux. Pushed to trunk. Backport needed for gcc-13 too.
-- >8 --
For 32-bit targets using -pedantic (or using Clang) makes the expression
_M_elems[0] ambiguous. The overloaded operator[] that we want to call
has a size_t parameter, but 0 is type ptrdiff_t for many ILP32 targets,
On Fri, 2 Jun 2023 at 17:52, Jonathan Wakely wrote:
> On Fri, 2 Jun 2023 at 16:45, Joseph Faulls wrote:
>
>> It is not required that codecvt facet be
>> supported by
>>
>> the locale, nor is it added as part of the default locale. This can lead
>> to
>&g
Tested x86_64-linux. Pushed to trunk. This is worth backporting.
-- >8 --
libstdc++-v3/ChangeLog:
* src/filesystem/ops-common.h (do_copy_file) [O_CLOEXEC]: Set
close-on-exec flag on file descriptors.
---
libstdc++-v3/src/filesystem/ops-common.h | 13 +++--
1 file
On Wed, 22 Mar 2023 at 12:20, Jonathan Wakely wrote:
> On Wed, 22 Mar 2023 at 12:18, Jonathan Wakely wrote:
>
>> On Wed, 22 Mar 2023 at 12:14, Jonathan Wakely wrote:
>>
>>>
>>>
>>> On Mon, 20 Mar 2023 at 22:30, Jonathan Wakely via Libstdc++ <
>
On Wed, 22 Mar 2023 at 12:18, Jonathan Wakely wrote:
> On Wed, 22 Mar 2023 at 12:14, Jonathan Wakely wrote:
>
>>
>>
>> On Mon, 20 Mar 2023 at 22:30, Jonathan Wakely via Libstdc++ <
>> libstd...@gcc.gnu.org> wrote:
>>
>>> On 20/03/23 22:27 +
On Wed, 22 Mar 2023 at 12:14, Jonathan Wakely wrote:
>
>
> On Mon, 20 Mar 2023 at 22:30, Jonathan Wakely via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> On 20/03/23 22:27 +, Jonathan Wakely wrote:
>> >On 06/03/23 20:52 +0100, Jannik Glückert wrote
On Fri, 2 Jun 2023 at 16:45, Joseph Faulls wrote:
> It is not required that codecvt facet be
> supported by
>
> the locale, nor is it added as part of the default locale. This can lead to
>
> dangerous behaviour when static_cast.
>
Ouch, yes indeed. I don't know why I added that there. Thanks
On Fri, 2 Jun 2023 at 12:30, Jonathan Wakely wrote:
>
>
> On Fri, 2 Jun 2023 at 10:47, François Dumont wrote:
>
>> Ok, push done.
>>
>
> Thanks.
>
>
>> Even after full rebuild those tests are still UNRESOLVED on my system.
>>
> What is
On Fri, 2 Jun 2023 at 10:30, Alexandre Oliva via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
>
> ISTM that rtems is missing some of the math.h functions expected by
> libstdc++, but also that even those that are present are not visible in
> namespace ::std::, where the macros reasonably expect to
On Fri, 2 Jun 2023 at 10:47, François Dumont wrote:
> Ok, push done.
>
Thanks.
> Even after full rebuild those tests are still UNRESOLVED on my system.
>
What is the error in the log?
What is your system? How and where did you install "OMP"?
Does the libgomp directory exist in the GCC build
e add that dg-require-effective-target to those tests then
they don't need to repeat the check in the test itself:
#if __has_include()
So please just add the #include and then we can revisit the
effective-target separately.
>
> On 01/06/2023 23:57, Jonathan Wakely wrote:
>
> On Thu, 1 Jun 2023
be continued tomorrow...
>
> On 01/06/2023 14:05, Jonathan Wakely wrote:
> >
> >
> > On Thu, 1 Jun 2023 at 12:52, Rainer Orth
> > wrote:
> >
> > Jonathan Wakely via Gcc-patches writes:
> >
> > > On Wed, 31 May 2023 at 18:39,
On Sat, 29 Apr 2023 at 11:24, Arsen Arsenović via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> libstdc++-v3/ChangeLog:
>
> * libsupc++/typeinfo: Switch to bits/version.h for
> __cpp_lib_constexpr_typeinfo.
>
>
Does this change have an impact on compilation speed?
With this change
On Sat, 29 Apr 2023 at 11:25, Arsen Arsenović via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This commit replaces the ad-hoc logic in with an AutoGen
> database that (mostly) declaratively generates a version.h bit which
> combines all of the FTM logic across all headers together.
>
> This
Tested x86_64-linux. I'd appreciate a second set of eyeballs on this
before I push it.
-- >8 --
This ensures that anything that depends on AC_REQUIRE is hoisted out of
the conditional block.
The always-false test x"long_double_math_on_this_cpu" = x"yes" condition
is not altered by this commit,
Tested x86_64-linux. Pushed to trunk, will backport too.
Tom, this will require rebasing your PSTL rebase patch, but it should be
trivial.
-- >8 --
This test fails in C++20 and later due to a warning:
warning: C++20 says that these are ambiguous, even though the second is
reversed:
note:
Tested powerpc64le-linux. Pusshed to trunk.
-- >8 --
The monadic operations in std::expected always check has_value() so we
can avoid the execptional path in value() and the assertions in error()
by accessing _M_val and _M_unex directly. This means that the monadic
operations no longer require
Tested powerpc64le-linux. Pusshed to trunk.
-- >8 --
My r14-1452-gfb409a15d9babc change to add optimization hints to
std::vector causes regressions because it makes std::vector::size() and
std::vector::capacity() too big to inline. That's the opposite of what
I wanted, so revert the changes to
Pushed to trunk. The first two changes will be backported too.
-- >8 --
Traditionally libstdc++ allowed containers and strings to be
instantiated with allocator's that have the wrong value type, implicitly
rebinding the allocator to the container's value type. Since C++20 that
has been
On Thu, 1 Jun 2023 at 12:52, Rainer Orth
wrote:
> Jonathan Wakely via Gcc-patches writes:
>
> > On Wed, 31 May 2023 at 18:39, François Dumont via Libstdc++ <
> > libstd...@gcc.gnu.org> wrote:
> >
> >> libstdc++: Reduce inclusion to
> >>
On Thu, 1 Jun 2023 at 10:30, Christophe Lyon via Libstdc++
wrote:
>
> Hi,
>
>
> On Wed, 31 May 2023 at 14:25, Jonathan Wakely via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> > Tested powerpc64le-linux. Pushed to trunk.
> >
> > -- >8
In https://gcc.gnu.org/PR109954 I suggested also adding:
"N.B., using @option{-march} might be required to produce code suitable
for a specific CPU family, e.g., @option{-march=i486}."
I realise that that is true for all of -m32, -m64 and -mx32, and similar
rules apply for other targets too. But
On Thu, 1 Jun 2023 at 04:13, Jason Merrill via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested x86_64-pc-linux-gnu, OK for trunk?
>
OK, thanks.
>
> -- 8< --
>
> In the ABI's two-phase EH model, first we walk the stack looking for a
> handler, then we walk the stack running cleanups until we
On Thu, 1 Jun 2023 at 10:06, Christophe Lyon wrote:
> Hi!
>
> We have noticed the same problem on aarch64, if that's easier to reproduce.
>
I am already testing a fix.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This should make it possible to use openlibm with djgpp (and other
targets with missing C99 functions). The from openlibm
provides all the functions, but not the float_t and double_t typedefs.
By separating the autoconf checks for the functionsand
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Similar to the three commits r14-908, r14-909 and r14-910, the
_GLIBCXX_USE_C99_MATH_TR1 macro is misleading when it is also used for
, not only for headers. It is also wrong, because the
configure checks for TR1 use -std=c++98 and a target might
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This adds optimizer hints so that GCC knows that size() <= capacity() is
always true. This allows the compiler to optimize away re-allocating
paths when assigning new values to the vector without resizing it, e.g.,
vec.assign(vec.size(), new_val).
On Wed, 31 May 2023 at 16:32, Jonathan Wakely wrote:
>
>
> On Wed, 31 May 2023 at 16:29, Hans-Peter Nilsson via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> Since I don't see a quick fix at r14-1444-g3f4853a5f00fab, I
>> thought I'd better notify t
Tested x86_64-linux. Built msp430-elf and cris-elf. Pushed to trunk.
-- >8 --
My r14-1431-g7037e7b6e4ac41 change caused the _Float128 overload to be
compiled unconditionally, by moving the USE_STRTOF128_FOR_FROM_CHARS
check into the function body. That function should still only be
compiled if
Tested x86_64-linux. Built msp430-elf and cris-elf. Pushed to trunk.
-- >8 --
The -mlarge model for msp430-elf uses 20-bit pointers, which means that
sizeof(void*) == 4 and so the r14-1432-g51cf0b3949b88b change gives the
wrong answer. Check __INTPTR_WIDTH__ >= 32 instead.
On Wed, 31 May 2023 at 18:39, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> libstdc++: Reduce inclusion to
>
>
> Move the std::search definition from stl_algo.h to stl_algobase.h and use
> the later in .
>
> For consistency also move std::__parallel::search and associated
On Wed, 31 May 2023 at 16:29, Hans-Peter Nilsson via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Since I don't see a quick fix at r14-1444-g3f4853a5f00fab, I
> thought I'd better notify the author (I have written authors
> if there was more than one ;-) of suspect commits in the
> range
On Wed, 31 May 2023 at 13:23, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested powerpc64le-linux. Pushed to trunk.
>
> -- >8 --
>
> As suggested by Jakub in the PR, this just hardcodes the constants with
> a Q suffix, since the properties
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
We use the from_chars_strtod function with __strtof128 to read a
_Float128 value, but from_chars_strtod is not defined unless uselocale
is available. This can lead to compilation failures for some targets,
because we try to define the _Flaot128
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
Prior to N0966 (July 1996) the std::setfill manipulator was specified to
work with both input and output streams. In the final C++98 standard it
is only specified to work with output streams.
We have always supported it for input streams,
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
As suggested by Jakub in the PR, this just hardcodes the constants with
a Q suffix, since the properties of __float128 are not going to change.
We can only define it for non-strict modes because the suffix gives an
error otherwise, even in
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
We previously needed in for the std::lock_error
exception class, but that was moved out of in 2009 when it was
removed from the C++0x draft. We can stop including now.
Move the include for to
where it's actually used, and only include
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
The current POSIX standard says that the -a and -o operators to the
'test' utility are obsolete, and the shell operators && and || should be
used instead.
libstdc++-v3/ChangeLog:
* configure.ac: Replace use of -o operator for test.
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
The standard requires these constructors and accessors to be noexcept.
libstdc++-v3/ChangeLog:
* include/std/scoped_allocator (scoped_allocator_adaptor): Add
noexcept to all constructors except the default constructor.
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_ZONEINFO_DIR): Extend logic for avr and
msp430 to all 16-bit targets.
* configure: Regenerate.
---
libstdc++-v3/acinclude.m4 | 15 +--
libstdc++-v3/configure
On Tue, 30 May 2023, 05:35 Alexandre Oliva via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
>
> When long double is wider than double, but from_chars is implemented
> in terms of double, tests that involve the full precision of long
> double are expected to fail. Mark them as such on
On Fri, 26 May 2023 at 12:11, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> OK for master and all backports (after 11.4 is done)?
>
OK
>
> tested on powerpc64le-linux-gnu and x86_64-pc-linux-gnu
>
> --- 8<
>
> Signed-off-by: Matthias Kretz
>
>
On Fri, 26 May 2023 at 12:09, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> OK for master and all backports (after 11.4 is done)?
>
OK
>
> tested on powerpc64le-linux-gnu
>
> --- 8<
>
> This avoids a failure on PR109964.
>
> Signed-off-by: Matthias Kretz
On Fri, 26 May 2023 at 12:03, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> OK for master and all backports (after 11.4 is done)
>
OK
>
> tested on powerpc64le-linux-gnu (with 64-bit long double)
>
> --- 8<
>
> Expect that long might not fit into the long
On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Middle-end folks: any thoughts about how best to make the change described
> in
> the last paragraph below?
>
> Library folks: any thoughts on the changes to __cxa_call_terminate?
>
I see no harm in
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The Cpp17Allocator requirements say that an allocator's pointer and
const_pointer types must meet the Cpp17RandomAccessIterator
requirements. That means our PointerBase helper for defining fancy
pointer types should support the full set of
typedef. This patch provides more readability, especially for long
> type
> > names.
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/type_traits: Use using instead of typedef
>
> LGTM, thanks!
>
Agreed.
+Reviewed-by: Jonathan Wakely
Patrick, pl
On Wed, 24 May 2023 at 21:15, Jason Merrill wrote:
> On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>> On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
>>
>> > Wang Lei raised some concerns abo
On Wed, 24 May 2023 at 16:06, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> OK for master and backports? (also a long-standing bug that didn't surface
> until the new constexpr test was added)
>
OK for all
>
> tested on powerpc64le-linux-gnu
>
> - 8<
On Tue, 23 May 2023 at 22:57, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
>
> Signed-off-by: Matthias Kretz
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/109261
> * include/experimental/bits/simd_neon.h (_S_reduce): Add
> constexpr and make NEON
On Wed, 24 May 2023 at 11:59, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> OK for master and all branches? (this issue only surfaced because of the
> new
> test)
>
OK.
>
> 8< -
>
> On ARM NEON doesn't support double, so __is_intrinsic_type_v
On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
> Wang Lei raised some concerns about Itanium C++ ABI, so let's ask a C++
> expert here...
>
> Jonathan: AFAIK the standard and the Itanium ABI treats an empty class
> as size 1
Only as a complete object, not as a subobject.
> in order to
On Wed, 24 May 2023 at 06:52, Alexandre Oliva via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
>
> Just as on aarch64, x86's wider long double experiences loss of
> precision with from_chars implemented in terms of double. Expect the
> execution fail.
>
> Bootstrapped on x86_64-linux-gnu. Also
On Mon, 22 May 2023 at 21:51, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> I was thinking that it might be nice to get rid of predefined_ops.h
> content.
>
> So here is a start with __negate. Drawback is that stl_algo.h has to
> include .
We definitely don't want that.
On Mon, 22 May 2023 at 21:27, Matthias Kretz wrote:
> On Monday, 22 May 2023 18:25:15 CEST Jonathan Wakely wrote:
> > I note that using if (not __builtin_constant_evaluated()) will fail if
> > compiled with -fno-operator-names, which is why we don't use 'not',
> 'and',
On Mon, 22 May 2023 at 16:36, Matthias Kretz via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> OK for trunk and backporting?
>
> regtested on x86_64-linux and aarch64-linux
>
> The constexpr API is only available with -std=gnu++XX (and proposed for
> C++26). The proposal is to have the complete
On Thu, 18 May 2023 at 15:47, Bernhard Reutner-Fischer <
rep.dot@gmail.com> wrote:
> On 18 May 2023 14:56:45 CEST, Jonathan Wakely via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> >From: Michael B��uerle
> >
> >POSIX sh does not support the == f
On Thu, 18 May 2023 at 13:59, Jakub Jelinek wrote:
> On Thu, May 18, 2023 at 01:56:46PM +0100, Jonathan Wakely via Gcc-patches
> wrote:
> > --- a/gcc/testsuite/gcc.test-framework/gen_directive_tests
> > +++ b/gcc/testsuite/gcc.test-framework/gen_directive_tests
> >
Fixes a fat finger error in the v1 patch, spotted by Jakub.
-- >8 --
POSIX sh does not support the == for string comparisons, use = instead.
The gen_directive_tests script uses a bash shebang so == does work, but
there's no reason this script can't just use the more portable form
anyway.
POSIX sh does not support the == for string comparisons, use = instead.
These contrib scripts all use a bash shebang so == does work, but
there's no reason they can't just use the more portable form anyway.
PR bootstrap/105831
contrib/ChangeLog:
* bench-stringop: Use = operator
POSIX sh does not support the == for string comparisons, use = instead.
The gen_directive_tests script uses a bash shebang so == does work, but
there's no reason this script can't just use the more portable form
anyway.
PR bootstrap/105831
gcc/ChangeLog:
* config.gcc: Use =
From: Michael Bäuerle
POSIX sh does not support the == for string comparisons, use = instead.
gcc/ChangeLog:
PR bootstrap/105831
* config/nvptx/gen-opt.sh: Use = operator instead of ==.
* configure.ac: Likewise.
* configure: Regenerate.
---
Tested powerpc64le-linux.
I plan to push these as obvious, unless I hear objections.
Jonathan Wakely (2):
gcc: Fix nonportable shell syntax in "test" and "[" commands
[PR105831]
contrib: Fix nonportable shell syntax in "test" and "[" commands
and push to trunk, thanks!
+Reviewed-by: Jonathan Wakely
On Wed, 17 May 2023 at 19:18, Jakub Jelinek wrote:
> Hi!
>
> As can be seen on the following testcase, for
>
> std::{atan2,fmod,pow,copysign,fdim,fmax,fmin,hypot,nextafter,remainder,remquo,fma}
> if one operand type is std::float{16,32,64,128}_t or std::bfloat16_t and
> another one some integral
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
I don't know why these checks are disabled.
libstdc++-v3/ChangeLog:
* testsuite/18_support/headers/limits/synopsis.cc: Uncomment
checks for float_round_style and float_denorm_style.
---
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
Without this change many tests that depend on an effective-target will
fail when compiled with -pedantic -std=c++98. This happens because the
preprocessor check done by v3_check_preprocessor_condition uses -Werror
and includes directly (rather
Tested powerpc64le-linux. Pushed to trunk.
I'll probably backport this to gcc-13 too.
There are no tests for the changes to and_then and transform, because
LWG 3843 makes that hard to test. Both and_then and transform call
value(), which requires a copy constructible error_type. So we can test
On Wed, 17 May 2023 at 10:38, Nathaniel Shead
wrote:
> On Wed, May 17, 2023 at 10:05:59AM +0100, Jonathan Wakely wrote:
> > On Wed, 17 May 2023 at 09:37, Nathaniel Shead wrote:
> >
> > > Now that GCC13.1 is released is it ok to merge? Thanks!
> > >
> >
On Wed, 17 May 2023 at 10:32, Martin Jambor wrote:
> Hello,
>
> On Tue, May 16 2023, Jonathan Wakely via Gcc-patches wrote:
> > Tested powerpc64le-linux. Builds OK on djgpp too.
> >
> > Pushed to trunk.
> >
> > -- >8 --
> >
> > DJGPP (and
get). So I think we need a new
autoconf check for the existence of those functions. I'm in the process of
reworking the autoconf macros for (due to PR 109818), which is why
I didn't address it for this patch yet.
>
> On Tue, Apr 18, 2023 at 6:48 PM Jonathan Wakely
> wrote:
> >
&
901 - 1000 of 9534 matches
Mail list logo
