[Python-Dev] ANSI strict aliasing and Python

Tim Peters tim.one@comcast.net
Sun, 20 Jul 2003 21:16:53 -0400


[Martin]
> ...
> But gcc is pointing to a real problem. It is just that it cannot, in
> general, detect the real problem.

Perhaps it can't now, but it *could* know when it's reordering loads and
stores, and doing so because of anti-aliasing assumptions.  There simply
isn't a real problem unless it's doing that (by "real problem" I don't mean
a violation of a formal rule, but an actual case of code generation that
doesn't match our intent).

> As the real problem is wide-spread,

By my meaning of "real problem", as I've said before I doubt there are many
instances of it.

> 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.

In the comparisons it's complaining about, casting the comparands to char*
first would yield standard-conforming code with the semantics we intend.

I haven't seen a real example of anything else in Python it might be worried
about (I assume Neil's example was made up), so nothing else to say about
those.

>> 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.

Thanks for the confirmation!