https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121180
--- Comment #5 from Jonathan Wakely ---
struct Empty { };
struct S : Empty { char buf[1]; };
int main()
{
S s;
new (s.buf) Empty;
}
Isn't this exactly the same?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #15 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102181
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #10 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
--- Comment #7 from Jonathan Wakely ---
And the original code from comment 0 now does:
$ ./a.out
1) Create an object and pass it over to a shared pointer...
ptr.use_count() -> 1
2) Create an extra reference to that object...
ptr.use_count(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
--- Comment #14 from Jonathan Wakely ---
OK great, thanks all.
I have a patch ready that flips the non-inline atomics to use -fwrapv and fixes
the handful of inline ones to avoid signed overflow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121150
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121147
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> As it says at https://gcc.gnu.org/wiki/InstallingGCC "If your build fails
> and your configure command has lots of complicated options you should try
> remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121150
--- Comment #7 from Jonathan Wakely ---
(In reply to Tomasz Kamiński from comment #6)
> What about doing:
> __uint128 u = 0x1;
> u <<= 32u;
> u |= 0x2345;
> u <<= 32u;
> u |= 0x6789;
> __int128 i = u;
There's no problem forming the constant 0x1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121150
--- Comment #3 from Jonathan Wakely ---
--- a/libstdc++-v3/testsuite/20_util/hash/int128.cc
+++ b/libstdc++-v3/testsuite/20_util/hash/int128.cc
@@ -9,12 +9,12 @@ int main()
#ifdef __SIZEOF_INT128__
std::hash<__int128> h;
__int128 i = (__i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121150
--- Comment #5 from Jonathan Wakely ---
Also, those C macros are ugly and unnecessary in C++ :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121150
--- Comment #4 from Jonathan Wakely ---
(In reply to H.J. Lu from comment #2)
> + __int128 i = (__int128)INT64_C(0x123456789);
This doesn't do anything, it's already a signed 64-bit value.
The problem is that h(__i) truncates it to 32-bit siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121150
--- Comment #1 from Jonathan Wakely ---
There is no long anywhere here. The problem is that size_t is 32 bits, and
using an INT64 suffix won't change that: the value will still be too large for
size_t.
I'll fix it by using a different value for
|--- |16.0
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
--- Comment #9 from Jonathan Wakely ---
Ha yes, my patch uses -fwrapv, it's just a typo :)
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -132,6 +132,11 @@ atomicity_file =
${glibcxx_srcdir}/$(ATOMICITY_SRC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
--- Comment #6 from Jonathan Wakely ---
Simpler reproducer which fails the assertion with trunk when the ref count
overflows to INT_MIN, but which passes with my local patches:
#include
#include
#include
int main()
{
std::shared_ptr p(new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
--- Comment #7 from Jonathan Wakely ---
Nearly all the plain C++ code can be fixed just by compiling it with -ftrapv,
there's only one inline function where we can't control the compiler flags the
user uses. So only that place needs to change (i
|ASSIGNED
Last reconfirmed||2025-07-17
Target Milestone|--- |16.0
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> The __atomic_fetch_add built-in on signed integers is required to wrap like
> unsigned integers without UB, but we should check that all our
> target-specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jonathan Wakely changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jonathan Wakely changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jonathan Wakely changed:
What|Removed |Added
CC||schwab at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jonathan Wakely changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jonathan Wakely changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
--- Comment #1 from Jonathan Wakely ---
We also have handwritten assembly versions which need to be checked by target
maintainers:
libstdc++-v3/config/cpu/cris/atomicity.h has three different assembly
implementations of __exchange_and add
I th
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 71945
Target Milestone: ---
The std::atomic::fetch_xxx members are required to never
overflow:
Remarks: [...] for signed integer types the result is as if the object value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121147
--- Comment #3 from Jonathan Wakely ---
(In reply to terryinzaghi from comment #0)
> ../gcc-15.1.0/configure \
> --prefix=/home/cu-lib/GCC15/gcc15-installed \
> --enable-languages=c,c++ \
> --enable-bootstrap \
> --enable-checking=relea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121147
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121141
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116586
Jonathan Wakely changed:
What|Removed |Added
CC||dhruvc at nvidia dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> The __atomic_fetch_add built-in on signed integers is required to wrap like
> unsigned integers without UB, but we should check that all our
> target-specific
gcc dot gnu.org |redi at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> We should terminate if the counter reaches its maximum value.
That would mean changing f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121114
--- Comment #5 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #4)
> BTW, does the standard require that in all standard headers where these
> exceptions can be thrown the corresponding exception types have to be
> defined,
No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121055
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477
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: ---
For C++26 we can throw and catch exceptions during constant evaluation, but our
current solution for throwing in e.g. std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121097
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121097
--- Comment #5 from Jonathan Wakely ---
Sure, we could do, but I'm not convinced it's a real issue, only a hypothetical
one. Your config seems self-inflicted, due to an incomplete emulation of GCC 10
(which did define __cpp_fold_expressions).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121097
--- Comment #3 from Jonathan Wakely ---
(In reply to Arthur O'Dwyer from comment #1)
> Er, PC-Lint 2.0 with a config file that *we* made to roughly emulate GCC 10,
> apparently. I can't blame PC-Lint itself for the weird setting of these
> macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121097
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108409
Jonathan Wakely changed:
What|Removed |Added
Target|*-*aix* *-*-mingw* |*-*aix*
Summary|std::chron
ords: ABI
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
For all integer types std::hash just returns the original value:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121053
--- Comment #2 from Jonathan Wakely ---
Neither form is constrained in the standard. With libstdc++ std::visit is
SFINAE-friendly and std::visit is not. With libc++ both are SFINAE-friendly.
rsion: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct F
{
void operator()() && { }
};
templ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121052
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Many of our uses of the nonnull attribute are probably bugs, e.g.
>
> polymorphic_allocator(memory_resource* __r) noexcept
> __attribute__((__no
ords: wrong-code
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The standard requires that all of the bitset constructors taking a string
check the whole
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
I don't think this is required by the standard, but it works for the std::visit
case, just not std::visit
#include
template
concept visitable = requires(Visitor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86878
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2024-01-09 00:00:00 |2025-7-13
See Also|
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Depends on: 110617
Target Milestone: ---
Many of our uses of the nonnull attribute are probably bugs, e.g.
polymorphic_allocator(memory_resource* __r) noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2020-06-03 00:00:00 |2025-7-13
--- Comment #13 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015
--- Comment #16 from Jonathan Wakely ---
The standard relaxed the rules slightly for iterator difference types, to
permit integer-class types to be used as difference types (see
[iterator.concept.winc]). However, those integer-class types are
imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119742
--- Comment #5 from Jonathan Wakely ---
Also, do we want to make this change?
--- a/libstdc++-v3/include/std/bitset
+++ b/libstdc++-v3/include/std/bitset
@@ -720,7 +720,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
namespace __bitset
{
-#if _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121046
--- Comment #3 from Jonathan Wakely ---
https://cplusplus.github.io/LWG/issue4294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121046
--- Comment #2 from Jonathan Wakely ---
I think we should open a library issue to add a constraint to the standard.
lid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Found by the libc++ testsuite:
#include
struct NonTrivial { ~NonTrivial() { } };
static_assert( !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121046
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102181
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106610
--- Comment #1 from Jonathan Wakely ---
Isn't this invalid because of [concepts.equality] p6?
The indirectly_readable concept requires that *it works on a const lvalue,
which means it has to behave the same on lvalues and rvalues or the same ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117998
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90919
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2020-01-28 00:00:00 |2025-7-12
--- Comment #2 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88374
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #38 from Jonathan Wakely ---
I'll fix that, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #32 from Jonathan Wakely ---
(In reply to Hana Dusíková from comment #28)
> (In reply to Jakub Jelinek from comment #27)
> > Jason Merrill asked for that during patch review:
> > https://gcc.gnu.org/pipermail/gcc-patches/2025-July/68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120866
--- Comment #6 from Jonathan Wakely ---
So how should this be fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13823
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|SUSPENDED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117822
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120997
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> Thanks for submitting the issue! I'll add the link here once it gets created.
https://cplusplus.github.io/LWG/issue4293
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120997
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120305
Bug 120305 depends on bug 96710, which changed state.
Bug 96710 Summary: __int128 vs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96710
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96710
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 110498, which changed state.
Bug 110498 Summary: [12 Regression] Spurious warnings stringop-overflow and
array-bounds copying data as bytes into vector::reserve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|12.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 110498, which changed state.
Bug 110498 Summary: [12 Regression] Spurious warnings stringop-overflow and
array-bounds copying data as bytes into vector::reserve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121026
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Fourthly, I don't think this ranges::uninitialized_move optimization is
> valid:
>
> auto [__in, __out]
> = ranges::copy_n(std::make_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121026
--- Comment #1 from Jonathan Wakely ---
We could also take the opportunity to look into whether any of those
optimizations still buy us much performance. Is the compiler smart enough to
turn the default implementation (in terms of a loop) into m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> However, ranges::uninitialized_value_construct has the same bug as
> std::uninitialized_value_construct and wasn't fixed by my recent commit (but
> I do ha
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Firstly, the _DestroyGuard is a no-op for trivially destructible types:
template
requires
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #10 from Jonathan Wakely ---
However, ranges::uninitialized_value_construct has the same bug as
std::uninitialized_value_construct and wasn't fixed by my recent commit (but I
do have a fix in my local tree).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Jiang An from comment #6)
> > It seems that algorithms in std properly destroy trivially destructible
> > objects, but those in std::ranges don'
: accepts-invalid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: daniel.kruegler at googlemail dot com, de34 at live dot cn,
tkaminsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102284
Jonathan Wakely changed:
What|Removed |Added
Blocks||110367
--- Comment #9 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
--- Comment #8 from Jonathan Wakely ---
(In reply to Jiang An from comment #6)
> It seems that algorithms in std properly destroy trivially destructible
> objects, but those in std::ranges don't.
Isn't this a completely separate bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390
--- Comment #7 from Jonathan Wakely ---
Related: https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> #include
> #include
>
> consteval bool f(int n)
> {
> int* p = std::allocator().allocate(n);
> std::uninitialized_value_construct(p, p+n);
> std::al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
--- Comment #7 from Jonathan Wakely ---
(In reply to Žarko Asen from comment #5)
> in my case (C++ 20) -Wunitialized was not enabled by -Wall therefore a
> critical bug slip through:
>
> const uint32_t x = x + 1; // where is a novel variable in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
--- Comment #6 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #3)
> Hmm, I do think there is a documentation issue though it says -Wextra
> enables -Wuninitialized but it is -Wall that does.
Right, -Wextra clearly documents th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104547
--- Comment #13 from Jonathan Wakely ---
This test fails with this proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689128.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
Bug 110339 depends on bug 117403, which changed state.
Bug 117403 Summary: [C++26] Implement P1901R2 Enabling the Use of weak_ptr as
Keys in Unordered Associative Containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117403
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117403
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120997
--- Comment #4 from Jonathan Wakely ---
Thanks for submitting the issue! I'll add the link here once it gets created.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120997
--- Comment #3 from Jonathan Wakely ---
Yeah we have a defect in the C++26 draft, which needs to be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120997
--- Comment #2 from Jonathan Wakely ---
The libstdc++ implementation follows the C++26 draft standard exactly:
Effects: Equivalent to: return {data(), count};
So maybe we need to fix that.
|1
Last reconfirmed||2025-07-08
Target Milestone|--- |15.2
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
This fixes it:
--- a/libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
Bug 110339 depends on bug 120364, which changed state.
Bug 120364 Summary: std::bitset is missing hardened preconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120364
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118341
Jonathan Wakely changed:
What|Removed |Added
Blocks||110339
--- Comment #6 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118341
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120364
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
1 - 100 of 7915 matches
Mail list logo
