[Python-Dev] ANSI strict aliasing and Python

[Martin v. Löwis]

"Tim Peters" <tim.one@comcast.net> writes:

> > Notice that a compiler is allowed to infer that the test is always
> > false.
> 
> I don't buy that.  I'll buy that the result of the comparison is undefined
> by C, and that a hostile implementation of C could arbitrarily decide to
> call all such expressions false -- or arbitrarily decide to call all such
> expressions true.

You are right: it is undefined, so an implementation that always gives
false might still be conforming. The closest statement to defining
behaviour is 6.3.2.3p7:

# A pointer to an object or incomplete type may be converted to a
# pointer to a different object or incomplete type.  If the resulting
# pointer is not correctly aligned57) for the pointed-to type, the
# behavior is undefined.  Otherwise, when converted back again, the
# result shall compare equal to the original pointer.

So if you convert two pointers to the same PyIntObject to PyObject*,
and convert them back, then compare them, you are guaranteed to get
true. If you compare them while they are PyObject*, no guarantees are
given.

> I don't buy that because C simply doesn't define the result of
> 
>     (PyObject *) &_Py_TrueStruct

Again: agreed.

> But that's not the point I was trying to make:  the text of the warning
> message Neil quoted warned about dereferencing, but there is no
> dereferencing going on in the line it's complaining about.

So the message is confusing: I agree.

> I'm more worried about real problems <wink>:

But gcc is pointing to a real problem. It is just that it cannot, in
general, detect the real problem. As the real problem is wide-spread,
it makes a best effort approach in guessing what programs might show
undefined behaviour.

As it turns out, in the case of Python, the compiler is right: There
is undefined behaviour with respect to PyObject*. We could cheat the
compiler to fail to recognize our bad cade, but it still would be bad
code.

> Has anyone tried running Python compiled without no-strict-aliasing?  If so,
> how bad was it?

The current change was primarily triggered by the messages. No single
bug was tracked down to gcc generating bad code in such cases.

> The other question is whether no-strict-aliasing prevents such
> optimizations.  

It does. gcc then assumes that any pointer may alias with any other.

> If it does, then we should probably always use it.

We do.

Martin