On Wed, 10 Jan 2024 at 21:40, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> This avoids redundant moves when composing and partially applying range
> adaptor objects.
>
> Note that the new constraints on _Partial's constructor templates are
On Wed, 13 Sept 2023 at 21:50, Jonathan Wakely wrote:
>
> On Wed, 13 Sept 2023 at 21:47, François Dumont wrote:
> >
> > It's working and what's I've committed.
>
> Nice, thanks!
>
>
> >
> > Thanks
> >
> > On 12/09/2023 19:04, Jonathan Wakel
On Wed, 13 Sept 2023 at 21:50, Jonathan Wakely wrote:
>
> On Wed, 13 Sept 2023 at 21:47, François Dumont wrote:
> >
> > It's working and what's I've committed.
>
> Nice, thanks!
>
>
> >
> > Thanks
> >
> > On 12/09/2023 19:04, Jonathan Wakel
The first two paragraphs are cloned from existing text for other point
releases. The third paragraph documents a recent backport that should be
called out in the release notes.
Pushed to wwwdocs.
---
htdocs/gcc-13/changes.html | 26 ++
1 file changed, 26 insertions(+)
The first two paragraphs are cloned from existing text for other point
releases. The third paragraph documents a recent backport that should be
called out in the release notes.
Pushed to wwwdocs.
---
htdocs/gcc-13/changes.html | 26 ++
1 file changed, 26 insertions(+)
Some failures related to std::find_if and stdint types were observed
doing mass rebuilds with GCC 14.
Pushed to wwwdocs.
---
htdocs/gcc-14/porting_to.html | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index
Some failures related to std::find_if and stdint types were observed
doing mass rebuilds with GCC 14.
Pushed to wwwdocs.
---
htdocs/gcc-14/porting_to.html | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index
On Thu, 11 Jan 2024 at 12:23, Ken Matsui wrote:
>
> On Thu, Jan 11, 2024 at 3:45 AM Ken Matsui wrote:
> >
> > On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely wrote:
> > > On Thu, 11 Jan 2024 at 10:56, Ken Matsui wrote:
> > > >
> > > > On Thu, 11
On Thu, 11 Jan 2024 at 12:23, Ken Matsui wrote:
>
> On Thu, Jan 11, 2024 at 3:45 AM Ken Matsui wrote:
> >
> > On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely wrote:
> > > On Thu, 11 Jan 2024 at 10:56, Ken Matsui wrote:
> > > >
> > > > On Thu, 11
On Thu, 11 Jan 2024 at 10:50, Jonathan Wakely wrote:
>
> On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
> >
> > On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
> > >On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
> &
On Thu, 11 Jan 2024 at 11:28, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 10:50, Jonathan Wakely wrote:
> > On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
> > >
> > > On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely
> > > wrote:
> > > >
On Thu, 11 Jan 2024 at 10:50, Jonathan Wakely wrote:
>
> On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
> >
> > On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
> > >On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
> &
On Thu, 11 Jan 2024 at 11:28, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 10:50, Jonathan Wakely wrote:
> > On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
> > >
> > > On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely
> > > wrote:
> > > >
On Thu, 11 Jan 2024 at 10:56, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely wrote:
> > On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
> > >
> > > This patch made std::filesystem::equivalent correctly throw an exception
> > >
On Thu, 11 Jan 2024 at 10:56, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely wrote:
> > On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
> > >
> > > This patch made std::filesystem::equivalent correctly throw an exception
> > >
On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
> >On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
> >
> >> libstdc++-v3/ChangeLog:
> >
> >> * sr
On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
> >On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
> >
> >> libstdc++-v3/ChangeLog:
> >
> >> * sr
On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
>
> This patch made std::filesystem::equivalent correctly throw an exception
> when either path does not exist as per [fs.op.equivalent]/4.
Thanks, OK for trunk and all active branches (let me know if you need
help backporting it).
>
>
On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
>
> This patch made std::filesystem::equivalent correctly throw an exception
> when either path does not exist as per [fs.op.equivalent]/4.
Thanks, OK for trunk and all active branches (let me know if you need
help backporting it).
>
>
On Thu, 11 Jan 2024, 09:43 Ken Matsui, wrote:
> libstdc++-v3/ChangeLog:
>
> * src/filesystem/ops-common.h (stat_type): Use using.
>
> Signed-off-by: Ken Matsui
> ---
> libstdc++-v3/src/filesystem/ops-common.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Thu, 11 Jan 2024, 09:43 Ken Matsui, wrote:
> libstdc++-v3/ChangeLog:
>
> * src/filesystem/ops-common.h (stat_type): Use using.
>
> Signed-off-by: Ken Matsui
> ---
> libstdc++-v3/src/filesystem/ops-common.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
rib/ChangeLog
> index 04bde02b65b..11c9c1178bc 100644
> --- a/contrib/ChangeLog
> +++ b/contrib/ChangeLog
> @@ -1,3 +1,8 @@
> +2024-01-10 Michael Levine
> +
> + * libstdc++-v3/include/std/ranges: Remove a duplicate define directive
> + for __glibcxx_want_ranges_iota.
> +
rib/ChangeLog
> index 04bde02b65b..11c9c1178bc 100644
> --- a/contrib/ChangeLog
> +++ b/contrib/ChangeLog
> @@ -1,3 +1,8 @@
> +2024-01-10 Michael Levine
> +
> + * libstdc++-v3/include/std/ranges: Remove a duplicate define directive
> + for __glibcxx_want_ranges_iota.
> +
On Wed, 10 Jan 2024 at 22:08, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK (thanks, this was on my TODO list).
> -- >8 --
>
> Since _Nth_type has a fallback native implementation, use
> _GLIBCXX_USE_BUILTIN_TRAIT when deciding whether
On Wed, 10 Jan 2024 at 22:08, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK (thanks, this was on my TODO list).
> -- >8 --
>
> Since _Nth_type has a fallback native implementation, use
> _GLIBCXX_USE_BUILTIN_TRAIT when deciding whether
On Wed, 10 Jan 2024 at 19:47, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_scalar
> by dispatching to the new __is_scalar built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:47, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_scalar
> by dispatching to the new __is_scalar built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:41, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_unsigned
> by dispatching to the new __is_unsigned built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:47, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_signed
> by dispatching to the new __is_signed built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:41, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_compound
> by dispatching to the new __is_arithmetic built-in trait.
OK for trunk (no need to wait for anything else to be approved).
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 10 Jan 2024 at 19:47, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_signed
> by dispatching to the new __is_signed built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:41, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_unsigned
> by dispatching to the new __is_unsigned built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:41, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_compound
> by dispatching to the new __is_arithmetic built-in trait.
OK for trunk (no need to wait for anything else to be approved).
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 10 Jan 2024 at 19:43, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of
> std::is_floating_point by dispatching to the new
> __is_floating_point built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 10 Jan 2024 at 19:47, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_arithmetic
> by dispatching to the new __is_arithmetic built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 10 Jan 2024 at 19:48, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_integral
> by dispatching to the new __is_integral built-in trait.
OK for trunk (if the new built-in gets approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:47, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_arithmetic
> by dispatching to the new __is_arithmetic built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 10 Jan 2024 at 19:43, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of
> std::is_floating_point by dispatching to the new
> __is_floating_point built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 10 Jan 2024 at 19:48, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_integral
> by dispatching to the new __is_integral built-in trait.
OK for trunk (if the new built-in gets approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 18:33, Daniel Krügler wrote:
>
> Am Mo., 8. Jan. 2024 um 03:25 Uhr schrieb Jonathan Wakely
> :
> >
> > Tested x86_64-linux and aarch64-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > This adds std::runtime_format for C
On Wed, 10 Jan 2024 at 18:33, Daniel Krügler wrote:
>
> Am Mo., 8. Jan. 2024 um 03:25 Uhr schrieb Jonathan Wakely
> :
> >
> > Tested x86_64-linux and aarch64-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > This adds std::runtime_format for C
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Fix some copy & pasted logic in __is_extended_pictographic. This
function should yield false for the values before the first edge, not
true. Also add a missing boundary condition check in __incb_property.
Also Fix an off-by-one error in
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Fix some copy & pasted logic in __is_extended_pictographic. This
function should yield false for the values before the first edge, not
true. Also add a missing boundary condition check in __incb_property.
Also Fix an off-by-one error in
On Tue, 9 Jan 2024 at 21:47, Andreas Schwab wrote:
>
> Tighten the regex to find the start of the .dynsym symtab in the readelf
> output to avoid matching the section symbol in the normal symtab.
OK, thanks.
>
> libstdc++-v3:
> * scripts/extract_symvers.in: Require final colon to only
On Tue, 9 Jan 2024 at 21:47, Andreas Schwab wrote:
>
> Tighten the regex to find the start of the .dynsym symtab in the readelf
> output to avoid matching the section symbol in the normal symtab.
OK, thanks.
>
> libstdc++-v3:
> * scripts/extract_symvers.in: Require final colon to only
Does anybody see any problem with making this change, so that we avoid
the problem described in the PR?
-- >8 --
As described in PR libstdc++/113258 there are old versions of tcmalloc
which replace malloc and related APIs, but do not repalce aligned_alloc
because it didn't exist at the time they
Does anybody see any problem with making this change, so that we avoid
the problem described in the PR?
-- >8 --
As described in PR libstdc++/113258 there are old versions of tcmalloc
which replace malloc and related APIs, but do not repalce aligned_alloc
because it didn't exist at the time they
Tested aarch64-linux. Pushed to trunk.
-- >8 --
I don't remember exactly why I made these bits of code reserve space in
a COW string and append to it, rather than just use the string returned
from std::format (which will undergo copy elision). The _Str_sink type
used by std::format means the
Tested aarch64-linux. Pushed to trunk.
-- >8 --
I don't remember exactly why I made these bits of code reserve space in
a COW string and append to it, rather than just use the string returned
from std::format (which will undergo copy elision). The _Str_sink type
used by std::format means the
On Tue, 9 Jan 2024 at 15:33, Ovais Khan via Gcc-help
wrote:
>
> Hello GCC Project Person,
> I would like to install the latest version of gfortran compiler for
> windows 10 on my computer.
> Could you please provide me with the weblink to download the file and
> necessary instructions to install
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
already did that for trunk with r14-3812-gb96b554592c5cb and trunk no
longer installs
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
already did that for trunk with r14-3812-gb96b554592c5cb and trunk no
longer installs
On Mon, 8 Jan 2024 at 01:19, Jonathan Wakely wrote:
>
> I decided to push this now, not wait for the morning.
>
> This is mostly the same as V2, but adds to the contrib/unicode/README as
> suggested by Lewis, and avoids a trailing whitespace character in the
> generated header.
On Mon, 8 Jan 2024 at 01:19, Jonathan Wakely wrote:
>
> I decided to push this now, not wait for the morning.
>
> This is mostly the same as V2, but adds to the contrib/unicode/README as
> suggested by Lewis, and avoids a trailing whitespace character in the
> generated header.
On Mon, 8 Jan 2024 at 16:25, Hans-Peter Nilsson wrote:
>
> (Sorry, never a bringer of good news...)
Regarding this bit ... even if you're reporting something I've broken,
I like to see it as an incremental step towards better portability, so
it's always good news ;-)
On Mon, 8 Jan 2024 at 16:25, Hans-Peter Nilsson wrote:
>
> (Sorry, never a bringer of good news...)
Regarding this bit ... even if you're reporting something I've broken,
I like to see it as an incremental step towards better portability, so
it's always good news ;-)
On Mon, 8 Jan 2024 at 16:28, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Mon, 8 Jan 2024 17:24:35 +0100
>
> > For some reason, this (r14-6990-g74a0dab18292be) breaks a
> > build of (newlib targets) at least cris-elf and arm-eabi:
>
> ...aaand, just now fixed in
On Mon, 8 Jan 2024 at 16:28, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Mon, 8 Jan 2024 17:24:35 +0100
>
> > For some reason, this (r14-6990-g74a0dab18292be) breaks a
> > build of (newlib targets) at least cris-elf and arm-eabi:
>
> ...aaand, just now fixed in
Tested x86_64-linux, pushed to trunk.
-- >8 --
The name __null_sentinel is defined as a macro by newlib, so we can't
use it as an identifier. That variable is not actually used by
libstdc++, it was added because P2728R6 proposes std::uc::null_sentinel.
Since we don't need it and it breaks
Tested x86_64-linux, pushed to trunk.
-- >8 --
The name __null_sentinel is defined as a macro by newlib, so we can't
use it as an identifier. That variable is not actually used by
libstdc++, it was added because P2728R6 proposes std::uc::null_sentinel.
Since we don't need it and it breaks
On Mon, 8 Jan 2024 at 01:22, Jonathan Wakely wrote:
>
> On Mon, 8 Jan 2024 at 01:13, Jonathan Wakely wrote:
> >
> > This V2 patch failed CI:
> > https://patchwork.sourceware.org/project/gcc/patch/20240106151802.3356059-1-jwak...@redhat.com/
> >
> > But
On Mon, 8 Jan 2024 at 01:22, Jonathan Wakely wrote:
>
> On Mon, 8 Jan 2024 at 01:13, Jonathan Wakely wrote:
> >
> > This V2 patch failed CI:
> > https://patchwork.sourceware.org/project/gcc/patch/20240106151802.3356059-1-jwak...@redhat.com/
> >
> > But
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This change makes std::make_format_args refuse to create dangling
references to temporaries. This makes the std::vformat API safer. This
was approved in Kona 2023 as a DR for C++20 so the change is implemented
unconditionally.
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This adds std::runtime_format for C++26. These new overloaded functions
enhance the std::format API so that it isn't necessary to use the less
ergonomic std::vformat and std::make_format_args (which are meant to be
implementation
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This change makes std::make_format_args refuse to create dangling
references to temporaries. This makes the std::vformat API safer. This
was approved in Kona 2023 as a DR for C++20 so the change is implemented
unconditionally.
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This adds std::runtime_format for C++26. These new overloaded functions
enhance the std::format API so that it isn't necessary to use the less
ergonomic std::vformat and std::make_format_args (which are meant to be
implementation
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This change ensures that char and wchar_t arguments are formatted
consistently when using integer presentation types. This avoids
non-portable std::format output that depends on whether char and wchar_t
happen to be signed or
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This change ensures that char and wchar_t arguments are formatted
consistently when using integer presentation types. This avoids
non-portable std::format output that depends on whether char and wchar_t
happen to be signed or
On Sun, 7 Jan 2024 at 18:50, François Dumont wrote:
>
>
> On 07/01/2024 17:34, Jonathan Wakely wrote:
> > On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
> >> Hi
> >>
> >> While working on the patch to use the cxx11 abi in gnu version
On Sun, 7 Jan 2024 at 18:50, François Dumont wrote:
>
>
> On 07/01/2024 17:34, Jonathan Wakely wrote:
> > On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
> >> Hi
> >>
> >> While working on the patch to use the cxx11 abi in gnu version
On Sun, 7 Jan 2024 at 16:40, Patrick Palka wrote:
>
> On Tue, 5 Dec 2023, Jonathan Wakely wrote:
>
> > On Wed, 22 Nov 2023 at 14:50, Jonathan Wakely wrote:
> > >
> > > On Mon, 20 Nov 2023 at 02:56, Jason Merrill wrote:
> > > >
> > > > T
On Sun, 7 Jan 2024 at 16:40, Patrick Palka wrote:
>
> On Tue, 5 Dec 2023, Jonathan Wakely wrote:
>
> > On Wed, 22 Nov 2023 at 14:50, Jonathan Wakely wrote:
> > >
> > > On Mon, 20 Nov 2023 at 02:56, Jason Merrill wrote:
> > > >
> > > > T
On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
>
> Hi
>
> While working on the patch to use the cxx11 abi in gnu version namespace
> mode I got a small problem with this missing constructor. I'm not sure
> that the main patch will be integrated in gcc 14 so I think it is better
> if I
On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
>
> Hi
>
> While working on the patch to use the cxx11 abi in gnu version namespace
> mode I got a small problem with this missing constructor. I'm not sure
> that the main patch will be integrated in gcc 14 so I think it is better
> if I
Tested x86_64-linux. Pushed to trunk.
-- >8 --
r14-1527-g2415024e0f81f8 changed the parameter of the
__cxa_call_terminate definition, but there's also a declaration in
unwind-cxx.h which should have been changed too.
libstdc++-v3/ChangeLog:
PR libstdc++/112997
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
r14-1527-g2415024e0f81f8 changed the parameter of the
__cxa_call_terminate definition, but there's also a declaration in
unwind-cxx.h which should have been changed too.
libstdc++-v3/ChangeLog:
PR libstdc++/112997
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As the comment notes, the increased timeout was needed because of PR
102780, but that was fixed long ago.
libstdc++-v3/ChangeLog:
* testsuite/20_util/variant/87619.cc: Remove dg-timeout-factor.
---
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As the comment notes, the increased timeout was needed because of PR
102780, but that was fixed long ago.
libstdc++-v3/ChangeLog:
* testsuite/20_util/variant/87619.cc: Remove dg-timeout-factor.
---
Pushed to trunk now.
On Thu, 14 Dec 2023 at 01:09, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Does this look right? Can we do it faster, or simplify it?
>
> -- >8 --
>
> This reduces the overhead of using std::is_trivially_destructible_v and
> as a result
Pushed to trunk now.
On Thu, 14 Dec 2023 at 01:09, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Does this look right? Can we do it faster, or simplify it?
>
> -- >8 --
>
> This reduces the overhead of using std::is_trivially_destructible_v and
> as a result
On Sat, 6 Jan 2024 at 17:03, Jonathan Wakely wrote:
>
> On Sat, 6 Jan 2024 at 16:57, Lewis Hyatt wrote:
> >
> > On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote:
> > >
> > > Here's a V2 patch which addresses the two things I mentioned: the new
> >
On Sat, 6 Jan 2024 at 17:03, Jonathan Wakely wrote:
>
> On Sat, 6 Jan 2024 at 16:57, Lewis Hyatt wrote:
> >
> > On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote:
> > >
> > > Here's a V2 patch which addresses the two things I mentioned: the new
> >
On Sat, 6 Jan 2024 at 16:57, Lewis Hyatt wrote:
>
> On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote:
> >
> > Here's a V2 patch which addresses the two things I mentioned: the new
> > Python script now generates a complete file that can just be included by
> >
On Sat, 6 Jan 2024 at 16:57, Lewis Hyatt wrote:
>
> On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote:
> >
> > Here's a V2 patch which addresses the two things I mentioned: the new
> > Python script now generates a complete file that can just be included by
> >
On Fri, 5 Jan 2024 at 14:12, Jonathan Wakely wrote:
>
> On 06/12/23 15:34 +0100, Gwenole Beauchesne wrote:
> >Tested on x86_64-pc-linux-gnu with --enable-languages=c,c++ and
> >additional -Wformat to CXXFLAGS.
>
> Please CC the libstdc++@gcc.gnu.org list on all libstdc++
On Fri, 5 Jan 2024 at 14:12, Jonathan Wakely wrote:
>
> On 06/12/23 15:34 +0100, Gwenole Beauchesne wrote:
> >Tested on x86_64-pc-linux-gnu with --enable-languages=c,c++ and
> >additional -Wformat to CXXFLAGS.
>
> Please CC the libstd...@gcc.gnu.org list on all libstdc++
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This prevents a std::filesystem::path from exceeding INT_MAX/4
components (which is unlikely to ever be a problem except on 16-bit
targets). That limit ensures that the capacity*1.5 calculation doesn't
overflow. We should also check that we don't
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This prevents a std::filesystem::path from exceeding INT_MAX/4
components (which is unlikely to ever be a problem except on 16-bit
targets). That limit ensures that the capacity*1.5 calculation doesn't
overflow. We should also check that we don't
Tested x86_64-linux. Pushed to trunk, backport to gcc-13 needed too.
-- >8 --
The new __is_convertible built-in should only be used after checking
that it's supported.
libstdc++-v3/ChangeLog:
PR libstdc++/113241
* include/std/type_traits (is_convertible_v): Guard use of
Tested x86_64-linux. Pushed to trunk, backport to gcc-13 needed too.
-- >8 --
The new __is_convertible built-in should only be used after checking
that it's supported.
libstdc++-v3/ChangeLog:
PR libstdc++/113241
* include/std/type_traits (is_convertible_v): Guard use of
On 06/12/23 15:34 +0100, Gwenole Beauchesne wrote:
Tested on x86_64-pc-linux-gnu with --enable-languages=c,c++ and
additional -Wformat to CXXFLAGS.
Please CC the libstd...@gcc.gnu.org list on all libstdc++ patches, as
documented at https://gcc.gnu.org/lists.html
Otherwise I won't see the
On 06/12/23 15:34 +0100, Gwenole Beauchesne wrote:
Tested on x86_64-pc-linux-gnu with --enable-languages=c,c++ and
additional -Wformat to CXXFLAGS.
Please CC the libstdc++@gcc.gnu.org list on all libstdc++ patches, as
documented at https://gcc.gnu.org/lists.html
Otherwise I won't see the
On Fri, 5 Jan 2024 at 13:00, Martin Küttler
wrote:
>
>
> >>This is a small change to libstdc++ which does not change any behavior.
> >
> > Please CC the libstd...@gcc.gnu.org list on all libstdc++ patches, as
> > documented at https://gcc.gnu.org/lists.html
>
> Acknowledged. Sorry.
>
> >>This
On Fri, 5 Jan 2024 at 13:00, Martin Küttler
wrote:
>
>
> >>This is a small change to libstdc++ which does not change any behavior.
> >
> > Please CC the libstdc++@gcc.gnu.org list on all libstdc++ patches, as
> > documented at https://gcc.gnu.org/lists.html
>
> Acknowledged. Sorry.
>
> >>This
On 18/12/23 09:36 +0100, Martin Küttler wrote:
This is a small change to libstdc++ which does not change any behavior.
Please CC the libstd...@gcc.gnu.org list on all libstdc++ patches, as
documented at https://gcc.gnu.org/lists.html
Otherwise I won't see the patches unless I happen to glance
On 18/12/23 09:36 +0100, Martin Küttler wrote:
This is a small change to libstdc++ which does not change any behavior.
Please CC the libstdc++@gcc.gnu.org list on all libstdc++ patches, as
documented at https://gcc.gnu.org/lists.html
Otherwise I won't see the patches unless I happen to glance
On Fri, 5 Jan 2024 at 10:33, Nani Rodrigue via Gcc wrote:
>
> Good morning
>
> Can I get the last version of an application of gcc for Windows ?
Not from here, no. See https://gcc.gnu.org/install/binaries.html
There are also the https://nuwen.net/mingw.html and
Tested x86_64-linux. Pushed to trunk. Backports needed too.
-- >8 --
The current constexpr implementation of std::char_traits::move relies
on being able to compare the pointer parameters, which is not allowed
for unrelated pointers. We can use __builtin_constant_p to determine
whether it's safe
From: Cassio Neri
Tested x86_64-linux. Pushed to trunk.
This seems suitable for backporting too, at least to gcc-13.
-- >8 --
The following invoke signed integer overflow (UB) [1]:
month + months{MAX} // where MAX is the maximum value of months::rep
month + months{MIN} // where MIN
Tested x86_64-linux. Pushed to trunk. Backports needed too.
-- >8 --
The current constexpr implementation of std::char_traits::move relies
on being able to compare the pointer parameters, which is not allowed
for unrelated pointers. We can use __builtin_constant_p to determine
whether it's safe
1101 - 1200 of 14961 matches
Mail list logo
