[Python-Dev] Py_DECREF causes spurious gcc warning

[Zack Weinberg]

"Tim Peters" <tim.one at comcast.net> writes:

> [Zack Weinberg]
>> I thought you might come back at me with that.  Yes, you can avoid the
>> syntax error by carefully leaving off the semicolon here.  I don't
>> consider this to be good style, though.  It's easy to forget, and it's
>> easy for someone to come along later and be confused and check in an
>> 'obvious' patch that adds a semicolon - and it might not even break
>> anything... then.
>
> Zack, you have to be kidding.  Martin was clearly talking about the
> expansion of Py_DECREF specifically, not "macros in general", as also was
> the poster who started this thread.

I, however, was never speaking about Py_DECREF specifically.  I
thought this was clear from previous statements but I apologize for
the confusion.

>> I'm speaking about general style principles, and I really do think it is
>> good style *always* to wrap complex macros in do { } while (0) whether
>> or not they need it.
>
> Py_DECREF doesn't need it; there may be some point to it if doing so shuts
> up gcc nuisance complaints, and we can be sure that the extra complexity of
> the expanded code doesn't provoke optimization bugs in any of the C
> compilers used to compile Python.  Writing non-loops *as* loops is a good
> way to tickle endcase bugs in sophisticated optimizers -- it's not without
> risk, and there are several thousand instances of Py_DECREF and Py_XDECREF
> just in the core.  Also because it's used a lot, in a debug build such a
> change would generate a ton of useless extra instructions (at least MSVC
> really does generate code to create a zero, test it against zero, and jump
> back to the top of "the loop" if zero doesn't equal zero; I expect that most
> C compilers would).

I doubt both statements just because this is a standard C idiom.
Recognizing it and generating no extra code falls naturally out 
of basic constant-condition detection, which I would expect to
be present in any modern compiler, - and done even in "debug
builds" because it can't hurt and in fact usually makes the
compiler run faster (less junk intermediat code to process).
I especially doubt that this construct will tickle bugs in
sophisticated optimizers -- it would be harder to get it 
wrong than to get it right.

I am not disputing that MSVC does this silly thing you describe, but
MSVC has a long track record of bugs and poor code generation.  GCC
does not generate junk code even at -O0.

zw