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

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!