Re: Stanard compliant bit-casting
On Mar 12, 12:19 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Mar 12, 1:56 am, James Kanze <james.ka...@gmail.com> wrote:
[...]
So, when the union is in scope, gcc "does the right thing",
and when reinterpret_cast is in scope, gcc does not "do the
right thing".
Which is, from a QoI point of view, an error.
It's an error if you believe that those are the desired semantics.
Error may not be the best word in this case, since it implies
something unintentional. My argument is, precisely, that from a
QoI point of view, the desired semantics are the only ones which
make sense.
In fact, I don't know whether this is an error in the coding,
a problem in the way that the optimizer works which would make
it difficult (and perhaps not worth it) to fix, or simply a bit
of stubborness on the part of g++ developers. It does mean that
reinterpret_cast is useless, which is certainly not the intent
of the committee.
I would argue that it's the gcc team's stubbornness to follow the
standard as written.
I suspect that you're right. Which is, IMHO, an error from a
QoI point of view: the standard gives implementations a lot of
leeway, but from a QoI point of view, some common sense is to be
expected.
I cannot speak to the intent of the committee, nor can most
users of C++. However, we can speak to what the standard
clearly says. That said, it is somewhat silly to provide type
punning when the union is in scope but not allow type punning
when a cast is in scope.
Exactly. The standard makes both undefined behavior. In the
case of unions, this is intentional (if I recall and interpret
correctly discussions I followed during the standardization of
C); the goal is to allow hidden discriminators. Again, if I
recall and interpret such discussions correctly, the motivation
for undefined behavior in the case of reinterpret_cast (or a
pointer case in C) is that the "reasonable" behaviors in the
case of dereferencing such a cast are in fact impossible to
specify in a portable way, but that the committee expected the
implementations to do what is reasonable for whatever the
platform was.
Keeping in mind in all of this that the committee also wanted to
allow the compiler to deduce as much as possible with regards to
anti-aliasing. We have a definite conflict in the goals here,
and the standard is, regretfully, not really as clear as we'd
like with regards to how to resolve this conflict.
I think it makes a little more sense if we say that they're
simply following current practice, and this is how most other
compilers do it. (Again, confirmation or evidence to the
contrary anyone?)
As I mentionned, Microsoft C 1.0 ignored any aliasing due to
unions, but did respect that resulting from casts.
That g++ does provide additional guarantees for unions is, IMHO,
a positive point, since in fact, before the C standard, that was
the traditional solution, and it is still widespread.
The issue isn't simple. Historically (pre-ISO C), the union was
the preferred solution, at least from what I understood. For
whatever reasons, the ISO C committee (or at least the parts of
it which formallized the wording in this regard) designed to
make type punning via a union undefined behavior, which means
that only casting remains. The C++ committee simply followed
the C committee in this respect---I'm 100% sure that the intent
of the C++ committee is that a reinterpret_cast, when legal,
behave exactly the same as a cast in C.
Repeating for emphasis:
I'm 100% sure that the intent of the C++ committee is that a
reinterpret_cast, when legal, behave exactly the same as a
cast in C.
I agree with that. I cannot speak to the intent of the
committee(s) as you can, but I can speak to what they wrote,
and the standard is quite clear that the C-style cast does not
get around the strict aliasing rule, and thus reinterpret_cast
does not get around the strict aliasing rule.
See above. There are two motivations for undefined behavior.
In addition, there is a note (non-normative) in the C++ standard
(=A75.2.10/3) concerning the mapping done by reinterpret_cast: "it
is intended to be unsurprising to those who know the addressing
structure of the underlying machine". Although this note is
directly attached to the pointer to integer conversion, in the
absense of any other indications, it seems reasonable to me to
apply it to the other uses of reinterpret_cast as well.
There is no such absence in the C++ standard. It is very clear that
accessing an object through an lvalue of a sufficiently different type
is undefined behavior (except for the char and unsigned exception, and
the common leading part of POD exception).
It is also clear that dereferencing the result of an arbitrary
int, converted to a pointer, is undefined behavior. I think it
reasonable to apply the same text to both: "it is intended that
the results be unsurprising to those who know the addressing
structure of the underlying machine."
Note that while these words are only used for the conversions
between integral types and pointers in the standard, it is easy
to extend them (for most implementations, anyway) by using an
intermediate cast:
double d;
short* ps = reinterpret_cast<short*>(
reinterpret_cast<long long>(&d));
This is with regards to the cast, and it's immediate use. I do
think that the intend was that in a function:
void f(int* pi, double* pd)
, the compiler should be allowed to assume no aliasing between
pi and pd (even though it is possible to construct cases where
the standard doesn't allow this).
The section you cite, including the normative note, is a very
narrow exception which states that a reinterpret_cast on a
pointer will produce an rvalue whose value should not be
surprising to those who know the addressing structure of the
underlying machine.
Exactly. Any use of reinterpret_cast must be considered
unportable (except to and from character type pointers).
This in no way is an exception to the strict aliasing rule.
Instead, in this context reinterpret_cast takes one value of a
certain type and casts that value to another type. It does not
tell the compiler that two different pointers alias or in any
way affect the strict aliasing rule.
No. And any use of the resulting pointers is undefined behavior
according to the standard. There's no disagreement there. The
question is what the motivation for this undefined behavior is,
why it is there, and what we should expect from a QoI point of
view.
In any case, the current standard is very unclear with
regards to type punning---with the exception of character
types. And I don't think that this has changed in the more
recent drafts---in a very real sense, I think that it is
more a C problem; that the C++ committee should simply wait,
and adopt whatever the C committee finally decides.
Now, I don't know any other compilers offhand which
optimize with the strict aliasing allowance besides newer
gcc versions,
I don't know of any that don't. It's a common optimization.
It was present in Microsoft C 1.0, for example (in which
your union example would break).
Really? I was under the impression that basically no Microsoft
compiler actually optimized with the strict aliasing
allowance,
Current compilers certainly don't do the same optimizations that
Microsoft C 1.0 did. In some cases, they do a lot more, but in
a few special cases, they do less. (There is no common code
from 1.0 in the current compilers.) However...
that too much windows code would break if it did by default.
Very simple testing like that above seems to show that the
Microsoft compiler does not.
I've not done too much testing with regards to how the Microsoft
compiler does aliasing analysis, but the fact that it does
optimize better than g++ (for Windows platforms) leads me to
think that it does use the anti-aliasing rule. Or that the
anti-aliasing rule doesn't really buy much in practice, and
should perhaps be dropped. (I've not tried special test cases,
but from what little I've looked at, I suspect that most of the
aliasing which causes problems for optimization involves
pointers of the same type, so ignoring the anti-aliasing rule
actually has no impact with regards to optimizating. In which
case, from a QoI point of view, the compiler should ignore it,
and suppose that all pointers may alias.)
but I would suggest you revise your understanding of the
QoI implications of reinterpret_cast.
Why? My understanding of the QoI implications are based on the
actual words in the standard, and the various discussions that
I've followed in the standardization committees.
My previous argument succinctly: C-style casts were never
intended to get around strict aliasing.
Yes and no. An optimizer is expected to use the knowledge at
its disposal. If it can see that there is aliasing, whether
from a union or a cast, it should take it into account.
That is, by the way, the direction the C committee was going the
last time I looked.
reinterpret_cast was never intended to be more powerful than
C-style casts.
Certainly not. But since the C style cast should behave as
expected, when visible, so should the reinterpret_cast.
I cannot speak to your private discussions with the
committees. It's just that's not what's in the current
standards.
Just for the record, it's not private discussions, in the sense
of just me and the committee. Any member of the committee can
view them.
As for the current standards, the "anti-aliasing" rule doesn't
allow any optimizations, because of the following case:
int f(int* pi, double* pd)
{
int retval = *pi;
*pd = 3.14159;
return retval;
}
void main()
{
union { int i; double d; } u;
u.i = 42;
f(&u.i, &u.d);
std::cout << u.d << std::endl;
return 0;
}
According to the strict words of the current standard, this is
guaranteed to output 42. In practice, if the compiler applies
the anti-aliasing rule in f, it may assign *pd before actually
reading *pi, which will result in a wrong output.
The current wording of the standard guarantee this. IMHO, this
is not the intent, and the discussions in the C committee lead
me to believe that there will be a clarification in this
respect. In the meantime, however, we are left speculating with
regards to the intent of the standard.
But regardless of the words in the standard, common sense says
that if I explicitly say that there is aliasing (and that is
what reinterpret_cast says), then the compiler shouldn't assume
that there isn't.
(The named casts were each intended to fulfill a specific role
of the several roles of C-style casts to remove potential
ambiguity to the code writer and readers.) Thus
reinterpret_cast was never intended to get around strict
aliasing.
You seem to be misunderstanding the motivation behind the strict
aliasing rule. It is to allow the compiler to assume no
aliasing in cases where it otherwise couldn't. There was never
any intent to allow the compiler to totally ignore aliasing that
it can clearly see.
Perhaps I was too strong. However, I don't think it's right to
be so dismissive of that position. It is a reasonable one.
Many times I hear "The compiler should just be smart enough",
but many times this is not the case, for various reasons, such
as too hard to implement, or the semantics would be too vague
or not well defined, or it would be bad style and confusing to
the coders. I think all kinds of "type punning but only in
certain scopes [unions and casts]" qualify.
The issue is, obviously, not a simple one for compiler
implementers. There is a definite motivation to generate the
fastest code possible, and a number of "undefined behavior" in
the standard are present precisely to allow the compiler
implementer the most freedom possible to do so. My argument is
simply that reinterpret_cast is, or should be, a red flag: the
programmer is effectively telling the compiler that he knows
something that the compiler doesn't. And that the compiler
should respond in consequence, and not ignore what the
programmer is telling it. (And IMHO, reinterpret_cast should be
rare enough that even turning off all optimization in a function
that uses it shouldn't matter.)
--
James Kanze