https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109150
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #5 from Arthur O'Dwyer ---
> Yes, so that std::copy_n benefits from the same memmove optimization as
> std::copy.
Right, I'm not objecting to the memmove optimization, just to the current
codebase's approach of "slightly pessimize
++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
Jason Turner recently did a video on `-Wnrvo`
https://www.youtube.com/watch?v=PTCFddZfnXc and I noticed some deficiencies in
GCC's handling of his very first example. Here's the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115361
--- Comment #6 from Arthur O'Dwyer ---
Thanks, that looks much less noisy! (Assuming godbolt.org has updated already.)
I now see this:
// https://godbolt.org/z/WqT6hs8ed
f3, f7, and f9 now all give -Wuninitialized at -O1 and higher (and
false-
erity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
Bug #105609 is related, i.e. it's about using std::move(*it) where ADL
iter_move(it) is required; but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102116
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109941
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
https://godbolt.org/z/fPjoqMrYs
template
struct CW {
using V = typename decltype(T())::type;
static voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118647
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
ormal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
https://godbolt.org/z/Y4nKfsfM8
int main() {
std::deque v;
printf("Default-constructed capacity: %zu\n"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351
--- Comment #10 from Arthur O'Dwyer ---
> > Would it be at least possible to make the error clearer?
> I don't think that's possible to do in the library.
Agreed. IMO this bug should be marked RESOLVED at this point, because James
Knight's pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119497
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119497
--- Comment #7 from Arthur O'Dwyer ---
> @jwakely is correct that on OSX/Darwin the macro is named `__assert_rtn`.
...er, sorry, the *non-constexpr function called by the `assert` macro* is
named `__assert_rtn`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119576
--- Comment #8 from Arthur O'Dwyer ---
The Linux kernel disables -Warray-bounds in GCC 9 and later (and
-Wstringop-overflow unconditionally).
https://github.com/openSUSE/kernel/blame/5be5ecdaf1e7fb1a04e6122771b432851cd2393d/init/Kconfig#L905-L92
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119576
--- Comment #6 from Arthur O'Dwyer ---
Will Wray points out that GCC's own codebase disables `-Warray-bounds` in
several places, including at least these places in current master:
gcc/cp/module.cc:#pragma GCC diagnostic ignored "-Warray-bounds"
: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
See meta-bug #56456 for both "false negative" and "false positive" reports with
-Warray-bounds.
See bug #107677 for a user asking "What is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109941
--- Comment #7 from Arthur O'Dwyer ---
I've split out the `std::expected` feature request specifically into bug
#119197.
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
See https://quuxplusone.github.io/blog/2024/12/08/should-expected-be-nodiscard/
and
https://www.reddit.com/r/cpp/comments/1h9u4us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
As reported by Rufei Zhao on the cpplang Slack: https://godbolt.org/z/fa48dvnoq
std::flat_map m;
int main(void) {
const double e { 3.14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #2 from Arthur O'Dwyer ---
(In reply to Patrick Palka from comment #1)
> Confirmed, that fix looks good to me.
>
> FWIW our template operator[] is just the standard
> https://eel.is/c++draft/flat.map#access-4 with more generalized c
201 - 223 of 223 matches
Mail list logo
