[Python-Dev] ANSI strict aliasing and Python (original) (raw)

Martin v. L�wis martin@v.loewis.de
19 Jul 2003 03:07:47 +0200

"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 *) &PyTrueStruct

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 :

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