On 2014/03/28 11:59:58, jbramley wrote:
https://codereview.chromium.org/213943002/diff/20001/src/arm64/simulator-arm64.h
File src/arm64/simulator-arm64.h (right):
https://codereview.chromium.org/213943002/diff/20001/src/arm64/simulator-arm64.h#newcode179
src/arm64/simulator-arm64.h:179: } reg = { new_value };
On 2014/03/28 11:46:04, Sven Panne wrote:
> On 2014/03/27 19:58:33, Fritz wrote:
> > I'm specifically trying to type-alias here in a safe way. [...]
>
> I don't think that such a thing is possible: IIRC, the only defined way
of
using
> a union is accessing its fields consistently, i.e. read only out of the
field
> you have last written into, everything else is totally undefined (at
least
this
> was the definition for C). Or in other words: The only safe way to use a
union
> is to save space, not to do some funny casting/conversion tricks.
It seems to be allowed in C99 TC3 (dated the September 2007-09-07). See
section
6.5.2.3, page 73: "If the member used to access the contents of a union
object
is not the same as the member last used to store a value in the object,
the
appropriate part of the object representation of the value is
reinterpreted as
an object representation in the new type [...]"
from [...] == "as described in 6.2.6 (a process sometimes called "type
punning"). This might be a trap representation."
Which I read as not allowed.
I can't find any reference in the C++ spec, so I will assume that it is
also not
defined.
I don't think it was allowed in TC2, but I don't have it to hand.
> Has this changed in C++? If yes, could somebody point me to the right
section
of
> the spec? It would be good to know, because I'm quite sure we already
had
> trouble in this area.
I don't think it's allowed in C++98 but I can't find a clear bit of the
specification that says that. However, it does have a rather surprising
note
on
reinterpret_cast suggesting that reinterpret_cast<T&>(x) can be used to
safely
do type-punning. I'd not seen this before, and every resource I've seen
until
now has said that this is _not_ safe. This (draft) standard is dated
2005-10-19
and I'm not sure where I got it from.
I still think that the only _portable_ way to do it is to use memcpy;
that's
safe in every version of the standards, but the rules are rather more
relaxed
than I previously thought.
void Set(T new_value) {
int64_t* value = reinterpret_cast<int64_t*>(&new_value);
value_ = value;
}
won't work because the size of the read is different. If it was originally
a
float, I'm now stuck with the upper 32 bits having random data.
Get() will work fine with this construct because the original value was 64
bits,
so all reads 64bits or less are going to be correct.
memcpy, even with fixed size, is still a slower.
base : 5:31
memcpy : 4:03
union : 3:52
Does this adversely impact the possible use of Q registers in the future to
not
be worthwhile?
https://codereview.chromium.org/213943002/
--
--
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.
