Visual Studio doesn't define __ARM_ARCH nor _ARM_NEON, but _M_ARM and _M_ARM64,
so SDL_HasNEON() was bypassed.
PF_ARM_NEON_INSTRUCTIONS_AVAILABLE doesn't see to be defined (but still works
when defined as 19).
Only __ARM_NEON is defined with Android NDK and arm64-v8a
Tested on ndk-r18, ndk-r13 and also Xcode.
(Visual Studio needs a different fix).
Fixes Bugzilla #4409.
Luke Dashjr
Bug 3993 was "fixed" by #undef'ing bool. But this breaks C99's stdbool.h bool too.
For example, mpv's build fails with:
../audio/out/ao_sdl.c:35:5: error: unknown type name ?bool?
It seems ill-advised to be #undef'ing *anything* here - what if the code including SDL_cpuinfo.h actually wants to use altivec?
Felix Geyer
Forwarding from https://bugs.debian.org/892087 quoting verbatim:
The SDL2 header SDL_cpuinfo.h generates gcc warnings if the program using
it compiles with the -Wundef warning. (In particular, this means that QEMU
builds using it fail on at least sparc hosts, since QEMU dev builds
use both -Wundef and -Werror.).
/usr/include/SDL2/SDL_cpuinfo.h:63:5: warning: "HAVE_IMMINTRIN_H" is not defined, evaluates to 0 [-Wundef]
#if HAVE_IMMINTRIN_H && !defined(SDL_DISABLE_IMMINTRIN_H)
bastien.bouclet
According to this GCC bug report, altivec.h requires building with the gnu extensions: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78263.
As an application developer, I don't want SDL to force me to enable the gnu extensions.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
