[Python-Dev] Py_DECREF causes spurious gcc warning (original) (raw)

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 .

More information about the Python-Dev mailing list