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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119756
Bug ID: 119756
Summary: Error when reading source from stdin and compiling
modules: cc1plus: fatal error: stdout: No such file or
directory
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119755
Bug ID: 119755
Summary: type_traits:828:11: fatal error: failed to load
pendings for 'std::__is_one_of'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywo
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
Bug ID: 119754
Summary: std::uninitialized_value_construct does not begin
lifetime of trivial types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
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
Targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119748
Bug ID: 119748
Summary: std::string::string(InputIterator, InputIterator)
rejects volatile charT* as iterator
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119745
Bug ID: 119745
Summary: [C++23] Implement P2438R2, basic_string::substr() &&
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119744
Bug ID: 119744
Summary: [C++23] Implement P2711R1, Making multi-param
constructors of views explicit
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119743
Bug ID: 119743
Summary: [C++26] Implement P0447R28, std::hive
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119742
Bug ID: 119742
Summary: [C++26] Implement P2697R1, Interfacing bitset with
string_view
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119741
Bug ID: 119741
Summary: [C++26] Implement P2495R3, Interfacing stringstreams
with string_view
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119740
Bug ID: 119740
Summary: [C++26] Implement P2714R1, Bind front and back to NTTP
callables
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119739
Bug ID: 119739
Summary: [C++25] Implement P0952R2, A new specification for
std::generate_canonical
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: nor
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |ASSIGNED
Assignee|unassigned
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119671
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-04-07
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119671
Bug ID: 119671
Summary: Use-after-free for formatting floating-point types to
wide strings
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119670
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119670
Bug ID: 119670
Summary: [C++26] Implement P2546R5, Debugging Support
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lib
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119667
Bug ID: 119667
Summary: libstdc++ configure checks for libbacktrace need
atomics for void* and size_t
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
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
Targ
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110854
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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
Last
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
Ev
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 3150 matches
Mail list logo
