This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Fix PR tree-optimization/21407
There's no casting between pointers and integers. There are
reinterpet_casts between pointers. The mapping is
implementation-defined, but, in practice, all implementations on, say,
IA32, are going to leave the bit-pattern unchanged.
That's not my point:
A pointer to an object can be explicitly converted to a pointer to an
object of different type. Except that converting an rvalue of type
"pointer to T1" to the type "pointer to T2" (where T1 and T2 are
object types and where the alignment requirements of T2 are no
stricter than those of T1) and back to its original type yields the
original pointer value, the result of such a pointer conversion is
I just don't see anything that says conclusively that this code is
Anything but casting back the pointer to the original type is
implementation-defined. That's also what Microsoft's MSDN documentation
says (http://snipurl.com/ettu): "The result of a reinterpret_cast cannot
safely be used for anything other than being cast back to its original
type. Other uses are, at best, nonportable. [...] One practical use of
reinterpret_cast is in a hash function, which maps a value to an index
in such a way that two distinct values rarely end up with the same
index, [where] the reinterpret_cast allows the pointer to be treated as
an integral type."
So MSDN says that arithmetic is only useful after pointer-to-integer
casts and the MSDN example does *not* cast anything back to a pointer.
Regarding pointer-to-integer casts, the standard says the same: "[the
result of reinterpret_cast of a pointer to integer] is intended to be
unsurprising to those who know the addressing structure of the
underlying machine." But it very clear in saying that "A pointer
converted to an integer of sufficient size (if any such exists on the
implementation) and back to the same pointer type will have its original
value; mappings between pointers and integers are otherwise