On 21/04/22 04:31 -0700, Kaz Kylheku wrote:
libcpp/ChangeLog
2022-04-21 Kaz Kylheku
This change introduces a pair of related macros
__EXP_COUNTER__ and __UEXP_COUNTER__. These macros access
integer values which enumerate macro expansions.
They can be used for
On 18/03/24 07:30 +, Jonathan Wakely wrote:
On 21/04/22 04:31 -0700, Kaz Kylheku wrote:
libcpp/ChangeLog
2022-04-21 Kaz Kylheku
This change introduces a pair of related macros
__EXP_COUNTER__ and __UEXP_COUNTER__. These macros access
integer values which
On Sun, 17 Mar 2024 at 18:14, François Dumont wrote:
>
> I was a little bit too confident below. After review of all _M_singular
> usages I found another necessary fix.
>
> After this one for sure we will be able to define
> __cpp_lib_null_iterators even in Debug mode.
>
> libstdc++: Fix N334
On Sun, 17 Mar 2024 at 16:52, François Dumont wrote:
>
>
> >
> > OK for trunk, thanks!
> >
> > I think this is OK to backport to 13 too.
> >
> > Maybe after this we can define the __cpp_lib_null_itetators macro for
> > debug mode?
> >
> After this fix of local_iterator I think we can indeed.
>
> I
On Mon, 18 Mar 2024 at 16:46, Kaz Kylheku wrote:
>
> On 2024-03-18 00:30, Jonathan Wakely wrote:
> >>+@item __EXP_COUNTER__
> >>+This macro's name means "(macro) expansion counter".
> >>+Outside of macro replacement sequences, it expands to the int
On Mon, 18 Mar 2024 at 21:38, François Dumont wrote:
>
> Both committed now.
>
> Just to confirm, those 2 last patches should be backported to gcc-13
> branch, right ?
Yes please.
>
> I might have a try to update version.h but if you want to do it before
> don't hesitate.
You'll need to have 'au
On Tue, 19 Mar 2024 at 10:55, Iain Sandoe wrote:
>
> Note that Windows-based platforms do something quite similar, but always
> use the same (x.exe) filename. I wonder, in passing, if that makes a
> vulnerability in parallel testing (I chose to avoid the possibility for
> Darwin).
Parallel testin
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 to follow.
-- >8 --
This doesn't cause a problem with GCC, but Clang correctly diagnoses a
bug in the code. The objects in the allocated storage need to begin
their lifetime before we start using them.
This change uses the allocator's cons
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This has been reported upstream.
libstdc++-v3/ChangeLog:
* testsuite/util/pstl/test_utils.h: Fix typos in comments.
---
libstdc++-v3/testsuite/util/pstl/test_utils.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
dif
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These scripts both print "generated by $file, do not edit" header but
one of them prints the wrong filename. Use the built-in __file__
attribute to ensure it's correct.
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Fix header
Pushed to trunk.
-- >8 --
There are several more sub-directories below 'src' now, with lots more
conveience libraries. Document them all as of GCC 14.
Also document how to regenerate the generated headers under include/bits
and how to update the tzdata.zi file.
libstdc++-v3/ChangeLog:
Tested x86_64-linux. Pushed to trunk.
I've taken the liberty of assuming that the change to
gcc/doc/install.texi is sufficiently "obviously true" to not require
separate approval.
-- >8 --
This is a generated header but regenerating it requires the manual step
of running 'make -C include update-
On Tue, 19 Mar 2024 at 09:31, Jonathan Wakely wrote:
>
> On Mon, 18 Mar 2024 at 21:38, François Dumont wrote:
> >
> > Both committed now.
> >
> > Just to confirm, those 2 last patches should be backported to gcc-13
> > branch, right ?
>
> Yes plea
Does anybody see any issues with making this change?
The __cpp_constexpr_dynamic_alloc macro is defined with -std=c++2a
since Clang 10.0.0 so this won't result in std::construct_at
disappearing by anybody using libstdc++ with Clang.
Tested x86_64-linux and aarch64-linux. Basic smoke tests checked
This fixes the problem in the PR, which is revealed by the new
concept-based constraints on std::pair constructors in C++20 mode. That
makes this a C++20 regression, as the PR's example compiles with C++17.
We need something similar for std::basic_string too, which I'll do
later.
Any comments?
T
Tested x86_64-linux. Pushed to trunk.
Not a regression, but worth backporting.
-- >8 --
The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is
unsigned and 4 * _M_t wraps to zero. The third operand has type double,
so do the second multiplication first, so that we aren't multiply
On Wed, 20 Mar 2024 at 05:59, François Dumont wrote:
>
> Thanks to you doc:
>
> libstdc++: [_GLIBCXX_DEBUG] Define __[glibcxx,cpp_lib]_null_iterators
>
> _GLIBCXX_DEBUG has now fully N3344 compliant iterator checks, we
> can define
> __glibcxx_null_iterators and __cpp_lib_null_iterat
ators): Likewise.
>
> François
>
>
> On 20/03/2024 10:02, Jonathan Wakely wrote:
> > On Wed, 20 Mar 2024 at 05:59, François Dumont wrote:
> >> Thanks to you doc:
> >>
> >> libstdc++: [_GLIBCXX_DEBUG] Define __[glibcxx,cpp_lib]_null_iterators
>
Tested aarch64-linux. Pushed to trunk.
-- >8 --
Replace std::result_of with std::invoke_result, as specified in the
standard since C++17, to avoid deprecated warnings for std::result_of.
We don't have __invoke_result_t in C++11 mode, so add it as an alias
template for __invoke_result<>::type (wh
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The preprocessor checks for __cplusplus in should
use the appropriate feature test macros instead of __cplusplus, namely
__glibcxx_raw_memory_algorithms and __cpp_constexpr_dynamic_alloc.
For the latter, we want to check the compiler macro not the
Tested aarch64-linux. Pushed to trunk.
-- >8 --
Put the C++23 generator and tuple_like ones before the C++26 ones.
libstdc++-v3/ChangeLog:
* include/bits/version.def (generator, tuple_like): Move earlier
in the file.
* include/bits/version.h: Regenerate.
---
libstdc++-v
Pushed to trunk. Backport to gcc-13 needed too, as the changes to use
concepts for std::pair constructors are on that branch.
On Tue, 19 Mar 2024 at 15:59, Jonathan Wakely wrote:
>
> This fixes the problem in the PR, which is revealed by the new
> concept-based constraints on
Tested aarch64-linux. Pushed to trunk.
This should be backported to all branches, as the failure to destroy the
allocators in the re-inserted nodes results in potential resource leaks.
-- >8 --
The allocator objects in container node handles were not being destroyed
after the node was re-inserte
And this replaces an existing custom dg-require- directive with a use of
the new one that checks for a standard feature test macro. I didn't see
any other existing dg-require-xxx directives that can be replaced like
this.
-- >8 --
Remove the dejagnu code for checking whether std::stacktrace is su
Thoughts? There are only a few uses for this presently, but I can see it
being useful often in future. The library exposes which features it
supports in a standardized way, so we can use those in tests to skip
tests for features that aren't available on all targets.
The obvious downside is that it
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The difference between __type_identity_t and std::type_identity_t is
observable, as demonstrated in the PR. Nobody in LWG seems to think this
an example we should really care about, but it seems easy and harmless
to change this.
libstdc++-v3/Change
Tested aarch64-linux. Pushed to trunk.
-- >8 --
We already have __is_in_place_type_v for in_place_type_t so adding an
equivalent for in_place_index_t allows us avoid a class template
instantiation for the __not_in_place_tag constraint on the most
commonly-used std::variant::variant(T&&) construct
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This was just approved in Tokyo as a DR for C++23. It doesn't affect us
yet, because we don't implement the __cpp_lib_format_ranges features. We
can add the disabled specializations and add a testcase now though.
libstdc++-v3/ChangeLog:
*
Tested aarch64-linux. Puhed to trunk.
-- >8 --
This was a copy & paste error.
libstdc++-v3/ChangeLog:
* testsuite/std/text_encoding/requirements.cc: #undef the
correct macro.
---
libstdc++-v3/testsuite/std/text_encoding/requirements.cc | 2 +-
1 file changed, 1 insertion(+), 1
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović wrote:
>
> Per the standard, the return type of a generators ranges iterator op*
> should be the reference type rather than the yielded type.
>
> The yielded type was used here by mistake.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/generator
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/generator: Fix _V badname.
OK for trunk, thanks.
> ---
> libstdc++-v3/include/std/generator | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/lib
Pushed to trunk.
On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely wrote:
>
> And this replaces an existing custom dg-require- directive with a use of
> the new one that checks for a standard feature test macro. I didn't see
> any other existing dg-require-xxx directives that can
Pushed to trunk.
On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely wrote:
>
> Thoughts? There are only a few uses for this presently, but I can see it
> being useful often in future. The library exposes which features it
> supports in a standardized way, so we can use those in tests to
On Wed, 27 Mar 2024 at 08:51, Matthias Kretz wrote:
>
> This is broken on GCC 13 and 14 (https://compiler-explorer.com/z/GPKGPGs6T)
>
> Tested on x86_64-linux-gnu.
>
> OK for trunk and 13?
OK for both, thanks.
>
> --- 8< -
>
> This resolves failures in th
On Fri, 8 Mar 2024 at 09:58, Matthias Kretz wrote:
>
> Hi,
>
> I applied and did extended testing on x86_64 (no regressions) and aarch64
> using qemu testing SVE 256, 512, and 1024. Looks good!
>
> While going through the applied patch I noticed a few style issues that I
> simply turned into a patc
On Wed, 27 Mar 2024 at 12:13, Richard Sandiford
wrote:
>
> Matthias Kretz writes:
> > On Wednesday, 27 March 2024 11:07:14 CET Richard Sandiford wrote:
> >> I'm still worried about:
> >>
> >> #if _GLIBCXX_SIMD_HAVE_SVE
> >> constexpr inline int __sve_vectorized_size_bytes = __ARM_FEATURE_SVE_
On Wed, 27 Mar 2024 at 12:48, Matthias Kretz wrote:
>
> And one more to fix follow-up / remaining failures. Tested on x86_64-linux-
> gnu.
>
> OK for trunk and 13?
OK for both, thanks.
>
> 8< --
>
> This resolves further failures (-Wreturn-type warnings) and test
> fail
On Mon, 1 Apr 2024 at 23:16, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
This is a layout change for some specializations of slide_view, but
better to do that now than change it between gcc 14 and 15.
OK for trunk.
>
> -- >8 --
>
> Currently __maybe_pre
On Tue, 2 Apr 2024 at 08:47, Jakub Jelinek wrote:
>
> Hi!
>
> Like in r12-7519-g027e30414492d50feb2854aff38227b14300dc4b, I've done
> git grep -v 'long long\|optab optab\|template template\|double double' | grep
> ' \([a-zA-Z]\+\) \1 '
>
> This is just part of the changes, mostly for non-gcc direc
On Tue, 2 Apr 2024 at 18:00, Pilar Latiesa wrote:
>
> Just out of curiosity: would this also work?
>
> template
> struct _Absent {};
>
> template
> using __maybe_present_t = __conditional_t<_Present, _Tp, _Absent<_Tp, _Disc>>;
>
> That would avoid having to type 0, 1, ... manually.
This is subject
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/114519
* include/bits/unicode.h (_Utf8_view): Guard with check for
char8_t being enabled.
(__literal_encoding_is_unicode): Guard use of char8_t with check
for it being enab
Tested x86_64-linux. Pushed to trunk. Backports likely to follow.
-- >8 --
This is a workaround for a possible compiler bug that causes constraint
recursion in the operator<=>(const optional&, const U&) overload.
libstdc++-v3/ChangeLog:
PR libstdc++/104606
* include/std/optional
I would appreciate more eyes on this to confirm my conclusions about
negative int_type values, and the proposed fix, make sense.
Tested x86_64-linux.
-- >8 --
A negative value for the delim value passed to std::istream::ignore can
never match any character in the stream, because the comparison i
On Thu, 4 Apr 2024 at 16:40, Iain Sandoe wrote:
>
>
>
> > On 4 Apr 2024, at 16:29, Jonathan Wakely wrote:
> >
> > I would appreciate more eyes on this to confirm my conclusions about
> > negative int_type values, and the proposed fix, make sense.
> >
On Thu, 4 Apr 2024 at 17:29, Ulrich Drepper wrote:
>
> On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely wrote:
> > I would appreciate more eyes on this to confirm my conclusions about
> > negative int_type values, and the proposed fix, make sense.
>
> The way something
On Thu, 4 Apr 2024 at 17:33, Jonathan Wakely wrote:
>
> On Thu, 4 Apr 2024 at 17:29, Ulrich Drepper wrote:
> >
> > On Thu, Apr 4, 2024 at 5:29 PM Jonathan Wakely wrote:
> > > I would appreciate more eyes on this to confirm my conclusions about
> > > negati
On Thu, 4 Apr 2024 at 17:30, Jonathan Wakely wrote:
>
> On Thu, 4 Apr 2024 at 16:40, Iain Sandoe wrote:
> >
> >
> >
> > > On 4 Apr 2024, at 16:29, Jonathan Wakely wrote:
> > >
> > > I would appreciate more eyes on this to confirm my conclu
On Thu, 4 Apr 2024 at 17:55, Jonathan Wakely wrote:
>
> On Thu, 4 Apr 2024 at 17:30, Jonathan Wakely wrote:
> Ulrich's suggestion is to allow the buggy user code to Just Work (for
> all cases except (char)-1 on a platform where char is signed). That is
> maybe the least surp
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
We don't need separate tests for the C++17 and C++20 cases, we can just
have one test that uses __cpp_char8_t to adjust whether it tests char8_t
or not. This means the C++20 one doesn't fail if -fno-char8_t is used.
libstdc++-v3/Ch
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
Adjust expected errors or skip tests as UNSUPPORTED if -fno-char8_t is
used in the test flags.
libstdc++-v3/ChangeLog:
* testsuite/20_util/integer_comparisons/equal_neg.cc: Use
no-opts selector for errors that depe
I recently disabled _Utf8_view for -fno-char8_t, but we can just make it
use char instead of char8_t. The existing uses of it in the library are
unaffected.
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
Instead of just omitting the definition of __unicode::_Utf8_view when
char
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_type::find to match 'a' but then the eq_int_type
comparison will fail because (int)'a' != (int)('a' + 256).
This version of the p
Tested x86_64-linux. Richi confirmed this fixes rx-elf bootstrap.
Pushed to trunk.
-- >8 --
If the faster std::from_chars is not supported for floating-point types
then just extract the value from the stream using operator>>.
This fixes a build error for targets where __cpp_lib_to_chars is not
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
and only requires changes to operator== and operator<=>. To do this for
older standards would require changes to the six relat
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== and operator<=> overloads to std::reference_wrapper.
The operator<=> overloads in the paper cause compilation errors for any
type w
Tested x86_64-linux.
This is just a minor clean-up and could wait for stage 1.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/variant (_VARIANT_RELATION_FUNCTION_TEMPLATE):
Simplify.
---
libstdc++-v3/include/std/variant | 20 +---
1 file changed, 9 insertions(+)
Tested x86_64-linux.
Since this only affects C++20 and later (except for adding [[nodiscard]]
to relational ops) it seems OK for trunk now.
-- >8 --
Implement the changes from P2944R3 which add constraints to the
comparison operators of std::pair, std::tuple, and std::variant.
The paper also ch
I think this is considerably nicer than the macro version, but it can
definitely wait for stage 1.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/variant (__detail::__variant::__compare): New
function template.
(operator==, operator!=, operator<, operator>, operator<=)
Tested x86_64-linux and x86_64-freebsd14. Pushed to trunk.
-- >8 --
Although POSIX requires ELOOP, FreeBSD documents that openat with
O_NOFOLLOW returns EMLINK if the last component of a filename is a
symbolic link. Check for EMLINK as well as ELOOP, so that the TOCTTOU
mitigation in remove_all
Tested x86_64-linux and x86_64-freebsd14. Pushed to trunk.
-- >8 --
The std/time/year_month_day/io.cc test assumes that %x in the fr_FR
locale is %d/%m/%Y but on FreeBSD it is %d.%m.%Y instead. Make the test
PASS for either format.
Similarly, 27_io/manipulators/extended/get_time/char/2.cc expect
On Thu, 25 Jan 2024 at 15:54, Christophe Lyon
wrote:
>
> On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote:
> >
> > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> > >
> > > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
>
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 bas
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).
> We've
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 a/libstdc++-
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: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
> > 2
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: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 everywhere
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:46, Andreas Schwab wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote:
> >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3
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
>
> * doc/xml/ma
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 instant
On Wed, 31 Jan 2024 at 19:41, Patrick Palka wrote:
>
> On Wed, 31 Jan 2024, Patrick Palka wrote:
>
> > On Wed, 24 Jan 2024, Patrick Palka wrote:
> > >
> > > In v2:
> > >
> > > * Named the template parameters of the forward declaration of pair.
> > > * Added dangling checks for the new tuple and pa
d::forward<>
> calls when
> done several times on the same arguments.
>
> Ok to commit ?
>
> François
>
>
> On 31/01/2024 14:11, redi at gcc dot gnu.org wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
>
> Jonathan Wakely changed:
On Tue, 30 Jan 2024 at 21:35, Jonathan Wakely wrote:
>
> On 30/01/24 15:02 +, Jonathan Wakely wrote:
> >That way other subdirectories could add their own extra generated files to
> >it.
>
> Like so.
>
> mklog: Add lookup for generated files in specifi
On Wed, 31 Jan 2024 at 17:20, xndcn wrote:
>
> Thanks!
>
> > Why not just use -latomic unconditionally here?
> testsuites of libstdc++ seems to have some tricks to find and link
> libatomic.a by using "dg-add-options libatomic", which do nothing for
> x86 target. In previous email, we decide not t
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In C++20 it's deprecated for a [=] lambda capture to capture the 'this'
pointer. Using resize_and_overwrite with a lambda seems like overkill to
write three chars to the string anyway. Just resize the string and
overwrite the end of it directly.
lib
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We no longer hit a __builtin_unreachable() in these tests, so we need to
update the dg-error patterns to match _Error_formatter::_M_error().
We can also remove some dg-prune-output directives matching notes saying
"in 'constexpr' expansion" because
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These line markers are not needed, because searching
for a macro name works fine. Removing them means that small changes to
do not result in large diffs to
because of all the changed line numbers.
libstdc++-v3/ChangeLog:
* include/bits/v
I plan to push this to trunk soon.
CC HP for visibility of the change affecting cris-elf. In practice it
shouldn't make any difference to any sensible code. It only affects
C++20 mode (and later), and only changes the size of std::formatter
objects which are typically only created by the library h
I am undecided about pushing this PATCH 2/2 to trunk. PATCH 1/2 needs to
be done now due to the ABI impact on cris-elf. This one could wait for
stage 1. (HP, this one probably isn't of interest to you, but I don't
know how to tell git-send-email to only CC you on the first patch).
I'd like to do t
On Thu, 1 Feb 2024 at 17:08, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Thu, 1 Feb 2024 17:16:47 +0100
>
> > Not speaking for other platforms with default-packed layout
> > or where ABI structure layout alignment implies a change due
> > to PCC_BITFIELD_TYPE_MATTERS and th
On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
>
> On Feb 01 2024, Jonathan Wakely wrote:
>
> > This will result in an ABI change for targets that use 1-byte alignment
> > for all integral types, e.g. cris-elf.
>
> Or 2-byte alignment as on m68k.
Ah yes.
In fact
On Thu, 1 Feb 2024, 17:23 Jonathan Wakely, wrote:
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all integral
On Thu, 1 Feb 2024 at 17:22, Jonathan Wakely wrote:
>
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all i
I'm going to push this as obvious.
-- >8 --
gcc/ChangeLog:
* doc/extend.texi (Common Type Attributes): Fix typo in
description of hardbool.
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This overload of std::generator::promise_type::yield_value calls things
which might throw, so should not be noexcept. The noexcept was remove by
LWG 3894.
libstdc++-v3/ChangeLog:
* include/std/generator (promise_type::yield_value): Remove
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This should not be noexcept because its _M_syncbuf member has a
potentially-throwing move assignment operator. The noexcept was removed
by LWG 3867.
libstdc++-v3/ChangeLog:
* include/std/syncstream (basic_osyncstream::operator=): Remove
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This was changed by LWG 3857.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(R&&)): Remove
constraint that traits_type must be the same, as per LWG 3857.
* testsuite/21_strings/basic_string_view/cons/c
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The reverse_invoker utility for PSTL tests uses forwarding references for
all parameters, but some of those parameters get forwarded to move
constructors which then leave the objects in a moved-from state. When
the parameters are forwarded a second t
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This looks like a typo in the upstream test that causes a failure in
debug mode. It has been reported upstream.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc: Fix
compar
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v6::network): Define.
(network_v6::hosts): Finish implementing.
(network_v6::to_string): Do not concatenate std::string to
arbitrary std::basic_string s
Tested x86_64-linux. Pushed to releases/gcc-12 branch.
-- >8 --
This avoids a linker error with -fkeep-inline-functions when including
. We can't backport the fix from trunk because it adds an
export to the shared library. By marking the "missing" symbol
always_inline for C++20 mode we don't need
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended it to contain. We might be able to
avoid that increased on
On 02/02/24 12:14 +, Jonathan Wakely wrote:
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended
On Tue, 9 Jan 2024 at 12:44, Jonathan Wakely wrote:
>
> I was talking to Matthias Klose about enabling libstdc++_libbacktrace.a
> for Ubuntu's gcc package and I realised that it would be preferable if
> the gcc-13 branch had those libbacktrace symbols in libstdc++exp.a. I
>
These new headers should probably have the usual boilerplate at the top,
so make the Python scripts output it.
-- >8 --
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Add copyright and
license text to the output.
libstdc++-v3/ChangeLog:
* include/bits/text_
Tested x86_64-linux and powerpc-ibm-aix7.3.1.0. Pushed to trunk.
-- >8 --
This fails due to "u" being used in a system header.
FAIL: experimental/names.cc -std=gnu++17 (test for excess errors)
Excess errors:
/usr/include/sys/poll.h:77: error: expected unqualified-id before ';' token
/usr/includ
Teted x86_64-linux. Pushed to trunk.
-- >8 --
This makes the deduction guides for std::function and std::packaged_task
work for explicit object member functions, i.e. "deducing this", as per
LWG 3617.
libstdc++-v3/ChangeLog:
PR libstdc++/113335
* include/bits/std_function.h (__f
On 02/02/24 17:59 +0100, Florian Weimer wrote:
---
htdocs/gcc-14/porting_to.html | 465 ++
1 file changed, 465 insertions(+)
base-commit: 15056edbb60e24a6410d9b75f7386de28ea60bc1
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
i
401 - 500 of 9967 matches
Mail list logo
