Teted x86_64-linux. Pushed to trunk.
-- >8 --
This makes the deduction guides for std::function and std::packaged_task
work for explicit object member functions, i.e. "deducing this", as per
LWG 3617.
libstdc++-v3/ChangeLog:
PR libstdc++/113335
* include/bits/std_function.h
Teted x86_64-linux. Pushed to trunk.
-- >8 --
This makes the deduction guides for std::function and std::packaged_task
work for explicit object member functions, i.e. "deducing this", as per
LWG 3617.
libstdc++-v3/ChangeLog:
PR libstdc++/113335
* include/bits/std_function.h
Tested x86_64-linux and powerpc-ibm-aix7.3.1.0. Pushed to trunk.
-- >8 --
This fails due to "u" being used in a system header.
FAIL: experimental/names.cc -std=gnu++17 (test for excess errors)
Excess errors:
/usr/include/sys/poll.h:77: error: expected unqualified-id before ';' token
Tested x86_64-linux and powerpc-ibm-aix7.3.1.0. Pushed to trunk.
-- >8 --
This fails due to "u" being used in a system header.
FAIL: experimental/names.cc -std=gnu++17 (test for excess errors)
Excess errors:
/usr/include/sys/poll.h:77: error: expected unqualified-id before ';' token
These new headers should probably have the usual boilerplate at the top,
so make the Python scripts output it.
-- >8 --
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Add copyright and
license text to the output.
libstdc++-v3/ChangeLog:
*
These new headers should probably have the usual boilerplate at the top,
so make the Python scripts output it.
-- >8 --
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Add copyright and
license text to the output.
libstdc++-v3/ChangeLog:
*
On Tue, 9 Jan 2024 at 12:44, Jonathan Wakely wrote:
>
> I was talking to Matthias Klose about enabling libstdc++_libbacktrace.a
> for Ubuntu's gcc package and I realised that it would be preferable if
> the gcc-13 branch had those libbacktrace symbols in libstdc++exp.a. I
&
On Tue, 9 Jan 2024 at 12:44, Jonathan Wakely wrote:
>
> I was talking to Matthias Klose about enabling libstdc++_libbacktrace.a
> for Ubuntu's gcc package and I realised that it would be preferable if
> the gcc-13 branch had those libbacktrace symbols in libstdc++exp.a. I
&
On 02/02/24 12:14 +, Jonathan Wakely wrote:
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended
On 02/02/24 12:14 +, Jonathan Wakely wrote:
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended it to contain. We might be able to
avoid that increased
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended it to contain. We might be able to
avoid that increased
Tested x86_64-linux. Pushed to releases/gcc-12 branch.
-- >8 --
This avoids a linker error with -fkeep-inline-functions when including
. We can't backport the fix from trunk because it adds an
export to the shared library. By marking the "missing" symbol
always_inline for C++20 mode we don't
Tested x86_64-linux. Pushed to releases/gcc-12 branch.
-- >8 --
This avoids a linker error with -fkeep-inline-functions when including
. We can't backport the fix from trunk because it adds an
export to the shared library. By marking the "missing" symbol
always_inline for C++20 mode we don't
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v6::network): Define.
(network_v6::hosts): Finish implementing.
(network_v6::to_string): Do not concatenate std::string to
arbitrary std::basic_string
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v6::network): Define.
(network_v6::hosts): Finish implementing.
(network_v6::to_string): Do not concatenate std::string to
arbitrary std::basic_string
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The reverse_invoker utility for PSTL tests uses forwarding references for
all parameters, but some of those parameters get forwarded to move
constructors which then leave the objects in a moved-from state. When
the parameters are forwarded a second
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This looks like a typo in the upstream test that causes a failure in
debug mode. It has been reported upstream.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc: Fix
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This looks like a typo in the upstream test that causes a failure in
debug mode. It has been reported upstream.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc: Fix
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The reverse_invoker utility for PSTL tests uses forwarding references for
all parameters, but some of those parameters get forwarded to move
constructors which then leave the objects in a moved-from state. When
the parameters are forwarded a second
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This was changed by LWG 3857.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(R&&)): Remove
constraint that traits_type must be the same, as per LWG 3857.
*
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This was changed by LWG 3857.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(R&&)): Remove
constraint that traits_type must be the same, as per LWG 3857.
*
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This overload of std::generator::promise_type::yield_value calls things
which might throw, so should not be noexcept. The noexcept was remove by
LWG 3894.
libstdc++-v3/ChangeLog:
* include/std/generator (promise_type::yield_value): Remove
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This should not be noexcept because its _M_syncbuf member has a
potentially-throwing move assignment operator. The noexcept was removed
by LWG 3867.
libstdc++-v3/ChangeLog:
* include/std/syncstream (basic_osyncstream::operator=): Remove
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This should not be noexcept because its _M_syncbuf member has a
potentially-throwing move assignment operator. The noexcept was removed
by LWG 3867.
libstdc++-v3/ChangeLog:
* include/std/syncstream (basic_osyncstream::operator=): Remove
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This overload of std::generator::promise_type::yield_value calls things
which might throw, so should not be noexcept. The noexcept was remove by
LWG 3894.
libstdc++-v3/ChangeLog:
* include/std/generator (promise_type::yield_value): Remove
I'm going to push this as obvious.
-- >8 --
gcc/ChangeLog:
* doc/extend.texi (Common Type Attributes): Fix typo in
description of hardbool.
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
On Thu, 1 Feb 2024 at 17:22, Jonathan Wakely wrote:
>
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all i
On Thu, 1 Feb 2024 at 17:22, Jonathan Wakely wrote:
>
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all i
On Thu, 1 Feb 2024, 17:23 Jonathan Wakely, wrote:
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all integral
On Thu, 1 Feb 2024, 17:23 Jonathan Wakely, wrote:
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all integral
On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
>
> On Feb 01 2024, Jonathan Wakely wrote:
>
> > This will result in an ABI change for targets that use 1-byte alignment
> > for all integral types, e.g. cris-elf.
>
> Or 2-byte alignment as on m68k.
Ah yes.
In fact
On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
>
> On Feb 01 2024, Jonathan Wakely wrote:
>
> > This will result in an ABI change for targets that use 1-byte alignment
> > for all integral types, e.g. cris-elf.
>
> Or 2-byte alignment as on m68k.
Ah yes.
In fact
On Thu, 1 Feb 2024 at 17:08, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Thu, 1 Feb 2024 17:16:47 +0100
>
> > Not speaking for other platforms with default-packed layout
> > or where ABI structure layout alignment implies a change due
> > to PCC_BITFIELD_TYPE_MATTERS and
On Thu, 1 Feb 2024 at 17:08, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Thu, 1 Feb 2024 17:16:47 +0100
>
> > Not speaking for other platforms with default-packed layout
> > or where ABI structure layout alignment implies a change due
> > to PCC_BITFIELD_TYPE_MATTERS and
I am undecided about pushing this PATCH 2/2 to trunk. PATCH 1/2 needs to
be done now due to the ABI impact on cris-elf. This one could wait for
stage 1. (HP, this one probably isn't of interest to you, but I don't
know how to tell git-send-email to only CC you on the first patch).
I'd like to do
I am undecided about pushing this PATCH 2/2 to trunk. PATCH 1/2 needs to
be done now due to the ABI impact on cris-elf. This one could wait for
stage 1. (HP, this one probably isn't of interest to you, but I don't
know how to tell git-send-email to only CC you on the first patch).
I'd like to do
I plan to push this to trunk soon.
CC HP for visibility of the change affecting cris-elf. In practice it
shouldn't make any difference to any sensible code. It only affects
C++20 mode (and later), and only changes the size of std::formatter
objects which are typically only created by the library
I plan to push this to trunk soon.
CC HP for visibility of the change affecting cris-elf. In practice it
shouldn't make any difference to any sensible code. It only affects
C++20 mode (and later), and only changes the size of std::formatter
objects which are typically only created by the library
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These line markers are not needed, because searching
for a macro name works fine. Removing them means that small changes to
do not result in large diffs to
because of all the changed line numbers.
libstdc++-v3/ChangeLog:
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We no longer hit a __builtin_unreachable() in these tests, so we need to
update the dg-error patterns to match _Error_formatter::_M_error().
We can also remove some dg-prune-output directives matching notes saying
"in 'constexpr' expansion" because
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These line markers are not needed, because searching
for a macro name works fine. Removing them means that small changes to
do not result in large diffs to
because of all the changed line numbers.
libstdc++-v3/ChangeLog:
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We no longer hit a __builtin_unreachable() in these tests, so we need to
update the dg-error patterns to match _Error_formatter::_M_error().
We can also remove some dg-prune-output directives matching notes saying
"in 'constexpr' expansion" because
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In C++20 it's deprecated for a [=] lambda capture to capture the 'this'
pointer. Using resize_and_overwrite with a lambda seems like overkill to
write three chars to the string anyway. Just resize the string and
overwrite the end of it directly.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In C++20 it's deprecated for a [=] lambda capture to capture the 'this'
pointer. Using resize_and_overwrite with a lambda seems like overkill to
write three chars to the string anyway. Just resize the string and
overwrite the end of it directly.
On Wed, 31 Jan 2024 at 17:20, xndcn wrote:
>
> Thanks!
>
> > Why not just use -latomic unconditionally here?
> testsuites of libstdc++ seems to have some tricks to find and link
> libatomic.a by using "dg-add-options libatomic", which do nothing for
> x86 target. In previous email, we decide not
On Wed, 31 Jan 2024 at 17:20, xndcn wrote:
>
> Thanks!
>
> > Why not just use -latomic unconditionally here?
> testsuites of libstdc++ seems to have some tricks to find and link
> libatomic.a by using "dg-add-options libatomic", which do nothing for
> x86 target. In previous email, we decide not
On Tue, 30 Jan 2024 at 21:35, Jonathan Wakely wrote:
>
> On 30/01/24 15:02 +, Jonathan Wakely wrote:
> >That way other subdirectories could add their own extra generated files to
> >it.
>
> Like so.
>
> mklog: Add lookup for generated fil
On Tue, 30 Jan 2024 at 21:35, Jonathan Wakely wrote:
>
> On 30/01/24 15:02 +, Jonathan Wakely wrote:
> >That way other subdirectories could add their own extra generated files to
> >it.
>
> Like so.
>
> mklog: Add lookup for generated fil
rward<>
> calls when
> done several times on the same arguments.
>
> Ok to commit ?
>
> François
>
>
> On 31/01/2024 14:11, redi at gcc dot gnu.org wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
>
> Jonathan Wakely changed:
>
rward<>
> calls when
> done several times on the same arguments.
>
> Ok to commit ?
>
> François
>
>
> On 31/01/2024 14:11, redi at gcc dot gnu.org wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
>
> Jonathan Wakely changed:
>
On Wed, 31 Jan 2024 at 19:41, Patrick Palka wrote:
>
> On Wed, 31 Jan 2024, Patrick Palka wrote:
>
> > On Wed, 24 Jan 2024, Patrick Palka wrote:
> > >
> > > In v2:
> > >
> > > * Named the template parameters of the forward declaration of pair.
> > > * Added dangling checks for the new tuple and
On Wed, 31 Jan 2024 at 19:41, Patrick Palka wrote:
>
> On Wed, 31 Jan 2024, Patrick Palka wrote:
>
> > On Wed, 24 Jan 2024, Patrick Palka wrote:
> > >
> > > In v2:
> > >
> > > * Named the template parameters of the forward declaration of pair.
> > > * Added dangling checks for the new tuple and
On Wed, 31 Jan 2024 at 09:38, Iain Sandoe wrote:
>
> Hi Jonathan,
>
> > On 30 Jan 2024, at 15:02, Jonathan Wakely wrote:
> >
> > This should fix the std/text_encoding/* FAILs that Iain sees on darwin.
> > I assume it will make it work for FreeBSD too.
>
On Wed, 31 Jan 2024 at 09:38, Iain Sandoe wrote:
>
> Hi Jonathan,
>
> > On 30 Jan 2024, at 15:02, Jonathan Wakely wrote:
> >
> > This should fix the std/text_encoding/* FAILs that Iain sees on darwin.
> > I assume it will make it work for FreeBSD too.
>
SG16 (Unicode and Text Study Group) and LWG are overwhelmingly in favour
of adding this alias, so let's not wait for the issue to get voted into
the working draft.
Tested aarch64-linux. Pushed to trunk.
-- >8 --
As noted in LWG 4043, "ASCII" is not an alias for any known registered
character
SG16 (Unicode and Text Study Group) and LWG are overwhelmingly in favour
of adding this alias, so let's not wait for the issue to get voted into
the working draft.
Tested aarch64-linux. Pushed to trunk.
-- >8 --
As noted in LWG 4043, "ASCII" is not an alias for any known registered
character
Another piece of the manual that needs to be kept up to date as we add
features.
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/using.xml: Update tables of supported headers.
* doc/html/*: Regenerate.
---
libstdc++-v3/doc/html/manual/index.html | 2
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This shift only happens if the unsigned long long type is wider than
unsigned long but the compiler warns when it sees the shift, without
caring if it's reachable.
Use the preprocessor to compare the sizes and just reuse
Another piece of the manual that needs to be kept up to date as we add
features.
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/using.xml: Update tables of supported headers.
* doc/html/*: Regenerate.
---
libstdc++-v3/doc/html/manual/index.html | 2
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This shift only happens if the unsigned long long type is wider than
unsigned long but the compiler warns when it sees the shift, without
caring if it's reachable.
Use the preprocessor to compare the sizes and just reuse
On 30/01/24 15:02 +, Jonathan Wakely wrote:
That way other subdirectories could add their own extra generated files to it.
Like so.
mklog: Add lookup for generated files in specific sub-directories
The mklog.py output for libstdc++-v3/include/bits/version.h is awful
On 30/01/24 15:02 +, Jonathan Wakely wrote:
That way other subdirectories could add their own extra generated files to it.
Like so.
mklog: Add lookup for generated files in specific sub-directories
The mklog.py output for libstdc++-v3/include/bits/version.h is awful
On Tue, 30 Jan 2024, 15:03 Jonathan Wakely, wrote:
> OK for trunk?
>
> -- >8 --
>
> The mklog.py output for libstdc++-v3/include/bits/version.h is awful.
> Teaching mklog.py that it's generated makes it correctly use
> "Regenerate" for its changes. We
On Tue, 30 Jan 2024, 15:03 Jonathan Wakely, wrote:
> OK for trunk?
>
> -- >8 --
>
> The mklog.py output for libstdc++-v3/include/bits/version.h is awful.
> Teaching mklog.py that it's generated makes it correctly use
> "Regenerate" for its changes. We
On Tue, 16 Jan 2024 at 16:17, xndcn wrote:
>
> Sorry about the mangled content...
> So I add a new add-options for libatomic_16b:
>
> ---
> libstdc++-v3/ChangeLog:
>
> * include/bits/atomic_base.h: add __builtin_clear_padding in
> __atomic_float constructor.
> * testsuite/lib/dg-options.exp: add
On Tue, 16 Jan 2024 at 16:17, xndcn wrote:
>
> Sorry about the mangled content...
> So I add a new add-options for libatomic_16b:
>
> ---
> libstdc++-v3/ChangeLog:
>
> * include/bits/atomic_base.h: add __builtin_clear_padding in
> __atomic_float constructor.
> * testsuite/lib/dg-options.exp: add
On Tue, 16 Jan 2024 at 16:17, xndcn wrote:
>
> Sorry about the mangled content...
> So I add a new add-options for libatomic_16b:
>
> ---
> libstdc++-v3/ChangeLog:
>
> * include/bits/atomic_base.h: add __builtin_clear_padding in
> __atomic_float constructor.
> * testsuite/lib/dg-options.exp: add
On Tue, 16 Jan 2024 at 16:17, xndcn wrote:
>
> Sorry about the mangled content...
> So I add a new add-options for libatomic_16b:
>
> ---
> libstdc++-v3/ChangeLog:
>
> * include/bits/atomic_base.h: add __builtin_clear_padding in
> __atomic_float constructor.
> * testsuite/lib/dg-options.exp: add
On 28/09/23 18:37 +0200, Dimitry Andric wrote:
Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
When building gcc's C++ sources against recent libc++, the poisoning of
the ctype macros due to including safe-ctype.h before including C++
standard headers such as , , etc, causes many
OK for trunk?
-- >8 --
The mklog.py output for libstdc++-v3/include/bits/version.h is awful.
Teaching mklog.py that it's generated makes it correctly use
"Regenerate" for its changes. We can do the same for the other new
generated headers as well.
contrib/ChangeLog:
* mklog.py
OK for trunk?
-- >8 --
The mklog.py output for libstdc++-v3/include/bits/version.h is awful.
Teaching mklog.py that it's generated makes it correctly use
"Regenerate" for its changes. We can do the same for the other new
generated headers as well.
contrib/ChangeLog:
* mklog.py
This should fix the std/text_encoding/* FAILs that Iain sees on darwin.
I assume it will make it work for FreeBSD too.
I won't push this until I hear it works for at least one of those.
Tested x86_64-linux.
-- >8 --
The header is needed for newlocale and locale_t on these
targets.
This should fix the std/text_encoding/* FAILs that Iain sees on darwin.
I assume it will make it work for FreeBSD too.
I won't push this until I hear it works for at least one of those.
Tested x86_64-linux.
-- >8 --
The header is needed for newlocale and locale_t on these
targets.
On Tue, 30 Jan 2024, 10:35 Amol Surati via Gcc, wrote:
> Hello,
>
> If a std attribute name is squeezed between 4x underscores,
>
Which is undefined behaviour, but shouldn't crash.
the compiler (both 13.2 [1] and trunk [2]) experiences an ICE.
>
Bug reports belong in bugzilla, not on the
On Mon, 29 Jan 2024 at 20:25, Ed wrote:
>
>
> On Monday, January 29, 2024 at 03:13:07 PM EST, Jonathan Wakely via Gcc
> wrote:
>
>
> On Mon, 29 Jan 2024 at 19:15, Claudio Bantaloukas via Gcc
> wrote:
> >
> > On 26/01/2024 17:51, Florin Mateoc via Gcc w
On Mon, 29 Jan 2024 at 19:15, Claudio Bantaloukas via Gcc
wrote:
>
> On 26/01/2024 17:51, Florin Mateoc via Gcc wrote:
> > Hi all,
> >
> > I am an experienced software developer, with an interest in compilers, and
> > an admirer of gcc.
> > I would like to contribute, hopefully reusing some of my
l: Link against libstdc++exp.a to use
> _GLIBCXX_DEBUG_BACKTRACE macro.
>
> Ok to commit ?
Yes please - thanks.
>
> François
>
> On 29/01/2024 11:10, Jonathan Wakely wrote:
> > On Mon, 29 Jan 2024 at 06:13, François Dumont wrote:
> >> Hi
> >>
&
l: Link against libstdc++exp.a to use
> _GLIBCXX_DEBUG_BACKTRACE macro.
>
> Ok to commit ?
Yes please - thanks.
>
> François
>
> On 29/01/2024 11:10, Jonathan Wakely wrote:
> > On Mon, 29 Jan 2024 at 06:13, François Dumont wrote:
> >> Hi
> >>
&
On Mon, 29 Jan 2024, 18:24 Jonathan Wakely, wrote:
>
>
> On Mon, 29 Jan 2024, 18:17 Martin Licht via Gcc, wrote:
>
>> GCC seems to have a non-standard lenient C++ overload resolution that is
>> not documented (or easy to find in the manual).
>>
>> The
On Mon, 29 Jan 2024, 18:17 Martin Licht via Gcc, wrote:
> GCC seems to have a non-standard lenient C++ overload resolution that is
> not documented (or easy to find in the manual).
>
> The following C++ code compiles with GCC. However, it produces a warning
> about an ambiguous overload that
On Mon, 29 Jan 2024 at 13:03, Richard Shaw wrote:
>
> On Mon, Jan 29, 2024 at 4:16 AM Jonathan Wakely wrote:
>>
>> On Sun, 28 Jan 2024 at 15:18, Richard Shaw wrote:
>> >
>> > Well I upped the memory to 10GB and got it to build but the issue on i686
>>
On Fri, 26 Jan 2024 at 12:29, Florian Weimer wrote:
> In the past, this kind of problem would have just compiled and resulted
> in a run-time error when the Python extension module is loaded. In some
> cases, issues went completely unnoticed because the Python bindins were
> unused. But with GCC
On Sun, 28 Jan 2024 at 15:18, Richard Shaw wrote:
>
> Well I upped the memory to 10GB and got it to build but the issue on i686
> with the wrong tbb package being pulled in has not been corrected by any of
> the 4 maintainers of the package.
I fixed tbb to stop installing tbb32.pc so the
On Mon, 29 Jan 2024 at 06:13, François Dumont wrote:
>
> Hi
>
> I'm trying to use _GLIBCXX_DEBUG_BACKTRACE to debug some crash in debug
> mode.
>
> So I buit library with --enable-libstdcxx-backtrace=yes
>
> But when I build any test I have:
>
> /usr/bin/ld: /tmp/cctvPvlb.o: in function
>
https://bugs.kde.org/show_bug.cgi?id=469271
Jonathan Wakely changed:
What|Removed |Added
CC||zi...@kayari.org
--- Comment #4 from
On Wed, 24 Jan 2024 at 17:27, Jonathan Wakely wrote:
>
> On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> >
> > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > > @@ -1016,10
On Wed, 24 Jan 2024 at 17:27, Jonathan Wakely wrote:
>
> On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> >
> > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > > @@ -1016,10
On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
>
> On Wed, 24 Jan 2024, Jonathan Wakely wrote:
>
> > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > > b/libstdc++-v3/include/bits/stl_pair.h
>
On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
>
> On Wed, 24 Jan 2024, Jonathan Wakely wrote:
>
> > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > > b/libstdc++-v3/include/bits/stl_pair.h
>
On Wed, 24 Jan 2024 at 12:01, Jonathan Wakely wrote:
>
> On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > b/libstdc++-v3/include/bits/stl_pair.h
> > index b81b479ad43..a9b20fbe7ca 100644
> > --- a/libstd
On Wed, 24 Jan 2024 at 12:01, Jonathan Wakely wrote:
>
> On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > b/libstdc++-v3/include/bits/stl_pair.h
> > index b81b479ad43..a9b20fbe7ca 100644
> > --- a/libstd
On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> diff --git a/libstdc++-v3/include/bits/stl_pair.h
> b/libstdc++-v3/include/bits/stl_pair.h
> index b81b479ad43..a9b20fbe7ca 100644
> --- a/libstdc++-v3/include/bits/stl_pair.h
> +++ b/libstdc++-v3/include/bits/stl_pair.h
> @@ -85,12 +85,70 @@
On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> diff --git a/libstdc++-v3/include/bits/stl_pair.h
> b/libstdc++-v3/include/bits/stl_pair.h
> index b81b479ad43..a9b20fbe7ca 100644
> --- a/libstdc++-v3/include/bits/stl_pair.h
> +++ b/libstdc++-v3/include/bits/stl_pair.h
> @@ -85,12 +85,70 @@
On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
>
> GDB emits end of lines as \r\n, we currently match the reverse \n\r,
We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> possibly leading to mismatches under racy conditions.
What do we incorrectly match? Is the
On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
>
> GDB emits end of lines as \r\n, we currently match the reverse \n\r,
We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> possibly leading to mismatches under racy conditions.
What do we incorrectly match? Is the
e know if ok to commit ?
>
OK, thanks
> François
>
>
> On 22/01/2024 14:42, Théo Papadopoulo wrote:
> > On 1/22/24 14:29, Jonathan Wakely wrote:
> >> On Mon, 22 Jan 2024 at 13:22, Théo Papadopoulo
> >> wrote:
> >>> On 1/22/24 11:07
On Tue, 23 Jan 2024, 23:53 Patrick Palka, wrote:
> This is consistent with std::tuple's __const_assignable member function,
> and will be reused when implementing the new pair::operator= overloads
> from P2165R4.
>
OK
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_pair.h
On Tue, 23 Jan 2024, 23:53 Patrick Palka, wrote:
> This is consistent with std::tuple's __const_assignable member function,
> and will be reused when implementing the new pair::operator= overloads
> from P2165R4.
>
OK
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_pair.h
On Tue, 23 Jan 2024 at 14:16, Jonathan Wakely wrote:
>
> On Tue, 23 Jan 2024 at 02:01, Ming Cheng via Gcc wrote:
> >
> > Hi GCC,
> >
> > Seems Janis is not at IBM. Wondering someone from GCC can help my question?
> >
> > Thanks
> > Ming.
>
701 - 800 of 14804 matches
Mail list logo
