[Python-Dev] ANSI strict aliasing and Python

[Tim Peters]

[Tim]
>> This is strange (according to me).  The real point of adding that
>> option would be to prevent bad code generation in the presence of
>> pretty common non-standard C code, but I don't know why a compiler
>> would complain about PyObject_IsTrue:
> [...]
>> 	if (v == Py_True)   THIS IS LINE 1565 FOR ME

[martin@v.loewis.de]
> 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.

> Py_True is
>
> #define Py_True ((PyObject *) &_Py_TrueStruct)
>
> where _Py_TrueStruct is of type PyIntObject. A PyObject* could never
> ever possibly point to a PyIntObject.

I don't buy that because C simply doesn't define the result of

    (PyObject *) &_Py_TrueStruct

Since it's undefined, a compiler would be within its rights to create a
pointer that happened to (or not to) compare equal to any other particular
PyObject *, or to segfault, or whatever.

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.

> If you still compare the two, you obviously assume the language is not
> standard C.

Indeed we do.  If we had to, we could cast both sides of such comparisons to
char* first.  The result of that is defined (they have to point to the
"lowest-addressed byte of the object", and that's exactly what we intend get
compared in these cases).  So I'm not worried about the specific things gcc
is complaining about -- they could be wormed around with mechanical pain, so
are just nuisances.  I'm more worried about real problems <wink>:

>> The way in which Python fakes inheritance by hand means there are
>> potential problems all over the place (just about everywhere we cast
>> to or from PyObject*), but very likely very few real problems.  If
>> the only ones gcc complains about involve Py_{True,False,None}, it's
>> not being helpful.

> These are the ones that gcc recognizes. It can and will generate bad
> code all over the place.

Has anyone tried running Python compiled without no-strict-aliasing?  If so,
how bad was it?  I expect that Python's

    call
    test
    branch

    call
    test
    branch
    ...

coding style inhibits most reordering optimizations anyway.

The other question is whether no-strict-aliasing prevents such
optimizations.  If it does, then we should probably always use it.

programmers-who-want-aggressive-anti-aliasing-assumptions-should-
    stick-to-fortran-ly y'rs  - tim