https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
Gareth Lloyd changed:
What|Removed |Added
CC||gar...@ignition-web.co.uk
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
--- Comment #10 from Marc Glisse ---
"Forward progress [intro.progress]
The implementation may assume that any thread will eventually do one of the
following:
(1.1) — terminate,
(1.2) — make a call to a library I/O function,
(1.3) — perform an ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
--- Comment #9 from Richard Biener ---
clang doesn't optimize the corresponding C testcase
struct Foo {
struct Foo *next;
};
void release(struct Foo *next) {
struct Foo *tmp = 0;
for (struct Foo *it = next; it; it = tmp) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
--- Comment #8 from Richard Biener ---
So it's legal to remove the classical "halt CPU" while (1);? Interesting...
Does this apply to C++ only?
I presume for libstdc++ we could add a
#pragma GCC loop finite
which tells GCC it can assume the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
--- Comment #7 from Gareth Lloyd ---
To give extra context, this optimization is desirable when using
pmr::monotonic_buffer_resource. After de-virtualization and inlining it is
likely for node based containers with trivially destructible internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
Andrew Pinski changed:
What|Removed |Added
CC||gar...@ignition-web.co.uk
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
--- Comment #4 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> There isn't any "infinite loop is undefined behavior" thing
> so clang removing the loop is an invalid transform.
In C++ [intro.multithread]
27 The implementatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
--- Comment #3 from Richard Biener ---
We indeed do not have a flag to tell GCC it's ok to remove infinite loops with
no side-effects. We assume the dereferences will not trap (unless
-fexceptions -fnon-call-exceptions) and GCC happily removes p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
--- Comment #2 from Andrew Pinski ---
And it is not legal to do if you catch other undefined behavior like trapping
on invalid memory locations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809
Matt Godbolt changed:
What|Removed |Added
CC||matt at godbolt dot org
--- Comment #1 fr
12 matches
Mail list logo
