On Wed, 30 Nov 2022 at 18:00, François Dumont wrote:
>
> On 30/11/22 14:07, Jonathan Wakely wrote:
> > On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote:
> >>
> >>
> >> On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote:
> >>>
> >>>
> >>> On Wed, 30 Nov 2022 at 06:04, François Dumont via Libs
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This test was recently modified to check that the library doesn't use
__unused anywhere, because that's a macro in newlib. But it's also a
macro in old versions of glibc, so the test now fails for those targets.
Disable that check for those targets a
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/107871
* include/std/format (_Iter_sink::_M_overflow): Add cast to
size_t.
(_Iter_sink::_M_make_span): Use
typedef instead of decltype.
* testsuite/std/format/funct
I've pushed this to trunk. Tested x86_64-linux.
On Mon, 21 Nov 2022 at 20:44, Jonathan Wakely via Libstdc++
wrote:
>
> While finishing the time zone support for C++20, I noticed that the
> chrono::hh_mm_ss type is surprisingly large: 40 bytes. That's because
> we use duration for each of the four
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The PR shows a bogus warning where jump threading generates code for the
undefined case that the insertion point is a value-initialized iterator
but _M_finish and _M_end_of_storage are unequal (so at least one must be
non-null). Using __builtin_unrea
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/std_mutex.h (mutex): Add nodiscard attribute to
try_lock member function.
* include/bits/unique_lock.h (unique_lock): Likewise for
try_lock, try_lock_until, try_lock_for member f
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Fix digit grouping for integers formatted with "{:#Lx}" which were
including the "0x" prefix in the grouped digits. This resulted in output
like "0,xff,fff" instead of "0xff,fff".
Also change std:::basic_format_parse_context to not throw for an arg-
On Sun, 4 Dec 2022, 11:08 Iain Sandoe via Libstdc++,
wrote:
> While looking at Darwin's os_defines, I wondered whether
> _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC was really still necessary. On
> checking
> the OS, it seems that it was a transient problem that only appears in
> Darwin11.
> Earlier v
On Sun, 4 Dec 2022, 10:54 Iain Sandoe via Libstdc++,
wrote:
> As pointed out on irc by Jonathan, the Darwin os_defines contains a "weak"
> attribute where we should use '__weak__'. Fixed thus, tested on i686,
> x86_64
> Darwin and x86_64 Linux, pushed to master, thanks,
> Iain
> -- >8 --
>
I
On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote:
>
>
>
> On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote:
>>
>>
>>
>> On Wed, 30 Nov 2022 at 06:04, François Dumont via Libstdc++
>> wrote:
>>>
>>> Good catch, then we also need this patch.
>>
>>
>> Is it worth printing an error? If we can
Resending with the typo in the mailing list address fixed...
On Wed, 30 Nov 2022 at 12:31, Jonathan Wakely wrote:
>
> On Tue, 29 Nov 2022 at 21:41, Björn Schäpers wrote:
> >
> > From: Björn Schäpers
> >
> > Not providing an error handler results in a nullpointer dereference when
> > an error occ
Tested x86_64-linux. Pushed to trunk.
-- >8 --
GCC assumes that any global variable might be modified by operator new,
and so in the testcase for this PR all data members get reloaded after
allocating new storage. By making local copies of the _M_start and
_M_finish members we avoid that, and the
Tested x86_64-linux. Pushed to trunk.
-- >8 --
There's no need to call a _M_xxx_dispatch function with a
statically-known __false_type tag, we can just directly call the
function that should be dispatched to. This will compile a tiny bit
faster and save a function call with optimization or inlini
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These names (and __unused) are defined as macros by newlib.
libstdc++-v3/ChangeLog:
* include/std/format: Rename all variables called __used or
__packed.
* testsuite/17_intro/badnames.cc: Add no_pch options.
* testsu
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This patch is fixing those tests:
>
> 20_util/to_chars/float128_c++23.cc
> std/format/formatter/requirements.cc
> std/format/functions/format.cc
> std/format/functions/format_to_n.cc
> std/format/function
Tested x86_64-linux, built on msp430-elf and h8300-elf. Pushed to trunk.
-- >8 --
For H8/300 with -msx -mn -mint32 the type of (_M_len - __pos) is int,
because int is wider than size_t so the operands are promoted.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view::co
Tested x86_64-linux, built on msp430-elf and h8300-elf. Pushed to trunk.
-- >8 --
This fixes compilation failures for H8 multilibs. For the normal
multilib (ILP16L32?), the chunk struct does not have the expected size,
because uint32_t is type long and has alignment 4 (by default). This
forces si
Tested x86_64-linux, built on msp430-elf and h8300-elf. Pushed to trunk.
-- >8 --
For H8/300 size_t is 32 bits wide, but (unsigned char)buf[2] << 16
promotes to int which is only 16 bits wide. The shift is then undefined.
This fixes it by converting to size_t before shifting.
libstdc++-v3/Change
On Mon, 28 Nov 2022 at 15:20, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested x86_64-linux. Pushed to trunk.
>
I didn't notice until my mailer flagged it that this commit has a non-ASCII
character. Fixed by the attached patch, pushed to trunk.
commit c775e2b81fca39f366040d4
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This means we don't need to use "(__8::)?" in dg-prune-output
directives.
libstdc++-v3/ChangeLog:
* testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc:
Simplify dg-prune-output pattern.
* testsuite/lib/prune.exp (
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This implements the proposed resolution of LWG 3809, so that
std::subtract_with_carry_engine can be used with a 16-bit result_type.
Currently this produces a narrowing error when instantiating the
std::linear_congruential_engine to create the initial
On Mon, 28 Nov 2022 at 10:08, Jonathan Wakely wrote:
>
>
> On Mon, 28 Nov 2022 at 10:06, Jonathan Wakely wrote:
>
>>
>>
>> On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++ <
>> libstd...@gcc.gnu.org> wrote:
>>
>>> libstdc++: [_GLIBCXX_INLINE_VERSION] Adapt dg error messages
>>>
>>> li
On Mon, 28 Nov 2022 at 10:10, Jonathan Wakely wrote:
>
>
> On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> This patch is fixing those tests:
>>
>> 20_util/to_chars/float128_c++23.cc
>> std/format/formatter/requirements.cc
>> std/format/functions/
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This patch is fixing those tests:
>
> 20_util/to_chars/float128_c++23.cc
> std/format/formatter/requirements.cc
> std/format/functions/format.cc
> std/format/functions/format_to_n.cc
> std/format/function
On Mon, 28 Nov 2022 at 10:06, Jonathan Wakely wrote:
>
>
> On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> libstdc++: [_GLIBCXX_INLINE_VERSION] Adapt dg error messages
>>
>> libstdc++-v3/ChangeLog
>>
>> * testsuite/20_util/bind/ref_neg.c
On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> libstdc++: [_GLIBCXX_INLINE_VERSION] Adapt dg error messages
>
> libstdc++-v3/ChangeLog
>
> * testsuite/20_util/bind/ref_neg.cc: Adapt dg-prune-output
> message.
> * testsuite/20_util/fu
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This moves two AC_MSG_RESULT lines for features so that they
are only printed when the corresponding AC_MSG_CHECKING actually
happened. This fixes configure output like:
checking for uchar.h... no
no
checking for int64_t... yes
Also move the AC_MS
Tested x86_64-linux. Pushed to trunk. Backport to gcc-12 needed too.
-- >8 --
As specified in the standard, the predicate for std::erase_if has to be
invocable as non-const with a non-const lvalues argument. Restore
support for predicates that only accept non-const arguments.
It's not strictly n
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These overloads are not needed in C++20 as they can be synthesized by
the compiler. Removing them means less code to compile when including
these headers.
libstdc++-v3/ChangeLog:
* include/bits/random.h [three_way_comparison] (operator!=):
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator_base_funcs.h (__distance):
Add always_inline attribute to overload for random
access iterators.
(advance, distance, next, prev): Add always_inline attribute to
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/html/manual/bugs.html: Regenerate.
* doc/xml/manual/intro.xml: Document LWG 3656 change.
* include/std/bit (__bit_width, bit_width): Return int.
* testsuite/26_numerics/bit/bit.pow.two/lw
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This copies the better tests from gcc-12 to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/106201
* testsuite/27_io/filesystem/iterators/106201.cc: Improve test.
* testsuite/experimental/filesystem/iterators/106201.cc: New test
On Thu, 24 Nov 2022 at 09:20, Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, Solaris apparently can handle right
> printf ("%.0Lf\n", 1e+202L * __DBL_MAX__);
> which prints 511 chars long number, but can't handle
> printf ("%.0Lf\n", 1e+203L * __DBL_MAX__);
> nor
> printf ("%.0Lf\n", __LD
On Thu, 24 Nov 2022 at 09:23, Jakub Jelinek wrote:
>
> Hi!
>
> Upstream fast_float came up with a cheaper test for
> fegetround () == FE_TONEAREST using one float addition, one subtraction
> and one comparison. If we know we are rounding to nearest, we can use
> fast path in more cases as before.
Tested x86_64-linux and sparc-sun-solaris2.11. Pushed to trunk.
I'll backport to the branches too.
-- >8 --
Copy the fix for PR 104731 to the equivalent experimental::filesystem
test.
libstdc++-v3/ChangeLog:
PR libstdc++/107814
* testsuite/experimental/filesystem/iterators/error
The existence of this option makes users think they need it (even though
it's in neither -Wall nor -Wextra). Document that there's a better
option (since 2011).
OK for trunk?
-- >8 --
The newer -Wdelete-non-virtual-dtor has no false positives and fewer
bugs. There is very little reason to use -W
On Wed, 23 Nov 2022 at 08:55, Jakub Jelinek wrote:
>
> Hi!
>
> fast_float library relies on size_t being 32-bit or larger and float/double
> being IEEE single/double. Otherwise we only use strtod/strtof.
> In 3 spots I've used fast_float namespace stuff unconditionally in one
> function, which bre
Tested x86_64-linux. Pushed to gcc-12 branch.
-- >8 --
This works around a compiler bug where overload resolution attempts
implicit conversion to path in order to call a function with a path&
parameter. Such conversion would produce a prvalue, which would not be
able to bind to the lvalue referen
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These functions aren't usable in constant expressions. Provide our own
implementations, based on __from_chars_alnum_to_val from .
libstdc++-v3/ChangeLog:
PR libstdc++/107817
* include/std/charconv (__from_chars_alnum_to_val): Add
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/106201
* testsuite/27_io/filesystem/iterators/106201.cc: New test.
---
.../testsuite/27_io/filesystem/iterators/106201.cc | 12
1 file changed, 12 insertions(+)
create mode 100644
Tested x86_64-linux, Pushed to trunk. Backports will follow.
-- >8 --
The array of pool sizes was previously adjusted to work for msp430-elf
which has 16-bit int and either 16-bit size_t or 20-bit size_t. The
largest pool sizes were disabled unless size_t has more than 20 bits.
The H8 family has
While finishing the time zone support for C++20, I noticed that the
chrono::hh_mm_ss type is surprisingly large: 40 bytes. That's because
we use duration for each of the four members, _M_h, _M_m,
_M_s and _M_ss. This is very wasteful. The patch below reduces it to 16
bytes (or less for some targets
Tested x86_64-linux. Pushed to trunk.
-- >8--
This ensures that we fail a static assertion before giving any other
errors. Instantiating chrono::duration will now
print this before the other errors caused by it:
error: static assertion failed: period must be a specialization of ratio
libstdc++-
Tested x86_64-linux. Pushed to trunk.
-- >8--
When there are no bound arguments to a std::bind_front call we don't
need the overhead of compiling, initializing, and accessing an empty
tuple.
libstdc++-v3/ChangeLog:
* include/std/functional (_Bind_front0): New class template.
(_B
Tested x86_64-linux. Pushed to trunk.
-- >8--
libstdc++-v3/ChangeLog:
* include/std/tuple: Add better Doxygen comments.
---
libstdc++-v3/include/std/tuple | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/libstdc++-v3/include/std/tuple b/l
On Sun, 20 Nov 2022, 20:45 François Dumont, wrote:
> On 19/11/22 14:11, Jonathan Wakely wrote:
> > On Sat, 19 Nov 2022 at 13:03, François Dumont via Libstdc++
> > wrote:
> >> Without this qualification I have this in _GLIBCXX_INLINE_VERSION mode:
> >>
> >>
> /home/fdt/dev/gcc/build_versioned_ns/
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This makes all the [iterator.range] functions always-inline, except the
ones that construct a std::reverse_iterator, as they do a little more
work. They could probably be made always_inline too though, and maybe
the std::reverse_iterator constructor
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/format: Fix -Wsign-compare warnings.
---
libstdc++-v3/include/std/format | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/includ
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes a Doxygen warning about a mismatched parameter name. The
standard uses 'r' here, like the Doxygen comment, so use '__r' instead
of '__e'.
libstdc++-v3/ChangeLog:
* include/bits/ptr_traits.h (pointer_traits::pointer_to): Rename
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/107649
* include/std/complex (__complex_proj): Fix requires-clause.
---
libstdc++-v3/include/std/complex | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/s
On Sat, 19 Nov 2022 at 13:03, François Dumont via Libstdc++
wrote:
>
> Without this qualification I have this in _GLIBCXX_INLINE_VERSION mode:
>
> /home/fdt/dev/gcc/build_versioned_ns/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2649:
> note: candidate: 'template bool std::__9::is
On Sat, 19 Nov 2022 at 02:40, Jason Merrill wrote:
>
> Thanks, this is what I'm pushing:
>
Great.
I wonder if we should move the contents of libstdc++fs.a and
libstdc++_libbacktrace.a into libstdc++exp.a and make the former libraries
into linker scripts that point to libstdc++exp.a
It would be
On Tue, 15 Nov 2022 at 19:01, Jonathan Wakely wrote:
>
> On Tue, 15 Nov 2022 at 18:50, David Malcolm wrote:
> >
> > [Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
> >
> > On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> > > On Mon, 7 Nov 2022 at 13:51, Jonathan
On 03/11/22 15:57 -0400, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. OK for trunk?
-- >8 --
This patch adds the library support for the experimental C++ Contracts
implementation. This now consists only of a default definition of the
violation handler, which users can override through def
On Thu, 17 Nov 2022 at 09:57, Daniel Krügler
wrote:
> Am Do., 17. Nov. 2022 um 10:48 Uhr schrieb Jonathan Wakely <
> jwak...@redhat.com>:
> >
> >
> >
> > On Thu, 17 Nov 2022 at 09:47, Jonathan Wakely
> wrote:
> >>
> >>
> >>
> >> On Thu, 17 Nov 2022 at 09:25, Daniel Krügler
> wrote:
> >>>
> >>>
On Thu, 17 Nov 2022 at 09:47, Jonathan Wakely wrote:
>
>
> On Thu, 17 Nov 2022 at 09:25, Daniel Krügler
> wrote:
>
>> Am Do., 17. Nov. 2022 um 10:07 Uhr schrieb Jonathan Wakely
>> :
>> >
>> >
>> >
>> > On Thu, 17 Nov 2022, 06:30 Daniel Krügler via Libstdc++, <
>> libstd...@gcc.gnu.org> wrote:
>>
On Thu, 17 Nov 2022 at 09:25, Daniel Krügler
wrote:
> Am Do., 17. Nov. 2022 um 10:07 Uhr schrieb Jonathan Wakely
> :
> >
> >
> >
> > On Thu, 17 Nov 2022, 06:30 Daniel Krügler via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
> >>
> >> Am Mi., 16. Nov. 2022 um 22:00 Uhr schrieb Jonathan Wakely via
On Thu, 17 Nov 2022, 06:30 Daniel Krügler via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Am Mi., 16. Nov. 2022 um 22:00 Uhr schrieb Jonathan Wakely via
> Libstdc++ :
> >
> > Tested x86_64-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > We can use an array instead of a std::vector, and we can av
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
For powerpc64le we need to be able to format both of __ieee128 and
__ibm128, so we need the std::to_chars overloads for both types to be
visible at once. The __ieee128 overloads are always visible in C++23
mode, because they're used to implement
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is only a partial fix for the PR.
libstdc++-v3/ChangeLog:
PR libstdc++/107720
* include/std/format (__format::_Arg_t): Fix typo in enumerator
name.
(_Arg_value::_S_get): Fix missing semi-colons.
---
libstdc++-v
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We can use an array instead of a std::vector, and we can avoid the
binary search for the common case of a time point after the most recent
leap second. On one system where I tested this, utc_clock::now() now
takes about 16ns instead of 31ns.
libstdc
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Clang doesn't define __builtin_toupper, so use std::toupper.
Also add some (not actually required since C++20) typename keywords to
help Clang versions up to and including 15.
libstdc++-v3/ChangeLog:
PR libstdc++/107712
* include/s
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This restricts std::format support for _Float128 (and __float128) to
targets where glibc provides __strfromf128 and so can give correct
output.
libstdc++-v3/ChangeLog:
* include/std/format [__FLT128_DIG__] (_GLIBCXX_FORMAT_F128):
On
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This test of leap second handling is taken from the C++20 standard.
libstdc++-v3/ChangeLog:
* testsuite/std/time/clock/utc/1.cc: Check handling across leap
second insertion.
---
.../testsuite/std/time/clock/utc/1.cc | 24 ++
On Wed, 16 Nov 2022 at 13:47, Jakub Jelinek wrote:
> On Wed, Nov 16, 2022 at 01:45:19PM +, Jonathan Wakely wrote:
> > > On Mon, 14 Nov 2022 at 13:57, Jakub Jelinek wrote:
> > >
> > >> Hi!
> > >>
> > >> As filed by Jonathan in the PR, I've screwed up the requires syntax
> > >> in the extended
On Wed, 16 Nov 2022 at 13:42, Jonathan Wakely wrote:
>
>
> On Mon, 14 Nov 2022 at 13:57, Jakub Jelinek wrote:
>
>> Hi!
>>
>> As filed by Jonathan in the PR, I've screwed up the requires syntax
>> in the extended floating point specialization:
>> -requires(__complex_type<_Tp>::type)
>> +r
On Mon, 14 Nov 2022 at 13:57, Jakub Jelinek wrote:
> Hi!
>
> As filed by Jonathan in the PR, I've screwed up the requires syntax
> in the extended floating point specialization:
> -requires(__complex_type<_Tp>::type)
> +requires requires { typename __complex_type<_Tp>::type; }
> and doing
Tested x86_64-linux, with GDB 12.1. Pushed to trunk.
-- >8 --
The recent changes to FilteringTypePrinter affect the result of
gdb.lookup_type('std::string') in StdExpAnyPrinter, causing it to always
return the std::__cxx11::basic_string specialization. This then causes a
gdb.error exception when
Tested x86_64-linux with GDB 12.1. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (is_specialization_of): Fix
incorrect terminology in docstring and describe arguments.
(FilteringTypePrinter): Add default argument for new parameter,
On Wed, 16 Nov 2022 at 10:55, Jonathan Wakely wrote:
>
> On Wed, 16 Nov 2022 at 02:46, Patrick Palka via Libstdc++
> wrote:
> >
> > When linking with a static library, the linker seems to exclude a
> > constituent .o object (including its global initializers) if nothing
> > from it is referenced
On Wed, 16 Nov 2022 at 11:54, Jonathan Wakely wrote:
>
> On Wed, 16 Nov 2022 at 11:35, Jonathan Wakely wrote:
> >
> > On Wed, 16 Nov 2022 at 06:04, François Dumont wrote:
> > >
> > > On 15/11/22 17:17, Jonathan Wakely wrote:
> > > > On 06/10/22 19:38 +0200, François Dumont wrote:
> > > >> Hi
> >
On Wed, 16 Nov 2022 at 11:35, Jonathan Wakely wrote:
>
> On Wed, 16 Nov 2022 at 06:04, François Dumont wrote:
> >
> > On 15/11/22 17:17, Jonathan Wakely wrote:
> > > On 06/10/22 19:38 +0200, François Dumont wrote:
> > >> Hi
> > >>
> > >> Looks like the previous patch was not enough. When using it
On Wed, 16 Nov 2022 at 06:04, François Dumont wrote:
>
> On 15/11/22 17:17, Jonathan Wakely wrote:
> > On 06/10/22 19:38 +0200, François Dumont wrote:
> >> Hi
> >>
> >> Looks like the previous patch was not enough. When using it in the
> >> context of a build without dual abi and versioned namespa
On Wed, 16 Nov 2022 at 02:46, Patrick Palka via Libstdc++
wrote:
>
> When linking with a static library, the linker seems to exclude a
> constituent .o object (including its global initializers) if nothing
> from it is referenced by the program (unless e.g. --whole-archive is
> used). This behavi
On Wed, 16 Nov 2022 at 07:51, Alexander Monakov wrote:
>
>
> On Wed, 16 Nov 2022, Hongyu Wang wrote:
>
> > > When emitting a compare-and-swap loop for @ref{__sync Builtins}
> > > and @ref{__atomic Builtins} lacking a native instruction, optimize
> > > for the highly contended case by issuing an at
On Tue, 15 Nov 2022 at 23:50, Jakub Jelinek wrote:
>
> On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
> > > Here is an updated patch that passed bootstrap/regtest, the only
> > > change is another testcase tweak.
> > >
> > > 2022-11-13 Jakub Jelinek
> > >
> > > gcc/c-family/
> >
On Tue, 15 Nov 2022 at 23:36, Jason Merrill wrote:
>
> On 11/13/22 01:45, Jakub Jelinek wrote:
> > On Fri, Nov 11, 2022 at 06:07:04PM +0100, Jakub Jelinek wrote:
> >> The following patch on top of Marek's P2448 PR106649 patch
> >> (mainly because that patch implements the previous __cpp_constexpr
On Tue, 15 Nov 2022 at 18:50, David Malcolm wrote:
>
> [Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
>
> On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> > On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote:
> > >
> > > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote
On 06/10/22 19:38 +0200, François Dumont wrote:
Hi
Looks like the previous patch was not enough. When using it in the
context of a build without dual abi and versioned namespace I started
having failures again. I guess I hadn't rebuild everything properly.
This time I think the problem was in t
On Thu, 20 Oct 2022 at 16:53, Arsen Arsenović via Libstdc++
wrote:
>
> This enables us to provide symbols for placeholders and numeric limits,
I'm not convinced this is worth doing.
The placeholders and the numeric_limits members are all inline
variables for C++17 and later, and C++17 is the co
On Tue, 15 Nov 2022 at 14:42, Jakub Jelinek wrote:
>
> On Tue, Nov 15, 2022 at 02:31:19PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
> >
> > -- >8 --
> >
> > std::format gives linker er
Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
-- >8 --
Adjust a test to avoid using std::make_unsigned_t<__int128>. That's
ill-formed in strict modes because std::is_integral_v<__int128> is
false.
libstdc++-v3/ChangeLog:
* testsuite/std/format/functions/format.cc: Do not
Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
-- >8 --
This concept was added by a C++23 proposal, so don't define it for
C++20.
Split the format/formatter/formatter.cc test into two parts, one that
tests the C++20 requirements and one that tests the C++23 concept.
libstdc++-v3/C
Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
-- >8 --
std::format gives linker errors on targets that define __float128 but
do not support using it with std::to_chars. This improves the handling
of 128-bit flaoting-point types so they are disabled if unsupportable.
libstdc++-v3/C
On Tue, 15 Nov 2022 at 13:34, Alexander Monakov wrote:
>
> On Tue, 15 Nov 2022, Jonathan Wakely via Gcc-patches wrote:
>
> > > @item -mrelax-cmpxchg-loop
> > > @opindex mrelax-cmpxchg-loop
> > >-Relax cmpxchg loop by emitting an early load and compare before
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/documentation_hacking.xml: Document use of
Markdown for Doxygen comments. Tweak formatting.
* doc/html/manual/documentation_hacking.html: Regenerate.
---
.../html/manual/documentation_hacking.html| 21
On 15/11/22 11:35 +0800, Hongyu Wang wrote:
Hi,
According to PR 107676, the document of -mrelax-cmpxchg-loop is nonsensical.
Adjust the wording according to the comments.
Bootstrapped on x86_64-pc-linux-gnu, ok for trunk?
gcc/ChangeLog:
PR target/107676
* doc/invoke.texi: Rewo
On Mon, 14 Nov 2022 at 15:58, Arsen Arsenović wrote:
>
>
> Jonathan Wakely writes:
> >> It's the first thing the recipe does:
> >>
> >> install-data-local: gdb.py
> >> @$(mkdir_p) $(DESTDIR)$(toolexeclibdir)
> >>
> >> That's why I'm suggesting to do the same thing for the debug dir.
> >
> > Th
On Mon, 14 Nov 2022 at 15:11, Patrick Palka wrote:
>
> On Mon, 14 Nov 2022, Jonathan Wakely wrote:
>
> > On Mon, 14 Nov 2022 at 10:17, Daniel Krügler
> > wrote:
> > >
> > > Am Mo., 14. Nov. 2022 um 11:09 Uhr schrieb Jonathan Wakely via
> > > Libstdc++ :
> > > >
> > > > On Mon, 14 Nov 2022 at 04:
On Mon, 14 Nov 2022 at 04:51, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_algo.h (__find_last_fn, find_last):
> Define.
> (__find_last_if_fn, find_last_if): Define.
On Mon, 14 Nov 2022 at 15:07, Patrick Palka wrote:
>
> On Mon, 14 Nov 2022, Jonathan Wakely wrote:
>
> > On Mon, 14 Nov 2022 at 04:51, Patrick Palka via Libstdc++
> > wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > >
On Mon, 14 Nov 2022 at 14:13, Jonathan Wakely wrote:
>
> On Mon, 14 Nov 2022 at 13:20, Arsen Arsenović wrote:
> >
> > Hi,
> >
> > Jonathan Wakely writes:
> > >> This looks simple, and more consistent with what we already do. Does
> > >> it solve your issue?
> >
> > It does work; though, if I was
On Mon, 14 Nov 2022 at 13:20, Arsen Arsenović wrote:
>
> Hi,
>
> Jonathan Wakely writes:
> >> This looks simple, and more consistent with what we already do. Does
> >> it solve your issue?
>
> It does work; though, if I was more daring I'd have said that it's fine
> without checking, too, since i
On Mon, 14 Nov 2022 at 10:29, Jonathan Wakely wrote:
>
> On Sun, 13 Nov 2022 at 18:06, Arsen Arsenović via Libstdc++
> wrote:
> >
> > I'm unsure why this issue only started manifesting now with how old this
> > code is, but this should fix it.
> >
> > libstdc++-v3/ChangeLog:
> >
> > * pyth
On Sun, 13 Nov 2022 at 18:06, Arsen Arsenović via Libstdc++
wrote:
>
> I'm unsure why this issue only started manifesting now with how old this
> code is, but this should fix it.
>
> libstdc++-v3/ChangeLog:
>
> * python/Makefile.am: Call mkinstalldirs before INSTALL_DATA
> when ins
On Mon, 14 Nov 2022 at 10:17, Daniel Krügler wrote:
>
> Am Mo., 14. Nov. 2022 um 11:09 Uhr schrieb Jonathan Wakely via
> Libstdc++ :
> >
> > On Mon, 14 Nov 2022 at 04:52, Patrick Palka via Libstdc++
> > wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > lib
On Sun, 13 Nov 2022 at 20:30, Bernhard Reutner-Fischer via Libstdc++
wrote:
>
> On Sun, 13 Nov 2022 19:42:52 +0000
> Jonathan Wakely via Gcc-patches wrote:
>
> > On Sun, 13 Nov 2022, 18:06 Arsen Arsenović via Libstdc++, <
> > libstd...@gcc.gnu.org> wrote:
> >
On Mon, 14 Nov 2022 at 04:52, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_algo.h (out_value_result): Define.
> (iota_result): Define.
> (__iota_fn, iota): Define.
>
On Mon, 14 Nov 2022 at 08:40, Martin Liška wrote:
>
> On 11/14/22 03:49, Martin Liška wrote:
> > I'm going to revert the patchset during today (Monday) and I'll send a
> > patch with a couple
> > of new changes that landed in the period of time we used Sphinx.
>
> The revert is done and I included
On Mon, 14 Nov 2022 at 04:51, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_algo.h (__contains_fn, contains): Define.
> (__contains_subrange_fn, contains_subrange): Define.
>
801 - 900 of 1920 matches
Mail list logo
