If the compiler cannot analyze memcpy, it must expect that pointer arguments may be stored as static data and must live for recursive calls.
In such cases, op_Store and op_Load operations will not get tail-call optimized.
By enclosing the local variables in a block before the recursive call, the storage duration does not extend far enough, allowing for TCO.
With C++ enum classes, the size of an enum object can vary depending
on the compiler generation mechanism (choosing the most optimal storage size
to contain all the variants) or a user-defined storage type. In wasm we
can only send int32_t and int64_t. That means, the enums using this
integer width for storage must also work properly. At runtime this works
flawlessly, the functions in wasm can return these values safely and
they are even converted back on the C++ side to their enum
representations, thanks to the code in wasm3 which does a cast an
integer cast. But when it comes to generating the code for function
arguments, the defined data structure is not enough to generalize the
code to allow enum classes even if they are of a proper (allowed) width.
This commit changes the defined data structure to create a data
structure literal for wasm so that it allows enum classes as well as
already defined data types.
Since https://reviews.llvm.org/D81689, wasm-ld has started wrapping
all exported functions including "_start" with surrounding ctor/dtor
calls. The wrapper function "_start.command_export" is exposed as
"_start".
wasm3 searched the entry function by looking up names indiscriminately.
However, it sometimes found the internal "_start" function, so ctor/dtor
were not called. To pick up the wrapper "_start", this patch changes to
search export names at first.
* Add integer overflow checks in NewCodePage
Fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33457
* TouchSlot should track slots outside of functions
Fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33554.
The OSS-Fuzz inputs led to a crash on a Const64 instruction that
overflows the stack. The overflow was not detected during compilation as
TouchSlot did not track maxStackSlots if o->function is NULL. This
commit changes TouchSlot to track slots outside of functions.
* Fix out-of-bounds write in MarkSlotsAllocatedByType
While pushing the params back onto the stack in CompileBlock,
GetSlotForStackIndex may return c_slotUnused. If that is the case,
passing the slot to MarkSlotsAllocatedByType leads to a crash.
Fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33555
Fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36551
* Fix memory leak in CompileElseBlock
In the case of an exception in CompileElseBlock, the original page was not
properly restored and was leaked. This commit moves the release/restore
in the _catch: block which always executes.
* Fix stackIndex underflow in param deallocation
When the stack is polymorphic, the stack should never underflow. This
commits fixes an unreported stack underflow while led to an integer
underflow in stackIndex. Now, if the stack is polymorphic, we only
decrement stackIndex up until blockStackIndex.
Frank Denis