Building Python 2.4 with icc and processor-specific optimizations

["Martin v. Löwis"]

Michael Hoffman wrote:
> Further investigation reveals that the function that sets
> sys.builtin_module_names sorts the list before turning it into a
> tuple. And binarysort() in Objects/listobject.c doesn't work when
> optimized in that fashion. Adding #pragma optimize("", off)
> beforehand solves the problem. Why that is, I have no idea. Is
> anyone else curious?

I would really like to know, indeed. OTOH, I probably don't have the
time to analyse it myself.

Looks like a compiler bug to me: perhaps, some condition is compile-time
asserted to be always true even though it could happen that it is false.

OTOH, it could also be Python's failure to follow C's aliasing rules
correctly; Python casts between C pointers which, in strict C, causes
undefined behaviour. So if your compiler has something similar to GCC's
-fno-strict-aliasing, you could see whether this helps.

If not, just try comparing the assembler output of either code, on
a function-by-function basis. Alternatively, try to annotate the
calls that go out of the sorting (e.g. to RichCompareBool) so that
you get tracing, and then see where the traces differ.

> Also, if anyone is looking for a way to squeeze a little extra time
> out of the startup, perhaps sorting the list at build-time,
> rather than when Python starts would be good. Although probably
> not worth the trouble. ;-)

Probably not. config.c is hand-written in some (embedded Python)
environments, and expecting it to be sorted would break these
environments.

Regards,
Martin