http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #7 from petschy at gmail dot com ---
Is it a plausible assumption that if a function is not marked as 'noreturn' and
the loop doesn't change the program's state then the loop could be optimized
away?
Cases:
- the loop terminates, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #8 from Michael Matz matz at gcc dot gnu.org ---
(In reply to petschy from comment #7)
Is it a plausible assumption that if a function is not marked as 'noreturn'
and the loop doesn't change the program's state then the loop could be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #9 from Mikael Pettersson mikpe at it dot uu.se ---
(In reply to Michael Matz from comment #8)
(the
argument being that an infinite loop is in itself a side-effect observable
from
outside).
Exactly.
A function containing
an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #10 from petschy at gmail dot com ---
Thanks for the explanation. The multithreaded argument is sound, but then, on
second thought, even in single threaded programs the state might be altered by
a signal handler, or another process if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #1 from petschy at gmail dot com ---
Created attachment 30365
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30365action=edit
test case source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #2 from petschy at gmail dot com ---
Created attachment 30366
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30366action=edit
gcc amd64 disassembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #3 from petschy at gmail dot com ---
Created attachment 30367
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30367action=edit
clang amd64 disassembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #4 from petschy at gmail dot com ---
Ooops, the test case won't perform the freeing completely, since the recursive
call is not inside the 'down' traversal loop, so only the first node on the
given level would be recursively freed, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #5 from petschy at gmail dot com ---
Created attachment 30368
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30368action=edit
fixed test case (correct recursive traversal)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
10 matches
Mail list logo
