- 01 Mar, 2018 1 commit
-
-
Clemens Hammacher authored
MSVC 2015 and 2017 implement std::is_trivially_copyable, but not correctly. Hence, reimplement it using more low-level primitives. For stdlibc++ versions below 5.0, we already have a workaround for the missing support of std::is_trivially_copyable, but this is an unsound approximation, because it is ignoring move constructor, move assignment and copy assignment. Therefore, do not use this approximation for asserting trivial copyability of a type. Finally, add unittests for the new is_trivially_copyable implementations. R=mstarzinger@chromium.org CC=loorongjie@gmail.com Change-Id: I9ee56a65882e8c94b72c9a2d484edd27963a5d89 Reviewed-on: https://chromium-review.googlesource.com/941521Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51651}
-
- 25 Oct, 2017 2 commits
-
-
Andreas Haas authored
R=mstarzinger@chromium.org Change-Id: Ic36d33ff8d1edeefc745146ec1c1203e08181565 Reviewed-on: https://chromium-review.googlesource.com/737992Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48937}
-
Clemens Hammacher authored
The Float32(uint32_t) constructor should not be public, use Float32::FromBits explicitly if needed. R=ahaas@chromium.org Change-Id: I414e621deebde8cdb474f17e08fcc489dbc083cd Reviewed-on: https://chromium-review.googlesource.com/738173Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48934}
-
- 20 Oct, 2017 1 commit
-
-
Clemens Hammacher authored
This is a reland of 6f93d59d. One more test had to be disabled (tracked by bug 6954), and two machops tests needed to be changed to use boxed floats and doubles. Original change's description: > [test] Add nan bit patterns to uint{32,64}_vector > > If you just cast those patterns to float or double and pass them > around, the quiet/signaling NaN bit might change. We had several bugs > around this, so add these patterns to the general input vectors. > > This uncovers a bug in the wasm interpreter, which will be fixed in a > separate CL. > > R=ahaas@chromium.org > > Bug: v8:6947, v8:6954 > Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0 > Reviewed-on: https://chromium-review.googlesource.com/725345 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48731} Bug: v8:6947, v8:6954 Change-Id: I9a38b5d9324131c3950c537910371a73c93d2c13 Reviewed-on: https://chromium-review.googlesource.com/728439Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48780}
-
- 17 Oct, 2017 1 commit
-
-
Clemens Hammacher authored
This prepares fixes in the implementations of vabs and vneg (potentially more). In order to implement them correctly, we need to preserve the exact bit pattern. R=ahaas@chromium.org, rodolph.perfetta@arm.com Bug: v8:6947 Change-Id: I7194a60371a6e3c9ffba32981c90090ffafaa610 Reviewed-on: https://chromium-review.googlesource.com/722941Reviewed-by: Rodolph Perfetta <rodolph.perfetta@arm.com> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48648}
-
- 21 Jul, 2017 1 commit
-
-
Andreas Haas authored
The class Float32 stores the bit pattern of a float as uint32_t to guarantee that the exact bit pattern of the contained value is preserved. This is necessary because the bit pattern of a NaN may change, e.g. when it is passed as a parameter. For convenience the Float32 class provides a constructor with a float parameter. Since this constructor cannot guarantee that the right bit pattern will be stored for NaNs, this CL adds a DCHECK now to make sure that the constructor is never used with a NaN. R=mstarzinger@chromium.org Change-Id: Iba85a5a1bb2778d5f8bdc1aad97524ef8369b73d Reviewed-on: https://chromium-review.googlesource.com/579367 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46811}
-
- 20 Jul, 2017 1 commit
-
-
Andreas Haas authored
Apparently the name float.h causes problems on Windows when V8 is compiled with Visual Studio, see the bug description. R=clemensh@chromium.org Bug: v8:6588 Change-Id: Iaa9c1e93e62509a779f1a8ddecbb03a53981cf8a Reviewed-on: https://chromium-review.googlesource.com/578029Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#46791}
-
- 07 Jul, 2017 1 commit
-
-
Andreas Haas authored
This CL changes for floats what https://chromium-review.googlesource.com/c/558964/ changed for doubles. Original message: On x86, signalling NaNs get converted to quiet NaNs when they get push on the stack and popped again. This happens in the code generation for arm, specifically for the vmov instruction with the immediate parameter. This CL replaces the vmov function in assembler-arm to take the immediate as a uint64_t instead of a double, to guarantee that the bit pattern does not change even if the parameter is a signalling NaN. New in this CL: Although src/double.h existed already, src/float.h did not exist yet. I created the file in this CL, and moved the classes Float32 and Float64 there, which already existed in src/deoptimizer.h. R=titzer@chromium.org, martyn.capewell@arm.com, v8-arm-ports@googlegroups.com BUG=v8:6564 Change-Id: I6a3f1f154af9c8cd4bb8e7e856235d3eee5e9edd Reviewed-on: https://chromium-review.googlesource.com/561009 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46473}
-