https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120512
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #12 from Jonathan Wakely ---
These were working before, but fail after r16-1054
static_assert( __is_destructible(int&) );
static_assert( __is_destructible(int&&) );
static_assert( __is_destructible(int(&)[1]) );
static_assert( __is_
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Given this code to be compiled with -std=c++20:
struct A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #8 from Jonathan Wakely ---
And for this type but I haven't figured out why:
#include
static_assert( __is_destructible(std::error_category) );
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #7 from Jonathan Wakely ---
The new built-in seems wrong for function types:
static_assert( not __is_destructible(int()) );
static_assert( not __is_nothrow_destructible(int()) );
static_assert( not __is_trivially_destructible(int())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120481
--- Comment #6 from Jonathan Wakely ---
Ah yes, I thought hh_mm_ss handled times >24h differently, but I misremembered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120481
--- Comment #4 from Jonathan Wakely ---
"However, if a flag refers to a “time of day” (e.g., %H, %I, %p, etc.), then a
specialization of duration is interpreted as the time of day elapsed since
midnight."
I think it's fine for the output to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
--- Comment #6 from Jonathan Wakely ---
They often are, because users like to set them to mean "this is a blocker for
my work" and that has no bearing on how important it is for GCC. Only Priority
really matters for GCC, because that's documente
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
--- Comment #4 from Jonathan Wakely ---
I assume it's the type_build_dtor_call call that causes the problem, and
probably removing lines 238-245 in semantics.cc would fix it.
But Jason might know how to preserve the new check without the unwan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
--- Comment #3 from Jonathan Wakely ---
Importance isn't actually a field, it's the combination of Priority and
Severity. And severity is pretty much ignored, and priority is set according to
clear rules, so I see no harm in assuming that the RM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #6 from Jonathan Wakely ---
This regressed the following testcase:
struct X;
template
struct default_delete
{
void operator()(T*) { static_assert(sizeof(T), "type is not incomplete"); }
};
template>
struct unique_ptr
{
~unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #18 from Jonathan Wakely ---
for ac_prog in gm4 gnum4 m4
do
# Extract the first word of "$ac_prog", so it can be a program name with
args.
set dummy $ac_prog; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #11)
> So you can't use designated initializers with that type in C++.
This is true for *most* POSIX structs, because POSIX does not guarantee the
order of membe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #11 from Jonathan Wakely ---
.sa_handler is not a real member of the struct, it's a macro referring to a
nested member.
So you can't use designated initializers with that type in C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #8 from Jonathan Wakely ---
And "expected primary-expression before '.' token" because that syntax for
initializing a member of a subobject isn't valid at all in C++.
So you're not initializing 'sa.u' and that's why you get an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #9 from Jonathan Wakely ---
The correct way to do it is to provide an initializer for sa.u, and that
initializer can initialize .sa_handler i.e.
struct sa sa = {.sa_flags = 0, .u = {.sa_handler = 0} };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #7 from Jonathan Wakely ---
What isn't helpful about them? It tells you exactly what is wrong with the
code:
"either all initializer clauses should be designated or none of them should be"
GCC didn't decide this is an error, the C+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
--- Comment #17 from Jonathan Wakely ---
Using _S_do_try_acquire as the predicate for __atomic_wait_address is wrong,
because it can fail for two reasons: __old == 0, meaning we can't acquire the
semaphore and need to do an atomic wait, or becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #16 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 104928, which changed state.
Bug 104928 Summary: std::counting_semaphore on Linux can sleep forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 104928, which changed state.
Bug 104928 Summary: std::counting_semaphore on Linux can sleep forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115955
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Yes, this is a known limitation that will get fixed with the planned
> refactoring of atomic::wait.
The function that maps an address to a mutex has been mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 118395, which changed state.
Bug 118395 Summary: Constructor of std::barrier is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Jonathan Wakely changed:
What|Removed |Added
Summary|std::barrier accepts|[DR 3898] std::barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 118494, which changed state.
Bug 118494 Summary: std::counting_semaphore should work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118494
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98749
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118494
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jonathan Wakely changed:
What|Removed |Added
Summary|[12/13/14/15/16 Regression] |[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 110854, which changed state.
Bug 110854 Summary: constructor of std::counting_semaphore is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110854
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110854
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #15 from Jonathan Wakely ---
I suppose another way to resolve this would be to just mark that function
[[__gnu__::__always_inline__]].
That would require no config changes at all, we could do it unconditionally.
Or we could do:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107527
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108859
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2023-02-20 00:00:00 |2025-5-29
--- Comment #1 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|12.5|16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120458
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120467
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-05-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
--- Comment #6 from Jonathan Wakely ---
See also https://lists.gnu.org/archive/html/bug-make/2025-05/msg2.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120465
--- Comment #3 from Jonathan Wakely ---
(In reply to Eligor Kadaf from comment #0)
> However, it seems that in libstdc++ implementation of std::flat_map it's
> value_type is std::tuple.
No, the predicate is just called on the elements of a zip_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120465
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
--- Comment #5 from Jonathan Wakely ---
I did try this:
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -164,6 +164,21 @@ fs::canonical(const path& p, error_code& ec)
path result;
#ifdef _GLIBCXX_FILESYSTEM_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
--- Comment #4 from Jonathan Wakely ---
Actually that's wrong because path("foo/bar/..").lexically_normal() is just
"foo" which ignores whether foo/bar is a symlink to somewhere else.
I think the right fix is to just not define _GLIBCXX_USE_REA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
--- Comment #3 from Jonathan Wakely ---
This fixes the FAIL for 27_io/filesystem/operations/weakly_canonical.cc
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -162,7 +162,7 @@ fs::path
fs::canonical(const path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120460
--- Comment #3 from Jonathan Wakely ---
i.e. maybe this warning should ignore whether it's in a system header or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120460
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-05-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #6 from Jonathan Wakely ---
Please don't waste time on the volatile question. What does it mean to lookup a
volatile value that could change at any moment? What is the library even
supposed to do with a volatile int& there, read it a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120458
--- Comment #1 from Jonathan Wakely ---
Clang compiles this, and I think MSVC does, but EDG doesn't (but EDG also
doesn't accept that identifier for a variable name, at least with the default
options).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2022-11-10 00:00:00 |2025-5-28
--- Comment #3 from Jonatha
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 103524
Target Milestone: ---
I think this should be valid in C++20:
export module 汉字;
$ g++ -std=c++20 c.cc -fmodules
./c.cc:1:8: fatal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #14 from Jonathan Wakely ---
Created attachment 61536
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61536&action=edit
Add abi tag to system_clock::to_time_t
Here's a new patch, which includes a test to verify that the abi_tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #12 from Jonathan Wakely ---
Also, I don't think we need the abi tag from from_time_t, because the mangled
name of that function already depends on the type of time_t. The problem with
to_time_t is that the mangled name does not depen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #11 from Jonathan Wakely ---
(In reply to Francois-Xavier Coudert from comment #10)
> I'd rather have a script like libgfortran/regenerate.sh, that calls m4 and
> updates the tree. Then maintainers know that, if they changed any m4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #15 from Jonathan Wakely ---
(In reply to Hongtao Liu from comment #13)
> The inner loop is not completely unrolled since std::copy is lowered to
> __builtin_memmove instead of __builtin_memcpy
std::copy allows the end of the output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #5 from Jonathan Wakely ---
Aside: FX, please use --author when committing somebody else's patch, so that
the Author: field in git and the generated ChangeLog are correct.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 106749
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2655r3.html
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #11 from Jonathan Wakely ---
My first thought was that -D_TIME_BITS=64 requires _FILE_OFFSET_BITS=64 to be
set too, but glibc will give an #error if it's not set. So libstdc++ does not
need to worry about users incorrectly using -D_TI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #8 from Jonathan Wakely ---
(In reply to Shawn Xu from comment #0)
> On x86-64 with avx512, PR115444 caused the following code to vectorize
> sub-optimally:
What made you blame PR115444 for this? Did you actually bisect it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100586
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> The regression was caused by
> r15-3078-g6ea25c041964bf63014fcf7bb68fb1f5a0a4e123
I bisected to this commit using the code in comment 2. It looks like the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |tree-optimization
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #7 from Jonathan Wakely ---
This was backported as r14-10608-g27dc1533b6dfc4 and r13-8987-gaea374238cec1a
and r12-10682-gb4bc34db3f2948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
Jonathan Wakely changed:
What|Removed |Added
Known to fail||14.3.0, 15.1.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #4 from Jonathan Wakely ---
The library code should be exactly equivalent, except for being slightly
simpler (one level of function call has been inlined into its caller now) and
doing:
ptr += n;
return ptr;
instead of:
retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111250
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|--- |12.5
Known to fail||15.1.0, 7.5.0
Priority|P3 |P4
Severity|normal |minor
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #8 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> clang 19 says
>
> > clang-19 t.C -S -std=c++20
> t.C:4:11: error: no viable overloaded '-='
> 4 | __tmp -= __n
> | ~ ^ ~~~
> t.C:4:17:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120325
--- Comment #3 from Jonathan Wakely ---
I've added a note about this to
https://gcc.gnu.org/gcc-15/porting_to.html#cxx20-iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119427
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|14.4|15.2
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #14 from Jonathan Wakely ---
I've added a note to the bottom of
https://gcc.gnu.org/gcc-14/porting_to.html#cxx20-iterators which links to
https://gcc.gnu.org/gcc-15/porting_to.html#cxx20-iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #10 from Jonathan Wakely ---
There's a one-line fix:
[[nodiscard]] constexpr friend difference_type operator-(const
TransformIterator& x, const TransformIterator& y)
+ requires std::sized_sentinel_for
{
return x.it - y.it;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #12 from Jonathan Wakely ---
Upstream already replaced their transform view with std::views::transform so
probably aren't going to be interested in the patch:
https://github.com/openMSX/openMSX/commit/e4aa15cbfdfb3e1b94ae7e787f2be0f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
Jonathan Wakely changed:
What|Removed |Added
Known to fail|14.3.0, 15.1.1 |
--- Comment #9 from Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407
--- Comment #4 from Jonathan Wakely ---
(In reply to Daniel Starke from comment #0)
> Compiling the following C++ code for mingw-w64 using `-O2 -s -static`
> creates a 896 KiB executable instead of 119 KiB since git commit
> releases/gcc-12.2.0-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #6 from Jonathan Wakely ---
I suspect this is a similar problem to Bug 120325 i.e. an iterator type which
is not compatible with C++20 rules, and needs to be fixed or opt-out of being a
C++20 random access iterator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> That should be r12-g00ac6fa3f2a (as Andrew linked to).
Gah, I mean r12-9330-g00ac6fa3f2a54f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407
--- Comment #3 from Jonathan Wakely ---
Similar code size increase is seen for a x86_64-linux target too.
$ size reg-12.2 reg-12.3
textdata bss dec hex filename
818932872 152 84917 14bb5 reg-12.2
816931 24296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395
--- Comment #3 from Jonathan Wakely ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120399
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120399
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |16.0
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
We have std::__uninitialized_default which is used to implement
std::uninitialized_value_construct, and std::__uninitialized_default_novalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120397
--- Comment #4 from Jonathan Wakely ---
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -118,7 +118,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
~_UninitDestroyGuard()
{
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120397
--- Comment #3 from Jonathan Wakely ---
~_UninitDestroyGuard()
{
if (__builtin_expect(_M_cur != 0, 0))
std::_Destroy(_M_first, *_M_cur);
}
If we handle arrays here then it doesn't impact other uses of std::_D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120397
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> We could either stop using std::_Destroy(first, cur) in the uninitialized
> algos (no thanks), or make std::_Destroy(first, cur) handle arrays, or make
> std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120397
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-05-22
Ever confirmed|0
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct X { ~X() { } };
void f()
{
X x[1];
x->~X();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395
--- Comment #1 from Jonathan Wakely ---
This isn't actually related to the builtin, we get the same thing for any
always_inline function that returns a constant:
void x(int);
[[gnu::always_inline]]
inline bool always_true() { return true; }
s
-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
void x(int);
[[gnu::always_inline]] inline bool
is_constant_evaluated()
{ return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390
Jonathan Wakely changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #5 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390
--- Comment #4 from Jonathan Wakely ---
There's also the source context which should be pretty clear what the assertion
was testing when it failed:
188 | static_assert(is_destructible<_Value_type>::value,
But I think the best solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387
--- Comment #5 from Jonathan Wakely ---
The instructions at https://gcc.gnu.org/bugs/ are very explicit about including
that information.
15.1.1 is not a release, it's any snapshot between the date of the 15.1.0
release and now, so is not enoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387
--- Comment #1 from Jonathan Wakely ---
*** Bug 120388 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387
--- Comment #3 from Jonathan Wakely ---
(In reply to Justen Di Ruscio from comment #0)
> The specific function causing the error is here
> (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/
> expected;h=5dc1dfbe5b8a954826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119714
Jonathan Wakely changed:
What|Removed |Added
CC||justend29 at gmail dot com
--- Commen
1 - 100 of 7689 matches
Mail list logo
