When building 2.3.3 on Solaris using Studio 11 and
"-xalias_level=std" to enable ISO C99 pointer aliasing
rules, the interpreter would core dump when running
test_descr2.py.  From examining the source, I believe
this problem exists in 2.4.2 as well, but did not
verify it.

I was able to simplify the code to invoke the problem
down to:
====
class C1(object):
   def __new__(cls):
       return super(C1, cls).__new__(cls)

a = C1()
====

I tracked the problem to super_init() in
Objects/typeobject.c.

The local variable "obj" is of type "PyObject *" and
"type" is of type "PyTypeObject *".  In this function,
both variables can be pointing to the same object in
memory.  Since the pointers are not of compatible
types, the compiler ends up optimizing out a memory
load between Py_INCREF(obj) and Py_INCREF(type) caching
a previously read value.  This causes the object
reference counter to only be incremented once instead
of twice.  When the object is deallocated, the
interpreter blows up.

A workaround is to cast one of the pointers to the
others type so that the compiler can see the pointer
aliasing potential.  This is what I did in the patch.

What I suspect needs to be done as a more global fix is
to discontinue use of the PyObject_VAR_HEAD macro hack.
 Casting between structures containing this macro
creates ISO C99 pointer aliasing violations.  The
contents of the macro needs to be in its own structure
which is referenced so a compliant compiler can know of
 possible aliasing.