Matt Frank added the comment:
Yes, this is currently only a problem with the Intel compiler.
The writes to buffer[] are dead (provably won't be ever used) at the point that
the recursive call occurs. Actually gcc and llvm can figure this out. Thus
all the space allocated for the first call can be reused by every subsequent
call.
The analysis that icc is doing that gcc and clang are not yet doing has to do
with the pointer to depth. I believe icc is able to determine that depth
doesn't point into buffer where gcc and clang aren't sure that this is the
case. (If you change stack_overflow() so that depth is passed in and returned
by value then gcc also does the tail optimization.)
volatile doesn't disable the optimization. I think in this case it is too easy
to determine that buffer is on the stack, and both buffer and sp are dead by
the time of the recursive call.
It occurs to me that the right way to deal with this is with
__attribute__ ((optimize ("no-optimize-sibling-calls")))
on the function where it matters (stack_overflow()).
I'm working on a solution (need to test whether the compiler supports
attributes and etc.) and will post it ASAP.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23654>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
