<div dir="ltr"><br>On Sat, Jan 23, 2021 at 12:56 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>><br>> When you say "build it with the debug flag"could you be more precise? What was the exact/complete compilation command line you used for the failing and succeeding case?<br>><br>> In any case, it sounds like maybe you build an unoptimized build and the test passed (because tail callingwasn't done, the stack grew, and the overflow terminated the process as expected) and an optimized build where tail calling was done and the stack never overflowed/process never crashed.<br>><br>> That sounds like expected/reasonable/correct behavior to me - and that the test is flawed & shouldn't be expecting to be guaranteed that the stack will overflow in this case.<div>Hi, this is a javascript engine, we wanna make sure the compiler won't do tail calling optimization for these functions, any option to do that?<br>><br>> On Fri, Jan 22, 2021 at 11:09 PM 罗勇刚(Yonggang Luo) via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>>><br>>> ```<br>>>  jerry-core/ecma/operations/ecma-proxy-object.c | 4 +++-<br>>>  1 file changed, 3 insertions(+), 1 deletion(-)<br>>><br>>> diff --git a/jerry-core/ecma/operations/ecma-proxy-object.c b/jerry-core/ecma/operations/ecma-proxy-object.c<br>>> index c5d299c6..77aed25c 100644<br>>> --- a/jerry-core/ecma/operations/ecma-proxy-object.c<br>>> +++ b/jerry-core/ecma/operations/ecma-proxy-object.c<br>>> @@ -1108,7 +1108,9 @@ ecma_proxy_object_get (ecma_object_t *obj_p, /**< proxy object */<br>>>    if (ecma_is_value_undefined (trap))<br>>>    {<br>>>      ecma_object_t *target_obj_p = ecma_get_object_from_value (proxy_obj_p->target);<br>>> -    return ecma_op_object_get_with_receiver (target_obj_p, prop_name_p, receiver);<br>>> +    ecma_value_t value = ecma_op_object_get_with_receiver (target_obj_p, prop_name_p, receiver);<br>>> +    fflush (stdout);<br>>> +    return value;<br>>>    }<br>>>  <br>>>    ecma_object_t *func_obj_p = ecma_get_object_from_value (trap);<br>>> ```<br>>> In which condition,  ecma_op_object_get_with_receiver tail calling will not increase the stack-size?<br>>> I have a test-case that cause infinite loop, because that in normal conition, it's expect to raise an stack-exceed error but<br>>> now with llvm-compiled release build binary, it's turn out to be infinite loop because  ecma_op_object_get_with_receiver<br>>> will not increase the stack size anymore, once  ecma_op_object_get_with_receiver getting called, it's returned to the previous stack position。<br>>> Reproduced on OSX/Ubuntu 20.04<br>>><br>>> Stack-trace-base<br>>> ```<br>>> jerry!ecma_proxy_object_get (\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-proxy-object.c:1111)<br>>> jerry!ecma_op_object_get_with_receiver (\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:790)<br>>> jerry!ecma_op_object_get (\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:763)<br>>> jerry!vm_op_get_value (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:114)<br>>> jerry!vm_loop (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:2799)<br>>> jerry!vm_execute (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:4939)<br>>> jerry!vm_run (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:5046)<br>>> jerry!vm_run_global (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:328)<br>>> jerry!jerry_run (\Users\lygstate\work\typescript\jerryscript\jerry-core\api\jerry.c:671)<br>>> jerry!main (\Users\lygstate\work\typescript\jerryscript\jerry-main\main-unix.c:156)<br>>> libdyld.dylib!start (Unknown Source:0)<br>>> libdyld.dylib!start (Unknown Source:0)<br>>> ```<br>>><br>>> stack-trace-new, it's hope  ecma_op_object_get_with_receiver to deeper, but turn out to step-back.<br>>> ```<br>>> jerry!ecma_op_object_get_with_receiver (\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:784)<br>>> jerry!ecma_op_object_get (\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:763)<br>>> jerry!vm_op_get_value (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:114)<br>>> jerry!vm_loop (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:2799)<br>>> jerry!vm_execute (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:4939)<br>>> jerry!vm_run (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:5046)<br>>> jerry!vm_run_global (\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:328)<br>>> jerry!jerry_run (\Users\lygstate\work\typescript\jerryscript\jerry-core\api\jerry.c:671)<br>>> jerry!main (\Users\lygstate\work\typescript\jerryscript\jerry-main\main-unix.c:156)<br>>> libdyld.dylib!start (Unknown Source:0)<br>>> libdyld.dylib!start (Unknown Source:0)<br>>> ```<br>>><br>>> Same clang , build it with debug flag, the issue gone. I am wonder if there is a misoptimization here<br>>><br>>> The c code<br>>> <a href="https://gist.github.com/lygstate/b554e74a22353d50a24240128f875474">https://gist.github.com/lygstate/b554e74a22353d50a24240128f875474</a><br>>><br>>> The full source tree<br>>> <a href="https://github.com/lygstate/jerryscript/tree/osx-clang-bug">https://github.com/lygstate/jerryscript/tree/osx-clang-bug</a><br>>><br>>><br>>> --<br>>>          此致<br>>> 礼<br>>> 罗勇刚<br>>> Yours<br>>>     sincerely,<br>>> Yonggang Luo<br>>> _______________________________________________<br>>> LLVM Developers mailing list<br>>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br><br><br><br>--<br>         此致<br>礼<br>罗勇刚<br>Yours<br>    sincerely,<br>Yonggang Luo</div></div>