When test_assert_path_exists or test_fail_if_path_exists
was used on a function containing a CompilerDirectivesNode
it was inherited by that CompilerDirectivesNode. Therefore
you got misleading test failures if the path was in the
function but not within that CompilerDirectivesNode.

* Fix #3588: Make existing overflow code safe

Signed overflow is undefined behaviour in C and compilers can and do optimized on that basis.

* Speed up our overflow impls

Note this is primarily based on performance of compilers which do not
support __builtin_add_overflow (i.e., not Clang >= 3.4 & gcc >= 5),
mostly looking at several gcc 4 releases (used by older, supported,
RHEL releases and Debian 8 "Jessie") and MSVC.

* Use __builtin_XXX_overflow if available

This is much quicker in general, as these all just then read the overflow flag from the status register.

Disable GC during hacked calls to PyType_Ready() that simulate a heap type for an actual non-heap type, because it can lead to crashes if GC visits such a hacked type.
Closes https://github.com/cython/cython/issues/3603

Disable GC during hacked calls to PyType_Ready() that simulate a heap type for an actual non-heap type, because it can lead to crashes if GC visits such a hacked type.
Closes https://github.com/cython/cython/issues/3603

Reduce the code overhead of the memoryview implementation a little by disabling CyFunctions for its methods.

Reduce the code overhead of exception raising in generated Cython code and the memoryview code by avoiding explicit calls to create the exception and prepared constant argument tuples. "raise Exc, message" can do this implicitly.

Move less common ref-counting cases for memory views out of the fast-path and only look up the atomic acquisition count value once per INC/DEC operation.

When it's merged into the main module, wrap it in a CompilerDirectivesNode.

Also mark the case of an uninitialised memory view slice as "unlikely()" when refcounting it since it's most probably not a performance critical case.

Mark the last deletion of a memory view slice as "unlikely()" to ask the C compiler to optimise for the repeated re-use case (usually in loops).

Mark the first creation of a memory view slice as "unlikely()" to ask the C compiler to optimise for the repeated re-use case (usually in loops).

Fix up the NumPy warnings hack by using the actual "import_array()" function declaration instead of a wrong one.

Also mark the case of an uninitialised memory view slice as "unlikely()" when refcounting it since it's most probably not a performance critical case.

Mark the last deletion of a memory view slice as "unlikely()" to ask the C compiler to optimise for the repeated re-use case (usually in loops).