Fixes "signed integer overflow: [varies] * 104858 cannot be represented in type 'int'" errors
under ubsan.
Signed-off-by: James Almer <jamrial@gmail.com>
The only multiplicators used in scalarproduct_and_madd_*
are -1, 0 and +1. Yet it is of type int and the checkasm
test uses the complete range of int for it, leading to overflows
that don't happen for actual users.
Fix this by using a more reasonable range for mul: Given
that it is used in v1[i] += v3[i] * mul with v1 being
a 16bit integer, it makes no sense to use values for mul
that don't fit into 16bit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ssd_int8_vs_int16 is only called from encode_block()
in svq1enc.c; it calls it in stages: At stage 0,
the int16_t array contains the difference of two
uint16_t. At each of the following stages, the
int16_t array is filled by subtracting an int8_t from
the current stage's int16_t array. The maximum stage
is five, so the int16_t are in the range
(-255 - 5 * 127)..(255 + 5 * 128).
This commit modifies the checkasm test to only use
values from this range, fixing (undefined) integer overflow
in the test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The requirement is either 8 or 16 bytes alignment, not 32.
This should help finding bugs in asm implementations.
Signed-off-by: James Almer <jamrial@gmail.com>
xHE-AAC relies on the same postfilter mechanism
that Opus uses to improve clarity (albeit with a steeper
deemphasis filter).
The code to apply it is identical, it's still just a
simple IIR low-pass filter. This commit makes it possible
to use alternative constants.
The exclude_guest option only has an effect on x86. Omitting
'exclude_guest' defaults to zero which implies that you can count guest
events should you run one. Some non-x86 kernels just ignore it, while
others (e.g. the Asahi Linux kernels) require the user to explicitly set
the option to 1, i.e. the only behaviour that makes sense when counting
guest events isn't supported.
Signed-off-by: J. Dekker <jdek@itanimul.li>
A namespace is unnecessary here given that all these files
are already in the vvc subfolder.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All versions of MSVC that support C11 (namely >= v19.27)
also support the restrict keyword, therefore av_restrict
is no longer necessary since 75697836b1.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This simplifies the code for checking the output, and can print
the failing output (including a map of matching/mismatching
elements) if checkasm is run with the -v/--verbose option.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Previously it only checked half the output in 8 bit per pixel mode,
as the output actually is 16 bit elements here.
Signed-off-by: J. Dekker <jdek@itanimul.li>
There is no MMX DSP code for VVC, so one can use the stricter
declare_func which also tests that we are not in MMX mode
at the end of this function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise aacenc.o gets pulled in by the aacencdsp checkasm
test and it in turn pulls the rest of lavc in.
Besides being bad size-wise this also has the downside that
it pulls in avpriv_(cga|vga16)_font from libavutil which are
marked as being imported from another library when building
libavcodec as a DLL and this breaks checkasm because it links
both lavc and lavu statically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Contrary to the existing "fate-checkasm", this always prints the
tool output, and runs all tests at once instead of splitting it up
per target group. This is more useful when the user expects to
look directly at the tool output, instead of being part of a full
fate run.
(On failure with the regular "make fate-checkasm" targets, none of
the tool output is printed, but stored in files. If run with reporting
set up to the FATE website, the individual failures are uploaded there,
but if it is run in some sort of other CI setup, the intermediate files
might not be available afterwards for inspection.)
Signed-off-by: Martin Storsjö <martin@martin.st>
