> I think that's too late for 3.3. It's not a bug fix.

Oops, I chose 3.3 instead of 3.4. Fixed.

> If we use this kind of feature, we either need to declare a minimum supported GCC version

typeof() and __builtin_types_compatible_p() were introduced to gcc in version 3.0 and 3.1.1. Do we plan to support GCC older than 3.1? :-)

> (any GCC older than 10 years can be dropped IMO)

GCC 3.1 was released 10 years ago. It's cheap to add a test on the GCC version to fallback on the simple "x<y?x:y" macro, but I don't know exactly which GCC versions are supported and I don't want to install a very old GCC version just to check this.

> Did you detect any errors in the Python code using this change?

Nope. But it avoids at least to evaluate an expression twice (if an argument is not a variable or a number, but a complex expression... like most new PyUnicode_*() macros). Even if I prefer to avoid expressions in macro arguments...

> Wouldn't the compiler refuse to perform the comparison
> if the types were not compatible?

I don't know exactly how __builtin_types_compatible_p() compare types. At least, I can say that int and unsigned int are considered as incompatible.

--

The Linux kernel uses "(void) (&_min1 == &_min2);" to check that types are compatible. I suppose that this expression is written for GCC. GCC only emits a warning, I chose Py_BUILD_ASSERT_EXPR() to emit an error instead.