[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Andrew Pinski --- Dup of bug 89713. We mark loops to be finite when -ffinite-loops is enabled (which is the case for C++ front-end) and will remove these loops. r10-1052 implemented part of this and r10-7522 implemented the other part. Note there are other loops which are marked finite on the trunk dealing with recursive calls. *** This bug has been marked as a duplicate of bug 89713 ***
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809 Gareth Lloyd changed: What|Removed |Added CC||gar...@ignition-web.co.uk --- Comment #11 from Gareth Lloyd --- Looks like as of GCC 10.1 this optimisation exists This bug can be closed?
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
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 access through a volatile glvalue, or (1.4) — perform a synchronization operation or an atomic operation. [Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. — end note]"
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
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) {
tmp = it->next;
}
}
which means it needs to have a way in the IL to annotate loops as
terminating.
Does the C++ rule apply to all cycles or just to "loops"? (thinking
of goto, recursion, etc.)
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
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 loop eventually terminates.
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
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 types will end up with empty loops in their destructors.
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809 Andrew Pinski changed: What|Removed |Added CC||gar...@ignition-web.co.uk --- Comment #6 from Andrew Pinski --- *** Bug 90089 has been marked as a duplicate of this bug. ***
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-28 Ever confirmed|0 |1 Severity|minor |enhancement --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
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 possible traps so I don't think that would prevent the DCE here. What prevents DCE is that the loop might not terminate. There isn't any "infinite loop is undefined behavior" thing so clang removing the loop is an invalid transform.
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
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 implementation may assume that any thread will eventually do one of the following: (27.1) — terminate, (27.2) — make a call to a library I/O function, (27.3) — read or modify a volatile object, or (27.4) — perform a synchronization operation or an atomic operation. [ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. — end note ]
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809 Matt Godbolt changed: What|Removed |Added CC||matt at godbolt dot org --- Comment #1 from Matt Godbolt --- A colleague has pointed out this of course is not a "do nothing" if the list is circular. IANALL but I wonder if clang/icc take advantage of some kind of "infinite loop is undefined behaviour" here that GCC doesn't.
[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out
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.
