https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
Andrew Pinski changed:
What|Removed |Added
Known to work|12.2.0, 15.0|
Keywords|needs-bisection,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-testcase
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
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 t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #9 from Mikael Pettersson ---
(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 infinite loop could
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #8 from Michael Matz ---
(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
> optimized away?
It
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 t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #6 fro
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=30368&action=edit
fixed test case (correct recursive traversal)
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 #3 from petschy at gmail dot com ---
Created attachment 30367
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30367&action=edit
clang amd64 disassembly
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=30366&action=edit
gcc amd64 disassembly
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=30365&action=edit
test case source
13 matches
Mail list logo
