This is the default when building with the clang built-in assembler,
but not if using the external assembler - thus always specify it,
for clarity.
Also use the three-operand for of a sub instruction in BS_NZC_CHECK.
The same is already done in the gnu version of the macro.
This fixes building most of the arm assembly with Apple's external
assembler. While this isn't a necessary goal in itself, there's no
harm in doing this either.
Interpreting data of one type via a pointer of a different type is an
aliasing violating. This means that a compiler optimizer's analyzer
can assume that data loaded into an array as uint32_t isn't related
to data read out from the same array as uint64_t, and e.g. reorder
loads/stores.
Since these structs are intentionally used to load data via pointers
of a wrong size, tell the compiler that these accesses may alias
other reads.
This fixes the GetIntraPredictorTest tests of WelsI4x4LumaPredV_c
and WelsI4x4LumaPredH_c. (The compiler optimizer did the wrong thing
as long as WelsFillingPred8to16_c or WelsFillingPred8x2to16_c were
inlined into the calling function.)
We don't use the ftime function on unix for filling SWelsTime anyway,
we fill the time and millitm fields manually.
On android, the sys/timeb.h header has been removed in the next
platform version (currently available in NDK r10 in the "L preview"
release), since this header and the ftime function have been removed
from the POSIX 2008 specification.
This fixes compilation when targeting the Android "L preview" release,
even when targeting the 32 bit ABIs.
This header is included by crt_util_safe_x.h whenever necessary (it's
all hidden in the SWelsTime struct) - code which does not explicitly
use things from sys/timeb.h shouldn't include it.
Since Xcode 5.1, the apple tools actually support using the
official, correct syntax for the ext instructions. This syntax
is already used in a number of places already - use it consistently,
and get rid of the compatibility hacks.
On 64 bit kernels, /proc/cpuinfo doesn't list the same old features
as on 32 bit kernels, since most of them are mandatory on 64 bit arm
systems, see [1] for details.
If running a 32 bit arm binary on such a kernel, we need to detect
the features slightly differently, either by using other names
listed in the Features field on these devices, by checking the
"CPU architecture" field and always enabling these if the architecture
is >= 8, or by parsing /proc/self/auxv or using the getauxval function.
[1] http://marc.info/?l=linux-arm-kernel&m=139087240101974
The pFeatureC pointer is an uint32_t pointer, therefore only
load 32 bits into ecx.
This avoids loading potentially uninitialized data into the upper
half of the rcx register, fixing valgrind warnings in some build
setups (depending on how the compiler chooses to layout the stack
in the calling function).
The logging level is checked in welsCodecTrace anyway.
Previously, error logging wasn't ever shown if the trace
level was set to WELS_LOG_ERROR (as it was by default),
since welsStderrLevelTrace required the message level to
be strictly lower than the trace level.
