On Wed, 31 Jul 2024 at 19:18, Jonathan Wakely wrote:
>
> On Wed, 31 Jul 2024 at 19:17, Dimitar Dimitrov wrote:
> >
> > On Wed, Jul 31, 2024 at 05:09:52PM +0100, Jonathan Wakely wrote:
> > > It took a while, but I was finally happy with this v4 patch, so I pushed
> &
On Wed, 31 Jul 2024 at 21:44, François Dumont wrote:
>
> Committed as trivial.
>
> Fix a compilation error that is not expected by the tests preserving
> the expected ones.
>
> The 'test' variable declaration is missing since commit
> a9260b7eb688df43a724e25421ba40f35a89fee9 that removed the test
On Wed, 31 Jul 2024 at 21:59, Jonathan Wakely wrote:
>
> On Wed, 31 Jul 2024 at 21:44, François Dumont wrote:
> >
> > Committed as trivial.
> >
> > Fix a compilation error that is not expected by the tests preserving
> > the expected ones.
> >
> >
On Wed, 24 Jul 2024 at 14:14, William Tsai wrote:
>
> The template `future.wait_until` will expand to
> `_M_load_and_test_until_impl` where it will call
> `_M_load_and_test_until*` with given time_point casted into second and
> nanosecond. The callee expects the caller to provide the values
> corr
On Thu, 1 Aug 2024 at 06:09, François Dumont wrote:
>
> Do you want me to take care of those 2 tests ?
Yes please.
>
> You seem to have started something on the review of dg-error patterns in
> use.
>
> Here I kept the test variable because I fear to potentially have a
> diagnostic about unused
ise.
>
> Comitted with you as author.
Great, thanks.
> François
>
>
> On 01/08/2024 09:26, Jonathan Wakely wrote:
> > On Thu, 1 Aug 2024 at 06:09, François Dumont wrote:
> >> Do you want me to take care of those 2 tests ?
> > Yes please.
> >
> >> You see
I added similar constraints to std::vector recently. The same problem
exists for std::string, so this fixes it.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is needed to avoid errors outside the immediate context when
evaluating is_default_constructible_v> when A is
not default constructi
I've had this in my local tree for ages, time to push it I think. It's
better to be non-conforming than to lie and posibly terminate the whole
process (the COW std::string is already non-conforming in C++11 and
later anyway).
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The C++17 non-const ove
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This should have been done as part of r13-693-ge3b8b4f7814c54, but I
only added the preprocessor logic and didn't use ARGS in the code.
libstdc++-v3/ChangeLog:
*
testsuite/26_numerics/random/discrete_distribution/operators/values.cc:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As noted in the PR the compiler doesn't seem able to do this on its own,
so we get better code at all optimization levels by using memcmp.
libstdc++-v3/ChangeLog:
PR libstdc++/113807
* include/std/bitset (bitset::_M_is_equal()): Use
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (__atomic_impl::compare_exchange_weak):
Remove unused parameter.
(__atomic_impl::compare_exchange_strong): Likewise.
---
libstdc++-v3/include/bits/atomic_base.h | 6 ++
This will probably need a gcc-15/porting_to.html entry at some point.
Every time we remove transitive includes of it breaks
somebody!
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We don't need to include all of when we only need uintptr_t
from it. By using GCC's internal macro we avoid unnec
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These are not used anywhere, we have more efficient variable templates
for them instead. They're not documented as extensions, and are easy for
users to write if they need them.
libstdc++-v3/ChangeLog:
* include/bits/utility.h (__is_in_plac
Tested x86_64-linux and sparc-solaris.
I really need to add some tests that use modified formats like %EY and
%OS for locales that actually have special forms for those. We don't
have any such tests now, and with this change most of the _M_locale_fmt
code paths are no longer exercised at all. So b
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
PR tree-optimization/102958
* include/bits/char_traits.h (char_traits::length): Use
strlen.
---
libstdc++-v3/include/bits/char_traits.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libstdc++
Tested x86_64-linux.
-- >8 --
This is LWG 4084 which I filed recently. LWG seems to support making the
change, so that std::num_put can use the %F format for floating-point
numbers.
libstdc++-v3/ChangeLog:
PR libstdc++/114862
* src/c++98/locale_facets.cc (__num_base::_S_format_f
Tested x86_64-linux.
-- >8 --
LWG 436 confirmed that const-qualified types are valid arguments for
Facet template parameters, but volatile-qualified types are not.
libstdc++-v3/ChangeLog:
* include/bits/locale_classes.h:
* include/bits/locale_classes.tcc:
---
libstdc++-v3/inclu
It makes me a big sad that we need to do this, but the _S_cast_flt
function should get optimized away completely on targets where it
doesn't need to do anything special.
As far as I know only RISC-V needs special handling, but we could extend
it to other targets if needed.
Tested x86_64-linux.
-
The latest in the series of "rewrite all our enable_if-based overload
sets using concepts!" improvements.
A smaller change will be needed on the branches, this is just for trunk.
Tested x86_64-linux.
-- >8 --
Using std::is_constructible in the constraints introduces a spurious
dependency on the
On Fri, 2 Aug 2024 at 02:29, Andrew Pinski wrote:
>
> On Thu, Aug 1, 2024 at 2:14 PM Jonathan Wakely wrote:
> >
> > This will probably need a gcc-15/porting_to.html entry at some point.
> > Every time we remove transitive includes of it breaks
> > somebody!
>
&
On Fri, 2 Aug 2024 at 10:35, Giuseppe D'Angelo wrote:
>
> Hello,
>
> On 31/07/2024 00:55, Jonathan Wakely wrote:
> > If __cpp_lib_is_virtual_base_of depends on __has_builtin, then that
> > will do the right thing for #ifdef __cpp_lib_is_virtual_base_of in
> > .
Rivos CI found a problem in the v1 patch (see the PR comments). This
should solve it, by using 'constexpr' not _GLIBCXX17_CONSTEXPR. That
requires diagnostic pragmas to suppress -Wc++17-extensions and isn't
possible at all in C++98 mode, so just use the slightly less efficient
__builtin_signbit(__f
On Fri, 2 Aug 2024 at 11:45, Giuseppe D'Angelo wrote:
>
> Hello,
>
> The attached patch adds support for P2248R8 + P3217R0 (Enabling
> list-initialization for algorithms, C++26). The big question is whether
> this keeps the code readable enough without introducing too much
> #ifdef-ery, so any feed
On Fri, 2 Aug 2024 at 13:17, Jonathan Wakely wrote:
>
> On Fri, 2 Aug 2024 at 11:45, Giuseppe D'Angelo wrote:
> >
> > Hello,
> >
> > The attached patch adds support for P2248R8 + P3217R0 (Enabling
> > list-initialization for algorithms, C++26). The big qu
This isn't properly tested so I'm not pushing it, but I'm sharing it now
for comment.
-- >8 --
Inspired by https://github.com/llvm/llvm-project/issues/101614 this
replaces the deduced return type of std::forward_like with a type trait
to compute that type.
libstdc++-v3/ChangeLog:
* incl
On Fri, 2 Aug 2024 at 23:43, Patrick Palka wrote:
>
> On Fri, 2 Aug 2024, Patrick Palka wrote:
>
> > On Fri, 2 Aug 2024, Jonathan Wakely wrote:
> >
> > > This isn't properly tested so I'm not pushing it, but I'm sharing it now
> > > for comme
On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
wrote:
>
> Hello,
>
> as usual thank you for the review. V2 is attached.
>
> On 02/08/2024 14:38, Jonathan Wakely wrote:
> > On Fri, 2 Aug 2024 at 13:17, Jonathan Wakely wrote:
> >>
> >> On Fr
On Tue, 6 Aug 2024, 17:28 Andi Kleen, wrote:
> Cassio Neri writes:
>
> > Implement the template function teju_jagua which finds the shortest
> > representation of a floating-point number. The floating-point type is a
> > template parameter and the implementation is generic enough to handle all
>
Tested powerpc64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/116247
* include/bits/fs_path.h: Use __UINTPTR_TYPE__ instead of
uintptr_t.
* include/bits/shared_ptr_atomic.h: Likewise.
* include/ext/pointer.h: Include .
---
libstdc
On Fri, 12 Apr 2024, 21:51 H.J. Lu, wrote:
> * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt:
> Updated.
>
OK thanks
---
> .../abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
> a/libstdc++-v3/conf
On Mon, 15 Apr 2024 at 14:01, Andreas Schwab wrote:
>
>
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
OK for trunk and gcc-13, thanks.
> ---
> .../config/abi/post/riscv64-linux-gnu/baseline_symbols.txt| 4
> 1 file changed, 4 insertions(+)
>
> diff --git
>
On Thu, 11 Apr 2024 at 15:51, Jonathan Wakely wrote:
>
> On Thu, 11 Apr 2024 at 15:50, Jakub Jelinek wrote:
> >
> > Hi!
> >
> > When we are already touching this topic, here is a patch like r13-5126
> > which documents the upcoming release symbol versions in the
Pushed to trunk now.
On Wed, 10 Apr 2024 at 09:53, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++26 it seems OK for trunk now.
>
> -- >8 --
>
> This C++26 change was just approved in Tokyo, in P2944R3. It adds
> operator== an
Pushed to trunk now.
On Wed, 10 Apr 2024 at 09:51, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++20 and later it seems OK for trunk now.
>
> -- >8 --
>
> I'm only treating this as a DR for C++20 for now, because it's les
Pushed to trunk now.
On Mon, 8 Apr 2024 at 17:53, Jonathan Wakely wrote:
>
> Patch v2.
>
> I realised that it's not only negative delim values that cause the
> problem, but also ones greater than CHAR_MAX. Calling ignore(n, 'a'+256)
> will cause traits_typ
On Tue, 16 Apr 2024, 04:17 Alexandre Oliva, wrote:
>
> VxWorks fails to load kernel-mode modules with weak undefined symbols.
> In RTP mode modules, that undergo final linking, weak undefined
> symbols are not a problem.
>
> This patch adds kernel-mode VxWorks multilibs to the set of targets
> th
On Tue, 16 Apr 2024, 04:19 Alexandre Oliva, wrote:
>
> Tests 20_util/from_chars/4.cc and 20_util/to_chars/long_double.cc were
> adjusted about a year ago to skip long double on some targets, because
> the fastfloat library was limited to 64-bit doubles.
>
> The same problem comes up in similar fl
On Tue, 16 Apr 2024 at 04:49, Alexandre Oliva wrote:
>
>
> On arm-vx7r2, the uses of as.load() as initializer get SRAed, so the
> padding bits in the tests are not what we might expect from full-word
> struct copies.
Aha, I was wondering why this was failing on ARM!
> I tried adding a function
On Tue, 16 Apr 2024 at 04:37, Alexandre Oliva wrote:
>
>
> A number of libstdc++ tests that implicitly instantiate
> __to_chars_i and also link floating_to_chars.o in
> fail on vxworks kernel mode. The platform doesn't support undefweak
> symbols (the kernel module loader fails to load modules co
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* config/locale/dragonfly/numeric_members.cc: Fix typos in
comments.
* config/locale/gnu/numeric_members.cc: Likewise.
---
libstdc++-v3/config/locale/dragonfly/numeric_members.cc | 4 ++--
libstdc++-v
On Wed, 17 Apr 2024 at 08:58, Matthias Kretz wrote:
>
> Tested on arm-linux-gnueabihf, powerpc64le-linux-gnu, and aarch64-linux-gnu.
>
> OK for trunk and backports?
OK, thanks.
>
> - 8< --
>
> This resolves failing tests in check-simd.
>
> Sig
On Wed, 17 Apr 2024 at 09:17, Matthias Kretz wrote:
>
> This never showed up as an issue because it's an internal header and
> implicitly guarded by bits/simd.h.
>
> OK for trunk? Any reason to backport?
OK for trunk, I think it's worth backporting too.
>
> - 8<
Tested x86_64-linux and x86_64-freebsd. Pushed to trunk.
-- >8 --
This was recently approved for C++26 at the Tokyo meeting. As suggested
by Stephan T. Lavavej, I'm defining it as an extension for C++23 mode
(when std::print and std::prinln were first added) rather than as a new
C++26 feature. Bo
This would fix the but, how do people feel about it this close to the
gcc-14 release?
Tested x86_64-linux.
-- >8 --
Since 2022 the TZif format defined in the zic(8) man page has said that
links can refer to other links, rather than only referring to a zone.
This isn't supported by the C++20 spec
On Thu, 18 Apr 2024 at 17:33, Jonathan Wakely wrote:
>
> This would fix the but,
*fix the bug
> how do people feel about it this close to the
> gcc-14 release?
>
> Tested x86_64-linux.
In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
but that wasn't true. Only the symbols from the latter were added to
libstdc++exp.a, the Filesystem TS ones weren't. This seems to be because
libtool won't
This completes the fixes to put all experimental symbols into
libstdc++exp.a.
On trunk the libstdc++_libbacktrace.a was removed completely and its
contents aded to libstdc++exp.a instead. We don't want to do that on the
gcc-13 branch because it will break makefiles using it. We can add the
content
a_FOO variable?
One advantage of the symlink approach is that we don't increase the
installed footprint of gcc-13 by duplicating all the backtrace symbols
in two static archives. We could even consider making libstdc++fs.a a
symlink to libstdc++exp.a as well, on trunk and gcc-13, to stop
dupli
On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
>
> This completes the fixes to put all experimental symbols into
> libstdc++exp.a.
>
> On trunk the libstdc++_libbacktrace.a was removed completely and its
> contents aded to libstdc++exp.a instead. We don't want to
On Fri, 19 Apr 2024 at 07:14, Richard Biener wrote:
>
> On Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely wrote:
> >
> > This would fix the but, how do people feel about it this close to the
> > gcc-14 release?
>
> Guess we'll have to fix it anyway, so why not
On Thu, 18 Apr 2024 at 22:59, Patrick Palka wrote:
>
> On Wed, 17 Apr 2024, Michael Levine (BLOOMBERG/ 919 3RD A) wrote:
>
> > This patch fixes GCC Bug 108760:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
> > Before this patch, using std::ranges::iota required including
> > when it s
On Fri, 19 Apr 2024 at 10:08, Jonathan Wakely wrote:
>
> On Fri, 19 Apr 2024 at 07:14, Richard Biener
> wrote:
> >
> > On Thu, Apr 18, 2024 at 6:34 PM Jonathan Wakely wrote:
> > >
> > > This would fix the but, how do people feel about it this close to
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Instead of constraining these overloads in terms of synth-three-way we
can just check that the value_type is less-than-comparable, which is
what synth-three-way's constraints check.
The reason that I implemented these with constraints has now been f
OK for wwwdocs?
---
htdocs/gcc-14/changes.html | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 9509487c..21d33db8 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -696,13
On Mon, 22 Apr 2024 at 16:37, Jakub Jelinek wrote:
>
> Hi!
>
> We see
> FAIL: 17_intro/headers/c++1998/all_attributes.cc (test for excess errors)
> FAIL: 17_intro/headers/c++2011/all_attributes.cc (test for excess errors)
> FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess er
On Mon, 22 Apr 2024 at 16:30, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?
OK
>
> - 8< -
>
> Signed-off-by: Matthias Kretz
>
> l
On Mon, 22 Apr 2024 at 16:30, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?
OK, thanks
>
> - 8< -
>
>
> Avoid
> -Wnarrowing in C c
* c.opt (Wstrict-flex-arrays): Spelling fix: inproper -> improper.
> gcc/cp/
> * parser.cc (cp_parser_using_declaration): Spelling fix: favour
> -> favor.
> gcc/m2/
> * lang.opt (fuse-list=): Spelling fix: finalializations ->
> finalizations.
LGTM
+Reviewed-by: Jonathan Wakely
On Tue, 23 Apr 2024 at 17:05, Jakub Jelinek wrote:
>
> On Mon, Apr 22, 2024 at 11:14:35PM -0400, Jason Merrill wrote:
> > > > The following testcase regressed with Marek's r14-5979 change,
> > > > when pr113208_0.C is compiled where the ctor is marked constexpr,
> > > > we no longer perform this o
Pushed to gcc-13
On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
>
> In r14-3812-gb96b554592c5cb I claimed that libstdc++exp.a now contains
> all the symbols from libstdc++fs.a as well as libstdc++_libbacktrace.a,
> but that wasn't true. Only the symbols from the lat
Tested x86_64-linux. Pushed to trunk.
-- >8 --
It's not obvious why needs so add a
comment to it.
libstdc++-v3/ChangeLog:
* include/std/variant: Add comment to #include.
---
libstdc++-v3/include/std/variant | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/doxygen/stdheader.cc (init_map): Add missing headers.
* doc/doxygen/user.cfg.in (EXCLUDE): Exclude generated files for
std::format and std::text_encoding.
---
libstdc++-v3/
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/chrono (tzdb_list): Fix typo in Doxygen comment.
---
libstdc++-v3/include/std/chrono | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/std/ch
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
Doxygen switched from \fC to \fR in its man page output:
https://github.com/doxygen/doxygen/pull/10497
This breaks our script that expects \fC so change the regaulr expression
to work with either style.
libstdc++-v3/ChangeLog:
Tested x86_64-linux, and docs regenerated. Pushed to trunk.
-- >8 --
The Doxygen-generated man pages for some new types need to be renamed to
use '::' instead of '_' in the filenames.
libstdc++-v3/ChangeLog:
* scripts/run_doxygen: Rename man pages for nested types.
---
libstdc++-v3/scr
On Thu, 18 Apr 2024 at 21:34, Jonathan Wakely wrote:
>
> On Thu, 18 Apr 2024 at 20:51, Jonathan Wakely wrote:
> >
> > This completes the fixes to put all experimental symbols into
> > libstdc++exp.a.
> >
> > On trunk the libstdc++_libbacktrace.a was removed com
Pushed to trunk. I'll also be following this with the non-whitespace
equivalents for the gcc-14 and gcc-13 branches.
-- >8 --
This simplifies the changes needed after branching for a new release, so
that new line breaks don't need to be introduced every time we branch.
libstdc++-v3/ChangeLog:
Pushed to gcc-13.
-- >8 --
This should have been done before the 13.1.0 release.
libstdc++-v3/ChangeLog:
* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml: Likew
Pushed to gcc-14.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likew
Tested x86_64-linux. Pushed to trunk.
I'm going to push this to gcc-13 and gcc-14 too (approved by Jakub on
IRC).
-- >8 --
We don't want to add grouping to strings like "-inf", and there is no
radix character to replace either.
libstdc++-v3/ChangeLog:
PR libstdc++/114863
* incl
On Mon, 22 Apr 2024 at 22:43, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk? More tests
> are needed but I figured I'd submit this now for possible consideration into
> GCC 14 since we're getting close to release.. All changes are confined to
> C++26.
OK for
On 20/11/23 11:22 -0500, Ben Boeckel wrote:
---
htdocs/gcc-14/changes.html | 11 +++
1 file changed, 11 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 7278f753..b506eeb1 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -
On Mon, 22 Apr 2024 at 12:35, Georg-Johann Lay wrote:
>
> Am 22.04.24 um 12:04 schrieb Jonathan Wakely:
> > OK for wwwdocs?
>
> For me it's ok (I am not a native speaker though,
> which is the reason the typos are there to begin with).
I've pushed this now.
&
Tested x86_64-linux. Pushed to trunk.
I'll backport this to gcc-14 as well, but it can wait until after the
14.1 release.
-- >8 --
This type trait isn't supported by Clang 18. It's only used in static
assertions, so they can just be omitted if the trait isn't available.
libstdc++-v3/ChangeLog:
Tested x86_64-linux.
I'm considering making the increment of __to_incr conditional:
if constexpr (!random_access_iterator<_Iter>)
++__to_incr;
and then when we call _M_update using _M_curr() - __g._M_orig for the
number of characters consumed. I should benchmark that to see if it
makes
I found some issues in the std::chrono::tzdb parser by testing the
tzdata "vanguard" format, which uses new features that aren't enabled in
the "main" and "rearguard" data formats.
Since 2024a the keyword "minimum" is no longer valid for the FROM and TO
fields in a Rule line, which means that "m"
On Thu, 2 May 2024 at 12:24, Jonathan Wakely wrote:
>
> I found some issues in the std::chrono::tzdb parser by testing the
> tzdata "vanguard" format, which uses new features that aren't enabled in
> the "main" and "rearguard" data formats.
>
>
Tested x86_64-linux.
It would also be possible to fix this with:
#if ! _GLIBCXX_HOSTED
template inline constexpr __is_shared_ptr = false;
#endif
But we would still need to guard the partial specializations that use
shared_ptr and __shared_ptr. It seemed cleaner to just guard all uses of
anythi
On Thu, 2 May 2024 at 18:38, Ville Voutilainen
wrote:
>
> On Thu, 2 May 2024 at 20:25, Ken Matsui wrote:
> > > There was some discussion of how to name the built-ins back in
> > > https://gcc.gnu.org/pipermail/gcc-patches/2007-March/thread.html#212171
> > > but __builtin wasn't discussed.
> > >
>
On Fri, 3 May 2024 at 10:30, Andreas Schwab wrote:
>
> * config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Update.
OK thanks
> ---
> .../powerpc-linux-gnu/baseline_symbols.txt| 98
On Fri, 3 May 2024 at 11:51, Jonathan Wakely wrote:
>
> On Fri, 3 May 2024 at 10:30, Andreas Schwab wrote:
> >
> > * config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
> > * config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt:
> &g
it in the caveats
section at the top, not as the last item of the C section.
How about this? OK for wwwdocs?
-- >8 --
commit fe5fd75ea5a7a08eee0831cadbdd05689e9408db
Author: Jonathan Wakely
Date: Fri May 3 16:04:49 2024 +0100
Add caveat to GCC 14 release notes about C warnings-as-err
On Thu, 2 May 2024 at 19:03, Ben Boeckel wrote:
>
> On Tue, Apr 30, 2024 at 10:24:44 +0100, Jonathan Wakely wrote:
> > On 20/11/23 11:22 -0500, Ben Boeckel wrote:
> > >---
> > > htdocs/gcc-14/changes.html | 11 +++
> > > 1 file changed, 11 insertion
Tested x86_64-linux. Pushed to trunk.
-- >8 --
If we update the list of "active" symbols versions now, rather than when
adding a new symbol version, we will notice if new symbols get added to
the wrong version (as in PR 114692).
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_abi.cc:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/backward/auto_ptr.h: Use https for URL in comment.
* include/bits/basic_ios.h: Likewise.
* include/std/iostream: Likewise.
---
libstdc++-v3/include/backward/auto_ptr.h | 2 +-
libstdc++-v3/i
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Implement the changes from P2944R3 which add constraints to the
comparison operators of std::pair, std::tuple, and std::variant.
The paper also changes std::optional, but we already constrain its
comparisons using SFINAE on the return type. However,
On Wed, 10 Apr 2024 at 09:51, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> This is just a minor clean-up and could wait for stage 1.
Pushed now.
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/std/variant (_VARIANT_RELATION_FUNCT
I don't think using a macro for these really saves us much, we can do
this to avoid duplication instead. And now it's not a big, multi-line
macro that's a pain to edit.
Any objections?
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/variant (__detail::__variant::__c
Tested x86_64-linux. Pushed to trunk. gcc-14 backport to follow.
-- >8 --
std::shared_ptr isn't declared for freestanding, so guard uses of it
with #if _GLIBCXX_HOSTED in .
libstdc++-v3/ChangeLog:
PR libstdc++/114866
* include/bits/out_ptr.h [!_GLIBCXX_HOSTED]: Don't refer to
Tested x86_64-linux. Pushed to trunk. gcc-14 backport to follow.
-- >8 --
Eddie Nolan reported to me that _Unicode_view was not correctly
implementing the substitution of ill-formed subsequences with U+FFFD,
due to failing to increment the counter when the iterator reaches the
end of the sequence
Do we want this change for RISC-V, to fix PR113578?
I haven't tested it on RISC-V, only on x86_64-linux (where it doesn't do
anything).
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/113578
* include/std/ostream (operator<<(basic_ostream&, float)):
Restore signbit after c
Tested x86_64-linux. This seems "obviously correct", and I'd like to
push it. The current code definitely has a data race, i.e. undefined
behaviour.
-- >8 --
The lazy caching in std::basic_ios::fill() updates a mutable member
without synchronization, which can cause a data race if two threads bot
Tested x86_64-linux. This one is less "obviously correct", as calling
the single-character narrow(char, char) overload no longer lazily
populates individual characters in the cache (because doing that is
racy). And the single-character widen(char) no longer calls
_M_wide_init() to populate the whol
On Tue, 7 May 2024 at 14:57, Jeff Law wrote:
>
>
>
> On 5/7/24 7:49 AM, Jonathan Wakely wrote:
> > Do we want this change for RISC-V, to fix PR113578?
> >
> > I haven't tested it on RISC-V, only on x86_64-linux (where it doesn't do
> > anything).
&
On Tue, 7 May 2024 at 15:06, Jonathan Wakely wrote:
>
> On Tue, 7 May 2024 at 14:57, Jeff Law wrote:
> >
> >
> >
> > On 5/7/24 7:49 AM, Jonathan Wakely wrote:
> > > Do we want this change for RISC-V, to fix PR113578?
> > >
> > > I haven'
On Tue, 7 May 2024 at 17:33, Jeff Law wrote:
>
>
>
> On 5/7/24 9:36 AM, Andreas Schwab wrote:
> > On Mai 07 2024, Jonathan Wakely wrote:
> >
> >> +#ifdef __riscv
> >> +return _M_insert(__builtin_copysign((double)__f,
> >> +
On Tue, 7 May 2024 at 17:39, Jonathan Wakely wrote:
>
> On Tue, 7 May 2024 at 17:33, Jeff Law wrote:
> >
> >
> >
> > On 5/7/24 9:36 AM, Andreas Schwab wrote:
> > > On Mai 07 2024, Jonathan Wakely wrote:
> > >
> > >> +#ifdef __riscv
On Wed, 8 May 2024 at 11:33, Andrew Waterman wrote:
>
> On Tue, May 7, 2024 at 9:46 AM Jonathan Wakely wrote:
> >
> > On Tue, 7 May 2024 at 17:39, Jonathan Wakely wrote:
> > >
> > > On Tue, 7 May 2024 at 17:33, Jeff Law wrote:
> > > >
> >
On Tue, 7 May 2024 at 15:11, Jonathan Wakely wrote:
>
> On Tue, 7 May 2024 at 15:06, Jonathan Wakely wrote:
> >
> > On Tue, 7 May 2024 at 14:57, Jeff Law wrote:
> > >
> > >
> > >
> > > On 5/7/24 7:49 AM, Jonathan Wakely wrote:
>
On Mon, 13 May 2024, 07:30 Iain Sandoe, wrote:
>
>
> > On 13 May 2024, at 06:06, François Dumont wrote:
> >
> >
> > On 07/05/2024 18:15, Iain Sandoe wrote:
> >> Hi François
> >>
> >>> On 4 May 2024, at 22:11, François Dumont wrote:
> >>>
> >>> Here is the list of patches to restore gnu versione
1201 - 1300 of 10092 matches
Mail list logo
