|
45b774e3
|
2017-01-01T18:33:28
|
|
Updated copyright for 2017
|
|
35430a73
|
2016-11-17T01:15:16
|
|
cpuinfo: first attempt at SDL_HasNEON() implementation.
|
|
|
0396af65
|
2016-11-06T14:13:28
|
|
Shifting a value by more than its bits isn't defined and has varying behavior depending on compiler and platform
|
|
|
40b571c9
|
2016-11-06T10:01:08
|
|
Fixed bug 3468 - _allshr in SDL_stdlib.c is not working properly
Mark Pizzolato
On Windows with Visual Studio, when building SDL as a static library using the x86 (32bit) mode, several intrinsic operations are implemented in code in SDL_stdlib.c.
One of these, _allshr() is not properly implemented and fails for some input. As a result, some operations on 64bit data elements (long long) don't always work.
I classified this bug as a blocker since things absolutely don't work when the affected code is invoked. The affected code is only invoked when SDL is compiled in x86 mode on Visual Studio when building a SDL as a static library. This build environment isn't common, and hence the bug hasn't been noticed previously.
I reopened #2537 and mentioned this problem and provided a fix. That fix is provided again here along with test code which could be added to some of the SDL test code. This test code verifies that the x86 intrinsic routines produce the same results as the native x64 instructions which these routines emulate under the Microsoft compiler. The point of the tests is to make sure that Visual Studio x86 code produces the same results as Visual Studio x64 code. Some of the arguments (or boundary conditions) may produce different results on other compiler environments, so the tests really shouldn't be run on all compilers. The test driver only actually exercised code when the compiler defines _MSC_VER, so the driver can generically be invoked without issue.
|
|
98d188f5
|
2016-10-30T21:01:46
|
|
Added call to SDL_HasAVX2() in platform test program.
|
|
|
42065e78
|
2016-01-02T10:10:34
|
|
Updated copyright to 2016
|
|
|
0e45984f
|
2015-06-21T17:33:46
|
|
Fixed crash if initialization of EGL failed but was tried again later.
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().
|