Fix undefined behavior due to memcpy-ing bool var

- Add template specialization for DataRange::get<bool> to avoid undefined behavior of the template DataRange::get<T> which uses memcpy to assign the result variable

Change-Id: I129773251c063ea6863c4b2318dbc18574588d99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165728Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67387}

AUTHORS

@@ -213,3 +213,4 @@ Zhao Jiazhong <kyslie3100@gmail.com>
 Zhongping Wang <kewpie.w.zp@gmail.com>
 柳荣一 <admin@web-tinker.com>
 Yanbo Li <lybvinci@gmail.com>
+Gilang Mentari Hamidy <gilang@hamidy.net>
\ No newline at end of file

test/fuzzer/wasm-compile.cc

@@ -79,6 +79,17 @@ class DataRange {
   DISALLOW_COPY_AND_ASSIGN(DataRange);
 };
 
+template <>
+bool DataRange::get<bool>() {
+  // SPECIALIZATION FOR BOOL
+  // The -O3 on release will break the result. This creates a different
+  // observable side effect when invoking get<bool> between debug and release
+  // version, which eventually makes the code output different as well as
+  // raising various unrecoverable errors on runtime. It is caused by undefined
+  // behavior of assigning boolean via memcpy from randomized bytes.
+  return get<uint8_t>() % 2 == 0;
+}
+
 ValueType GetValueType(DataRange* data) {
   // TODO(v8:8460): We do not add kWasmS128 here yet because this method is used
   // to generate globals, and since we do not have v128.const yet, there is no