On 23/05/24 06:55 +0200, François Dumont wrote:
As explained in this email:
https://gcc.gnu.org/pipermail/libstdc++/2024-April/058552.html
I experimented -Wfree-nonheap-object because of my enhancements on algos.
So here is a patch to extend the usage of the _Guard type to other
parts of
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This fixes a bug in locale::combine where we fail to meet the standard's
requirement that the result is unnamed. It also implements two library
issues related to the names of combined locales (2295 and 3676).
libstdc++-v3/ChangeLog:
PR
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/locale_classes.h (locale::combine)
(locale::name, locale::operator==, locale::operator!=)
(locale::operator(), locale::classic): Add nodiscard
attribute.
*
Tested x86_64-linux. Pushed to trunk. Backport needed too.
-- >8 --
Clang does not enable -fsized-deallocation by default, which means it
can't compile our and headers.
Make the __cpp_lib_generator macro depend on the compiler-defined
__cpp_sized_deallocation macro, and change to use unsized
Pushed to trunk. Backport to gcc-14 to follow.
On Fri, 17 May 2024 at 14:45, Jonathan Wakely wrote:
>
> Does anybody see any issue with the drive-by fixes to constraint
> std::formatter to only work for pointers and integers (since
> we don't know how to format pthread_t if it's
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Ensure that the result of comparing the variant alternatives is
converted to bool immediately rather than copied.
libstdc++-v3/ChangeLog:
PR libstdc++/115145
* include/std/variant (operator==, operator!=, operator<)
Tested x86_64-linux. Committed as obvious.
I'll backport it too.
-- >8 --
The correct dialect for std::to_address is cxx20 not cxx11.
gcc/cp/ChangeLog:
PR libstdc++/107800
* cxxapi-data.csv : Change dialect to cxx20.
* std-name-hint.gperf: Regenerate.
*
On Sun, 24 Mar 2024 at 21:34, Björn Schäpers wrote:
>
> From: Björn Schäpers
>
> This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
> I don't know if I picked the right way to do it.
>
> When acceptable I think the declaration should be moved into
> ops-common.h, since then we
Does anybody see any issue with the drive-by fixes to constraint
std::formatter to only work for pointers and integers (since
we don't know how to format pthread_t if it's an arbitrary struct, for
example), and to cast pointers to const void* for output (because if
pthread_t is char* then writing
Tested x86_64-linux. Pushed to trunk, gcc-14 backport to follow.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/115119
* include/bits/unicode.h (_Iterator::operator++(int)): Fix typo
in increment expression.
* testsuite/ext/unicode/grapheme_view.cc: Check
On Thu, 16 May 2024 at 19:52, Björn Schäpers wrote:
>
> From: Björn Schäpers
>
> libstdc++-v3/Changelog
>
> * acinclude.m4 (GLIBCXX_ENABLE_BACKTACE): Add check for
> tlhelp32.h, matching libbacktrace.
> * configure: Regenerate.
> * config.h.in: Regenerate.
This
Pushed to trunk.
On Tue, 7 May 2024 at 15:04, Jonathan Wakely wrote:
>
> 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 cach
On Tue, 7 May 2024 at 14:51, Ville Voutilainen
wrote:
>
> On Tue, 7 May 2024 at 16:47, Jonathan Wakely wrote:
> >
> > 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
> &g
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Prior to C++20 this enum type doesn't have a fixed underlying type,
which means it can be modified by -fshort-enums, which then means the
HLE bits are outside the range of valid values for the type.
As it has a fixed type of int in C++20 and later,
Tested x86_64-linux, x86_64-w64-mingw32. Pushed to trunk. Backport to
gcc-14 to follow.
-- >8 --
Do not use dynamic_cast unconditionally, in case libstdc++ is built with
-fno-rtti.
libstdc++-v3/ChangeLog:
PR libstdc++/115015
* src/c++23/print.cc (__open_terminal(streambuf*))
Pushed to trunk.
-- >8 --
This section can be misread to say that shrink_to_fit is available from
GCC 3.4, but it was added later.
libstdc++-v3/ChangeLog:
* doc/xml/manual/strings.xml: Clarify that GCC 4.5 added
std::string::shrink_to_fit.
*
Tested x86_64-linux. Pushed to trunk, gcc14 and gcc-13.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/115063
* include/std/stacktrace (basic_stacktrace::max_size): Fix typo
in reference to _M_alloc member.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc:
On Tue, 7 May 2024 at 14:42, Matthias Kretz wrote:
>
> Tested on x86_64-linux-gnu and aarch64-linux-gnu and with Clang 18 on x86_64-
> linux-gnu.
>
> OK for trunk and backport(s)?
OK for all.
>
> -- 8<
>
> Signed-off-by: Matthias Kretz
>
>
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
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 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 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 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 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't te
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).
> >
&
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
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
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
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
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
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
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
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.
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 +-
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:
*
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
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 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
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 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.
> > >
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
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.
>
> Sinc
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"
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
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:
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.
>
> J
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 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
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
*
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:
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:
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:
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
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.
---
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.
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
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.
---
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
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 latte
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
strict-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 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
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
>
>
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
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
@@
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
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
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
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 now .
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 do th
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
duplicating those symbols.
-- >8 --
Jonathan Wakely (2):
l
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
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
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.
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
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.
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<
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.
>
>
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 ++--
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
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, 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
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
>
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_t
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 less work
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
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
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 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
>
I'm considering this late patch for gcc-14 to workaround an issue
discovered by a recent Clang change.
I'm not yet sure if Clang is right to require these symbols. It's not
really clear, because always_inline isn't part of the standard so it's
not clear how it should interact with explicit
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 documentation.
>
> Ok for trunk?
OK, thanks.
>
> 2024-04-11 Jakub Jelinek
>
> *
On Thu, 11 Apr 2024 at 15:46, Andreas Schwab wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote:
> >>
On Thu, 11 Apr 2024 at 15:36, Andreas Schwab wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj
> > 2024-04-11 15:55:49.982325397 +0200
> > +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
On Thu, 11 Apr 2024 at 15:18, Jakub Jelinek wrote:
>
> Hi!
>
> While the previous patch was regeneration from 13.2 release (with hand
> edits for arches I don't have libraries for but which are still well
> maintained), thius one is regeneration from the trunk (this time for
> hand edits
On Thu, 11 Apr 2024 at 15:13, Jonathan Wakely wrote:
>
> On Thu, 11 Apr 2024 at 15:12, Andreas Schwab wrote:
> >
> > On Apr 11 2024, Jakub Jelinek wrote:
> >
> > > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj
> > &g
On Thu, 11 Apr 2024 at 15:12, Andreas Schwab wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj
> > 2023-05-04 09:42:43.277271065 +0200
> > +++ libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> >
On Thu, 11 Apr 2024 at 15:07, Jakub Jelinek wrote:
>
> On Thu, Apr 11, 2024 at 02:59:05PM +0100, Jonathan Wakely wrote:
> > I think we also want the same change for i386.
> >
> > -- >8 --
> >
> > libstdc++-v3/ChangeLog:
> >
> > *
I think we also want the same change for i386.
-- >8 --
libstdc++-v3/ChangeLog:
* config/abi/post/i386-linux-gnu/baseline_symbols.txt:
Regenerate.
---
.../config/abi/post/i386-linux-gnu/baseline_symbols.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Thu, 11 Apr 2024 at 14:52, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch regenerates the ABI files for 13 branch (I've only changed
> the Linux files which were updated in r13-7289, all but m68k, riscv64 and
> powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited).
>
I plan to push this shortly, to fix the P1 ABI regression that Jakub
reported earlier today.
This will trigger 'make check-abi' failures for CI testers, because the
baseline_sybols.txt wasn't regenerated for gcc 13.2.0 and so there are
two symbols present in GLIBCXX_3.4.32 which are not in the
1 - 100 of 9582 matches
Mail list logo
