https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #15 from Jonathan Wakely ---
(In reply to Sergey Fedorov from comment #13)
> Is this the same error? https://github.com/sleuthkit/sleuthkit/issues/3272
No, that is Bug 81967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 117983, which changed state.
Bug 117983 Summary: [12 Regression] -Wstringop-overflow false positive for
__builtin_memmove from vector::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117983
What|Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117983
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118035
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212
--- Comment #14 from Jonathan Wakely ---
The std::array problem is fixed for 12.5, 13.4 and 14.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #18 from Jonathan Wakely ---
The std::vector problem is fixed for 12.5 and 13.3 and 14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117966
--- Comment #17 from Jonathan Wakely ---
The error in std::span is fixed for 12.5, 13.4 and 14.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117560
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.4|12.5
--- Comment #9 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116549
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.4|12.5
--- Comment #12 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
--- Comment #10 from Jonathan Wakely ---
I proposed
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3223r1.html to fix
this surprising behaviour, but it hasn't made it through the committee yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105609
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106612
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|14.3|13.4
--- Comment #12 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117121
--- Comment #6 from Jonathan Wakely ---
I backported the changes to the algos and so had to backport this fix too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116471
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.4
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118093
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116586
Bug 116586 depends on bug 118093, which changed state.
Bug 118093 Summary: std::future::wait_until futex call returns EINVAL for
negative timeout smaller than 1s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118093
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088
--- Comment #11 from Jonathan Wakely ---
tl;dr:
> The remaining regressions in the number of allocations and temporaries
> should be addressed separately, with more conservative optimizations
> specific to std::string. That is not pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|15.0|14.3
--- Comment #10 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119822
--- Comment #4 from Jonathan Wakely ---
And also at https://gcc.gnu.org/gcc-14/changes.html#libstdcxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119813
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119798
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-04-14
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86273
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #4 from Jonathan Wakely ---
(In reply to AlphaOmegaProgrammer from comment #0)
> The problem with the current implementation is that it relies on a hash of
> the lower 12 bits of the pointer address to index an array of mutexes, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #3 from Jonathan Wakely ---
(In reply to AlphaOmegaProgrammer from comment #1)
> Created attachment 61108 [details]
> Current implementation of locking algorithm
>
> This file can be found at /libatomic/config/posix/lock.c
You don'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119755
--- Comment #3 from Jonathan Wakely ---
Sorry for the slightly confused report, I think what I pasted here wasn't quite
what I was testing (e.g. the command has `-x c++ -` but I said to compile a
file).
Thanks for figuring out what I actually m
: 15.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This works:
:| ~/gcc/15/bin/g++ -x c++ - -x c++ /dev/null -c -std=c
NCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Given a file with the single line:
#include
Using a recent trunk:
g+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #5 from Jonathan Wakely ---
Ah no, it looks like GCC only emits a line in that format for the main source
file, not for the included headers. So maybe GCC could just emit one extra
line, and not remove anything from the current outpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |15.0
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
--- Comment #1 from Jonathan Wakely ---
GCC fails to diagnose it for the same reason that it fails to diagnose this:
#include
consteval bool f()
{
int* p = std::allocator().allocate(1);
*p = 99;
std::allocator().deallocate(p, 1);
retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #4 from Jonathan Wakely ---
(In reply to Bogdan from comment #2)
> GCC does use the options specified in the standard.
I think it would be more accurate to say that the standard specifies the
options that GCC (and traditional UNIX c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
: 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
#include
consteval bool f(int n)
{
int* p = std::allocator().allocate(n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #1 from Jonathan Wakely ---
POSIX is talking about the 'c17' utility, not a command called 'gcc'. I don't
think GCC claims to be equivalent to 'c17'.
Any 'c99' or 'c17' utility you have is not part of upstream GCC but is
installed b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #3 from Jonathan Wakely ---
(In reply to Bogdan from comment #0)
> 1. If those numbers at the end are unimportant, maybe just strip them from
> the output. I'm not even sure what they represent.
See the documentation:
https://gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #13 from Jonathan Wakely ---
Hmm, __uninitialized_default doesn't have a std::is_constant_evaluated check,
but I think it needs it for exactly the same reasons.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #12 from Jonathan Wakely ---
The __uninitialized_default_n_1 specialization assumes that we can use
std::fill_n to assign to objects outside their lifetime. I don't think that's
valid during constant evaluation, is it? That's why we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119752
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119748
--- Comment #2 from Jonathan Wakely ---
Ah yes, thanks.
(In reply to Jonathan Wakely from comment #0)
> _S_copy(__p, std::__niter_base(__k1), __k2 - __k1);
> #if __cpp_lib_concepts
> else if constexpr (contiguous_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119748
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: hewillk at gmail dot com
Target Milestone: ---
#include
volatile char vs[42
rity: 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/2022/p2438r2.html
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bu
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/2022/p2711r1.html
Referenced Bugs
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 110339
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p0447r28.html
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 110339
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2697r1.pdf
Referenced Bugs:
https
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 110339
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2495r3.pdf
Referenced Bugs:
https
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 110339
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2714r1.html#5-Wording
Referenced Bugs:
https
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 110339
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0952r2.html#wording
Referenced Bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #54 from Jonathan Wakely ---
Furthermore, if two threads call the non-const begin() concurrently on a shared
rep, they both want to make a new clone and release their reference to the old
rep. If they both allocate a new clone and sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119724
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119724
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-04-11
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #53 from Jonathan Wakely ---
(In reply to tlknv from comment #44)
> Thanks Marc.
> I have posted my patch at
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg02086.html
This is just a bandaid and not sufficient to avoid the problem. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #25 from Jonathan Wakely ---
If we can't use range-based 'for' with ranges then we've taken a wrong turn
somewhere.
I did test them in e.g. std/ranges/access/begin.cc so we know that
ranges::begin and ranges::end will work with them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #20 from Jonathan Wakely ---
Does it matter? By design, ranges::begin does the same things as range-based
for (handles arrays first, then looks for member begin(), then looks for ADL
begin).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #23 from Jonathan Wakely ---
(In reply to 康桓瑋 from comment #21)
> FYI:
> https://stackoverflow.com/questions/79261063/in-what-situations-does-
> rangesfor-each-work-but-for-auto-elt-rg-fail/79262269#79262269
Yes, like that. It deser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #22 from Jonathan Wakely ---
There might be pathological cases where they differ, e.g. a range type that has
member begin and ADL end, but they deserve to break.
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Keywords||documentation
--- Comment #52 from Jonathan Wakely ---
(In reply to James Kanze from comment #0)
> I am sending this to the g++ bug list on the recommendation of
> Gabriel Dos Reis. Fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #21 from Jonathan Wakely ---
Fixed for 15 and 14.3 so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105926
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90468
--- Comment #6 from Jonathan Wakely ---
I think it's referring to control-flow problems and data-flow problems, but
maybe I'm wrong about that. I'm not sure what a warning about control is, but I
know what control flow is
Also, I think the origi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90468
--- Comment #4 from Jonathan Wakely ---
Would "efficacy of warnings about control- and data-flow" with an extra hyphen
be better?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119671
Jonathan Wakely changed:
What|Removed |Added
Known to fail||13.3.0, 14.2.0
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159
--- Comment #8 from Jonathan Wakely ---
Peter Dimov pointed out an even simpler example of valid-but-questionable code:
std::unique_ptr p(new int);
p.reset(p.get());
(void) p.release();
The pointer is invalidated by the self-reset, but then is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |16.0
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #8 from Jonathan Wakely ---
Created attachment 61033
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61033&action=edit
Rewrite atomic builtin checks
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |13.4
Ever confirmed|0 |1
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
int main()
{
auto loc = std::locale::classic();
assert(std::format(loc
gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed||2025-04-07
Status|UNCONFIRMED |ASSIGNED
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 110339
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2546r5.html
Also https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2810r4.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119642
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119666
--- Comment #5 from Jonathan Wakely ---
The language semantics require us to do that for C++ constant expressions. You
can use that integer (or a constexpr function returning an integer) like this:
int a[x];
std::array a2;
You cannot delay eva
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
GLIBCXX_ENABLE_BACKTRACE in acinclude.m4 says:
# libbacktrace only needs atomics for int, which we've already t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119654
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119647
--- Comment #4 from Jonathan Wakely ---
ICU is asking for an old version of POSIX, which causes macOS SDK to undeclare
functions required by C11, which means that the SDK is not compatible with
C++20 (because it assumes a C11 library).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119642
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=110620
--- Comment #8 from Jonathan Wakely ---
That isn't necessarily true though. _S_check_init_len takes __n by non-const
reference and changes it to be the number of elements that are actually
allocated *which might be more than requested*. std::vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111499
--- Comment #10 from Jonathan Wakely ---
Should we use #ifdef __OPTIMIZE__ around all of those additions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119620
--- Comment #7 from Jonathan Wakely ---
... and that's what "Cpp17EmplaceConstructible into X" is about.
But we can't constrain based on that, and can't spell out exactly what kind of
initialization is done, because we don't know. Only the allo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119620
--- Comment #6 from Jonathan Wakely ---
No, because if we only create it inside a container then it's constructed with
allocator_traits::construct(ptr, args...) and we don't know what that does. It
doesn't necessarily correspond to constructing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119627
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119627
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Andrew Sayers from comment #0)
> > ./cross-compiled: symbol lookup error: ./cross-compiled: undefined symbol:
> > _ZNSt12__shared_ptrINSt10files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119627
--- Comment #1 from Jonathan Wakely ---
(In reply to Andrew Sayers from comment #0)
> ./cross-compiled: symbol lookup error: ./cross-compiled: undefined symbol:
> _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2
> EE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|15.0|14.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119620
--- Comment #2 from Jonathan Wakely ---
The way our flat_set::emplace is implemented, it always constructs an object on
the stack:
template
pair
_M_try_emplace(optional __hint, _Args&&... __args)
{
// TOD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119620
--- Comment #1 from Jonathan Wakely ---
(In reply to 康桓瑋 from comment #0)
> I don't know why the standard sometimes constrains emplace(), sometimes only
> constrains insert(), and sometimes constrains neither.
flat_multiset::emplace is specifie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112934
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=119593
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103382
--- Comment #10 from Jonathan Wakely ---
(In reply to Richard Biener from comment #9)
> For the record, compiling with affected GCC but link editing against fixed
> libstdc++ makes the testcase no longer terminate but at the expense of not
> unl
||a/show_bug.cgi?id=118494
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #5 from Jonathan Wakely ---
This will be fixed by
https://forge.sourceware.org/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395
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=118494
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=114758
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
1 - 100 of 7709 matches
Mail list logo
