[Python-Dev] Py_DECREF causes spurious gcc warning

Tim Peters tim.one at comcast.net
Sat Dec 20 17:13:34 EST 2003


[Zack Weinberg]
> I doubt both statements just because this is a standard C idiom.

I worked in compiler development for 15 years, so I'll have to trust my
experience on this.  The union of MSVC and gcc accounts for the vast bulk of
Python installations, but only a fraction of the total number of compilers
in use.  Many optimizers know nothing at all about C specifically, as
they're a common back end for many front-end intermediate code generators,
for many languages.  It's unusual for a compiler to do any sort of
optimization unless optimizations are specifically requested.  I don't have
any gripe with gcc doing some regardless, but gcc isn't the universe.

> Recognizing it and generating no extra code falls naturally out
> of basic constant-condition detection,

No, changing the flow graph is a serious and delicate program
transformation.  A C compiler front end doing it more-than-less
"mindlessly", as part of special-casing the goofy idioms C encourages, has a
fine shot at never screwing up, because it's doing it then before flow graph
construction.  Not all compilers do it that way.

> which I would expect to be present in any modern compiler,

In one way or another, yes, at least optimizing compilers.  Not all
compilers optimize, though.  A possibly important example for Python in the
near future is that the "standard edition" retail .NET compilers have no
optimization capability, and neither does the freely downloadable .NET C/C++
compiler.

> ...
> I am not disputing that MSVC does this silly thing you describe, but
> MSVC has a long track record of bugs

That doesn't match our experience.  I don't believe Python code has ever
tickled an MSVC codegen or optimization bug, neither any in gcc-for-x86.
We've certainly tickled codegen and optimization bugs in gcc for other
platforms, and *many* such bugs in vendor compilers (SGI's native compilers
probably hold the record for sheer quantity of codegen and optimization bugs
when compiling Python).

At Dragon Systems we were using C++ rather than C, and I think MSVC and gcc
were blamed for about an equal number of codegen and optimization bugs.

> and poor code generation.

This also doesn't match our experience.  Release-build Python compiled under
MSVC for x86 has been faster than release-build Python compiled under gcc
for x86 each time I've seen them compared, and the same was true for
Dragon's software.  Maybe gcc is getting better on x86; I don't know; for a
long time it was at a systematic disadvantage because it was originally
designed for RISC-ish architectures with a large, uniform register set, and
x86 is about as from that model as things get.  MSVC had many years'
advantage in dealing with x86's many architecural quirks.

> GCC does not generate junk code even at -O0.

It certainly generates needless code even at -O0.  If it didn't, there would
be no reason to have a higher optimization level than -O0 <wink>.




More information about the Python-Dev mailing list