On 2014/09/19 06:07:26, Sven Panne wrote:
https://codereview.chromium.org/576973003/diff/1/test/cctest/compiler/test-run-properties.cc
File test/cctest/compiler/test-run-properties.cc (right):
https://codereview.chromium.org/576973003/diff/1/test/cctest/compiler/test-run-properties.cc#newcode53
test/cctest/compiler/test-run-properties.cc:53:
static_cast<double>(value_a) +
static_cast<double>(value_b);
Casting away volatile leads to undefined behavior:
Section 7.1.6.1 The cv-qualifiers
... If an attempt is made to refer to an object defined with a
volatile-qualified type through the use of a glvalue
with a non-volatile-qualified type, the program behavior is undefined.
Why was it introduced here at all? Trying to avoid some compiler
optimizations?
If that was the intention, that won't work in general.
Actually the volatile is probably not strictly necessary, but in this case
it is
not "casting away" the volatile, it's actually performing an explicit
conversion
from uint32_t to U, which mirrors the truncation that is done by the store
to
the typed array in the JavaScript code. Unlike static casts from uint32_t to
int8_t and others as previous in this test, C++ doesn't define the
precision of
intermediate results, so this change was to force the compiler to convert to
64-bit double and 32-bit float in those respective instantiations of this
test
function.
https://codereview.chromium.org/576973003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
