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
https://gcc.gnu.org/g:8d80e3c5a641556e32fdf3637f08a0648f5aaab3
commit r14-10129-g8d80e3c5a641556e32fdf3637f08a0648f5aaab3
Author: Jonathan Wakely
Date: Thu Apr 25 14:02:36 2024 +0100
libstdc++: Rename man pages to use '::' instead of '_'
The Doxygen-generated man pages for some
https://gcc.gnu.org/g:6391cf8bd9c1d71805d9aba00b25fdaa550f39c8
commit r14-10128-g6391cf8bd9c1d71805d9aba00b25fdaa550f39c8
Author: Jonathan Wakely
Date: Thu Apr 25 13:52:00 2024 +0100
libstdc++: Fix typo in Doxygen comment
libstdc++-v3/ChangeLog:
* include/std
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
https://gcc.gnu.org/g:c9cc1c850c6d084752207b6cf247a0a48bae0d52
commit r14-10127-gc9cc1c850c6d084752207b6cf247a0a48bae0d52
Author: Jonathan Wakely
Date: Thu Apr 25 13:24:56 2024 +0100
libstdc++: Fix run_doxygen for Doxygen 1.10 man page format
Doxygen switched from \fC to \fR
https://gcc.gnu.org/g:d5b2c6b32c97e1fd03214771d35f8d67b0d72940
commit r14-10126-gd5b2c6b32c97e1fd03214771d35f8d67b0d72940
Author: Jonathan Wakely
Date: Thu Apr 25 13:09:27 2024 +0100
libstdc++: Update Doxygen config for new headers
libstdc++-v3/ChangeLog:
* doc
https://gcc.gnu.org/g:f3021e6e0600bedd69567b21d2a06b0b9854c533
commit r14-10125-gf3021e6e0600bedd69567b21d2a06b0b9854c533
Author: Jonathan Wakely
Date: Thu Apr 25 13:04:43 2024 +0100
libstdc++: Add comment to #include in
It's not obvious why needs so add a
comment
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
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
https://gcc.gnu.org/g:9c49ab21b5df71cf5e397dfe0f7b97765300ec45
commit r13-8648-g9c49ab21b5df71cf5e397dfe0f7b97765300ec45
Author: Jonathan Wakely
Date: Fri Feb 2 12:07:09 2024 +
libstdc++: Fix libstdc++exp.a so it really does contain Filesystem TS
symbols
In r14-3812
On Thu, 25 Apr 2024 at 09:54, Jonathan Wakely wrote:
>
> On Thu, 25 Apr 2024 at 07:47, Gejoe Daniel via Gcc wrote:
> >
> > Hi team,
> > The following is my query posted but would need more inputs :
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
> >
&g
On Thu, 25 Apr 2024 at 07:47, Gejoe Daniel via Gcc wrote:
>
> Hi team,
> The following is my query posted but would need more inputs :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
>
> The gcov tool which was working so far seems to fail with our latest branch
> where gcc is 11.4.0 and
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, 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: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
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
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 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
https://gcc.gnu.org/g:d86472a6f041ccf3d1be0cf6bb15d1e0ad8f6dbe
commit r14-10044-gd86472a6f041ccf3d1be0cf6bb15d1e0ad8f6dbe
Author: Jonathan Wakely
Date: Fri Apr 19 17:42:04 2024 +0100
libstdc++: Simplify constraints on <=> for std::reference_wrapper
Instead of constr
https://gcc.gnu.org/g:eed7fb1b2fe72150cd6af10dd3b8f7fc4f0a4da1
commit r14-10043-geed7fb1b2fe72150cd6af10dd3b8f7fc4f0a4da1
Author: Jonathan Wakely
Date: Thu Apr 18 12:14:41 2024 +0100
libstdc++: Support link chains in std::chrono::tzdb::locate_zone [PR114770]
Since 2022 the TZif
On Thu, 18 Apr 2024 at 07:06, Thomas Koenig via Gcc wrote:
>
> Am 18.04.24 um 01:27 schrieb Mark Wielaard:
> > We also should make sure that all generated files (either in git or in
> > the release/snapshot tar balls) can be reliably and reproducibly
> > regenerated. This also helps the
On Thu, 18 Apr 2024 at 07:06, Thomas Koenig via Gcc wrote:
>
> Am 18.04.24 um 01:27 schrieb Mark Wielaard:
> > We also should make sure that all generated files (either in git or in
> > the release/snapshot tar balls) can be reliably and reproducibly
> > regenerated. This also helps the
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 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 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
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
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
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
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.
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
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.
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.
https://gcc.gnu.org/g:7c2a9dbcc2c1cb1563774068c59d5e09edc59f06
commit r14-10008-g7c2a9dbcc2c1cb1563774068c59d5e09edc59f06
Author: Jonathan Wakely
Date: Thu Mar 21 23:09:14 2024 +
libstdc++: Implement "Printing blank lines with println" for C++23
This was recentl
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 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.
>
>
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 ++--
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 ++--
https://gcc.gnu.org/g:443748259d903b6f4d4557392fc788df93d63377
commit r14-9995-g443748259d903b6f4d4557392fc788df93d63377
Author: Jonathan Wakely
Date: Tue Apr 16 10:56:46 2024 +0100
libstdc++: Fix "extact" typos in comments
libstdc++-v3/ChangeLog:
* con
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: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 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: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
>
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: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 less work
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
https://gcc.gnu.org/g:0d58450659ade002666c1c3604c94cd8e0cc6b50
commit r14-9980-g0d58450659ade002666c1c3604c94cd8e0cc6b50
Author: Jonathan Wakely
Date: Fri Mar 22 13:20:21 2024 +
libstdc++: Add std::reference_wrapper comparison operators for C++26
This C++26 change was just
https://gcc.gnu.org/g:b6239715c10193e73e66fe1671418459afd4a9aa
commit r14-9981-gb6239715c10193e73e66fe1671418459afd4a9aa
Author: Jonathan Wakely
Date: Mon Apr 15 16:38:08 2024 +0100
libstdc++: Update libstdc++.so versioning history for 14.1.0 release
We can replace &quo
https://gcc.gnu.org/g:2a0c083558b4ac6609692294df7a388cf4468711
commit r14-9979-g2a0c083558b4ac6609692294df7a388cf4468711
Author: Jonathan Wakely
Date: Mon Jan 15 14:47:52 2024 +
libstdc++: Heterogeneous std::pair comparisons [PR113386]
I'm only treating this as a DR for C++20
https://gcc.gnu.org/g:2d694414ada8e3b58f504c1b175d31088529632e
commit r14-9978-g2d694414ada8e3b58f504c1b175d31088529632e
Author: Jonathan Wakely
Date: Thu Apr 4 10:33:33 2024 +0100
libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]
A negative delim value
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 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 Sun, 14 Apr 2024, 13:12 Martin Guy via cfarm-users, <
cfarm-users@lists.tetaneutral.net> wrote:
> Il 14/04/24 13:46, Jonathan Wakely via cfarm-users ha scritto:
> > On Sun, 14 Apr 2024, 12:15 Baptiste Jonglez via cfarm-users,
> > wrote:
> >
> > On 09-04-
On Sun, 14 Apr 2024 at 20:45, Jonathan Wakely wrote:
>
> On Sun, 14 Apr 2024, 14:05 Bruno Haible, wrote:
> >
> > Jonathan Wakely wrote:
> > > > It would not be straightforward to track all SSH access on the farm,
> > > > both
> > > > for pr
On Sun, 14 Apr 2024, 14:05 Bruno Haible, wrote:
>
> Jonathan Wakely wrote:
> > > It would not be straightforward to track all SSH access on the farm, both
> > > for privacy reasons and technical reasons (the farm has very diverse
> > > systems, and some people
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
>
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
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: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: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: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: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
https://gcc.gnu.org/g:1defe743aeb19532f6d6f4cab37e10f11467abd8
commit r14-9917-g1defe743aeb19532f6d6f4cab37e10f11467abd8
Author: Jonathan Wakely
Date: Thu Apr 11 12:28:25 2024 +0100
libstdc++: Export std::__basic_file::native_handle as GLIBCXX_3.4.33
[PR114692]
I added this new
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: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: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:
> >
> > *
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
301 - 400 of 14961 matches
Mail list logo
