[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!