fast_call in before finally overfide the return address set by the fast_call before zend_return.

@nikic what do you think ? I don't see a easy to fix it..

So, as I understand it the problem is that the FAST_CALL<FROM_FINALLY> of the inner finally block will indiscriminately set the fast_call opline to the FAST_CALL of the outer finally block, even though this is not necessarily the FAST_CALL that was actually used to enter it (e.g. in this instance).

I was wondering why this worked on PHP 5.6 as IIRC the handling wasn't very different. It looks like it's just an accident of fate that this particular code works there. This similar example doesn't: https://3v4l.org/DsLLE

The only solution to this I see is to use different fast_call temporaries for each nesting level of finally-in-finally. We also need this to solve a similar issue with exceptions, though I can't seem to find the bug report for that just now (maybe in private discussions?).

the problem here is:

we have two entry to the outter finally, the one is FAST_CALL before return(1), and the other is FAST_CALL before finally(2).

when we enter the finally block via the `return` one, we set fast_call_var to ZEND_RETURN, but later, the ZEND_FAST_CALL in inner finally override it to its own return address.

later, when return from inner finally, it will return to the (2) which is calculated during compiling time.  thus bug shows up.

we could check fast_call_var's return address in ZEND_FAST_CALL to fix this particular problem, but the problem is, we allocate fast_call_var in temp var now, there is no initialization mechanism for it. which means, we can not do "check". 

@Dmitry, what do you think?

thanks

Fixed in master (PHP-7.1) brunch only.