Rework the code choosing BLAKE2 code paths from using the optimized
variant on all x86_64 machines to using it when SSSE3 or better
supported instructions sets are available.
Firstly, this solves the problem of using pure SSE2 code path on x86_64
machines. As reported in the bug, this code is slower than the reference
code on all tested x86_64 machines. Furthermore, on Athlon64 that lacks
SSSE3, it is even 2.5 times slower than the reference code! Checking
for SSSE3 therefore ensures that the optimized implementation will only
be used when it has a chance of performing better.
Secondly, this makes it possible to use SSSE3+ optimizations on 32-bit
x86 systems. This allows for even 2 times speed gain on modern 32-bit
x86 systems (tested in a 32-bit chroot).
Various platforms have various methods of handling multiarch libffi which probably won't match the previously looked-for defines. Now we just make sure that ffi.h is available.
Add basic fuzz tests for a few common builtin functions.
This is an easy place to start, and these functions are probably safe.
We'll want to add more fuzz tests later. Lets bootstrap using these.
While the fuzz tests are included in CPython and compiled / tested on a
very basic level inside CPython itself, the actual fuzzing happens as
part of oss-fuzz (https://github.com/google/oss-fuzz). The reason to
include the tests in CPython is to make sure that they're maintained
as part of the CPython project, especially when (as some eventually
will) they use internal implementation details in the test.
(This will be necessary sometimes because e.g. the fuzz test should
never enter Python's interpreter loop, whereas some APIs only expose
themselves publicly as Python functions.)
This particular set of changes is part of testing Python's builtins,
tracked internally at Google by b/37562550.
The _xxtestfuzz module that this change adds need not be shipped with binary distributions of Python.
As of Xcode 7, SDKs for Apple platforms now include textual-format stub
libraries whose file names have a .tbd extension rather than the
standard OS X .dylib extension. The Apple compiler tool chain handles
these stub libraries transparently and the installed system shared libraries
are still .dylibs. However, the new stub libraries cause problems for
third-party programs that support building with Apple SDKs and make
build-time decisions based on the presence or paths of system-supplied
shared libraries in the SDK. In particular, building Python itself with
an SDK fails to find system-supplied libraries during setup.py's build of
standard library extension modules. The solution is to have
find_library_file() in Distutils search for .tbd files, along with
the existing types (.a, .so, and .dylib). Patch by Tim Smith.
Michał Górny
Benjamin Peterson
Antoine Pitrou
Shlomi Fish
Devin Jeanpierre
Stefan Krah
Victor Stinner
xdegaye
Neil Schemenauer
Xavier de Gaye
INADA Naoki
Christian Heimes
Zachary Ware
R David Murray
Vinay Sajip
doko@ubuntu.com
Martin Panter
Ned Deily
Serhiy Storchaka