dependabot[bot] authored 1 year ago and Jean-Marc Valin committed 1 year ago

Bumps [gitpython](https://github.com/gitpython-developers/GitPython) from 3.1.36 to 3.1.41.
- [Release notes](https://github.com/gitpython-developers/GitPython/releases)
- [Changelog](https://github.com/gitpython-developers/GitPython/blob/main/CHANGES)
- [Commits](https://github.com/gitpython-developers/GitPython/compare/3.1.36...3.1.41

)

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Rudi Heitbaum authored 1 year ago and Jean-Marc Valin committed 1 year ago

fixes:
  ../meson.build:322:9: ERROR: Unknown variable "opus_arm_may_have_dotprod"

after:
  dotprod check passes through.

Checking if "compiler supports gcc-style inline assembly" compiles: YES
Checking if "assembler supports EDSP instructions on ARM" compiles: YES
Checking if "assembler supports ARMv6 media instructions on ARM" compiles: YES
Checking if "assembler supports NEON instructions on ARM" compiles: YES
Checking if "assembler supports DOTPROD instructions on ARM" compiles: NO
Program perl found: YES (/usr/bin/perl)
Fetching value of define "__APPLE__" : (undefined)
Checking if "compiler supports ARMv7/AArch64 NEON intrinsics" : links: YES
Checking if "compiler supports AArch64 NEON intrinsics" : links: NO
Checking if "compiler supports AArch64 NEON intrinsics with -mfpu=neon" : links: NO
Message: Compiler does not support AArch64 NEON intrinsics
Checking if "compiler supports AArch64 DOTPROD intrinsics" : links: NO
Checking if "compiler supports AArch64 DOTPROD intrinsics with -march=armv8.2-a+dotprod" : links: NO
Message: Compiler does not support AArch64 DOTPROD intrinsics

refer:
- https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/exploring-the-arm-dot-product-instructions



test with:
armv7ve-none-linux-gnueabihf-gcc test.c
/tmp/cc02sooK.s: Assembler messages:
/tmp/cc02sooK.s:32: Error: bad instruction `udot v0.4s,v1.16b,v2.16b'

aarch64-none-linux-gnu-gcc test.c
/tmp/ccnVi9Ec.s: Assembler messages:
/tmp/ccnVi9Ec.s:12: Error: selected processor does not support `udot v0.4s,v1.16b,v2.16b'

aarch64-none-linux-gnu-gcc -march=armv8.2-a+dotprod test.c

Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Rudi Heitbaum authored 1 year ago and Jean-Marc Valin committed 1 year ago

fixes:

testfile.c:3:11: warning: missing terminating " character
    3 |   __asm__(".arch armv5te
      |           ^
testfile.c:4:1: error: expected string literal before '.' token
    4 | .object_arch armv4t
      | ^
testfile.c:5:14: warning: missing terminating " character
    5 | qadd r3,r3,r3");
      |              ^

Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Rudi Heitbaum authored 1 year ago and Jean-Marc Valin committed 1 year ago

fix the following test in the meson.build

stderr:
testfile.c:6:34: error: expected ')' before '::' token
    6 |__asm__ (""::)
      |        ~  ^~
      |           )
testfile.c:6:37: error: expected ';' at end of input
    6 |__asm__ (""::)
      |              ^
      |              ;
-----------
Checking if "compiler supports gcc-style inline assembly" compiles: NO

refer:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045



Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Rudi Heitbaum authored 1 year ago and Jean-Marc Valin committed 1 year ago

meson does mot support output with paths; add a meson.build file in the arm
directory. The output files were being incorrectly placed in the celt/ directory.

Program arm/arm2gnu.pl found: YES (/var/media/DATA/home-rudi/LibreELEC.kernel11/build.LibreELEC-H3.arm-12.0-devel/build/opus-v1.5.1/celt/arm/arm2gnu.pl)
Configuring celt_pitch_xcorr_arm-gnu.S with command

../celt/meson.build:51:25: ERROR: configure_file keyword argument "output" Output 'arm/armopts.s' must not contain a path segment.

before:
celt/celt_pitch_xcorr_arm-gnu.S

after:
celt/arm/celt_pitch_xcorr_arm-gnu.S
celt/arm/armopts.s
celt/arm/armopts-gnu.S

Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

It's just an internal gcc/clang type

Thanks to Robert Clausecker <fuz@FreeBSD.org> for the patch.

The MSVC implementations already was, but the others were not.
This is an implementation detail that should not have external
 visibility.
The public interface is opus_select_arch().

MSVC doesn't have a real __m128i_u, so it would generate an aligned
store, resulting in a segfault. Adding explicit loadu/stureu
intrinsics to make sure the compiler generates unaligned load/store

Tristan Matthews authored 1 year ago and Jean-Marc Valin committed 1 year ago

These were not being included in the tarball in spite of being referenced.

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Martin Storsjö authored 1 year ago and Jean-Marc Valin committed 1 year ago

clang exposes this intrinsic even in 32-bit mode, if targeting >= armv8,
whereas gcc does not, see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95399


Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Only manage to warn on non-pointers

Many new features, API still compatible

silk_burg_analysis() could return a slightly negative value on zero
input, which would cause a negative, which the log didn't like.

Without the fix, ubsan would complain about some of the
NULL pointer checks from test_opus_api.

Added proper saturation and rounding

Michael Klingbeil authored 1 year ago and Jean-Marc Valin committed 1 year ago

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Matches the C code and avoids undefined behaviour

Rudi Heitbaum authored 1 year ago and Jean-Marc Valin committed 1 year ago

cc.get_define returns str (not bool)

Fixes:
Fetching value of define "__APPLE__" :
../meson.build:316:12: ERROR: Object <[StringHolder] holds [str]: ''> of type str does not support the `bool()` operator.

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

It was breaking badly for PLC.

-fargan-synthesis not -fargan_synthesis

Used to be disabled for LM==0 because of the unreliable energy in
one-bin bands. Now we just used the max with the previous energy to
stabilize things.