similar to: Pointer size bugs when compiling for android arm64?

Hi all, I'm sending patch "Optimize silk_warped_autocorrelation_FIX() for ARM NEON" in an separate email. It is based on Tim’s aarch64v8 branch https://git.xiph.org/?p=users/tterribe/opus.git;a=shortlog;h=refs/heads/aarch64v8 Thanks for your comments. Linfeng

I rebased my previous 3 patches to the current master with minor changes. Patches 1 to 3 replace all my previous submitted patches. Patches 4 and 5 are new. Thanks, Linfeng Zhang

+Artem Belevich <tra at google.com> On Fri, Mar 23, 2018 at 7:53 PM Bharath Bhoopalam via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I was wondering if anyone has encountered this issue when cross compiling > cuda on Nvidia TX2 running android. > > The error is > In file included from <built-in>:1: > In file included from >

I was wondering if anyone has encountered this issue when cross compiling cuda on Nvidia TX2 running android. The error is In file included from <built-in>:1: In file included from prebuilts/clang/host/linux-x86/clang-4667116/lib64/clang/7.0.1/include/__clang_cuda_runtime_wrapper.h:219: ../cuda/targets/aarch64-linux-androideabi/include/math_functions.hpp:3477:19: error: no matching function

Hi Xiph.org Team. We are using opusfile library <https://github.com/xiph/opusfile> for streaming *.opus* audio in our projects. But now we have a problem with building opusfile library for android with *ndk-build*. In particular, with arm64-v8a platform: Google removed <sys/timeb.h> from android. And now building opusfile with nkd-build crashes with error "fatal error:

Hello LLVMdev!! Yesterday I posted a patch request to the llvm-commits list requesting that someone could apply a patch to Triple.h and Triple.cpp for me. I didn't get any response so I wondered whether I should have posted to this list instead. My story is as follows: we are trying to get lldb/llvm support for CSRs range of Kalimba DSPs. Eventually we are planning to hire someone to

Jonathan, Here's the code difference we see with the recent change -- what amounts to reverting your change from a couple years back. It doesn't look like we're getting superfluous instructions from clang now. the bad behavior for us was the alignment exception on the movdqa instructions when the input data wasn't 128-bit aligned. We had to change something because the code as-is

Hm, yes — with the current Xcode clang (Xcode 8.3.3, Apple LLVM version 8.1.0 (clang-802.0.42)), I don’t see any difference in the generated code with -O2 between the two versions. (Literally none for x86_64, and only what seem to be some non-signficiant offset changes for i386). So if this improves some other cases (notably, it should avoid problems with -fsanitize=address) I think this is

Dear list, git checkout llvmorg-8.0.0 -b llvm8.0 cmake -G "Unix Makefiles" ../llvm-project/llvm -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;ARM;AArch64" [arm.cpp] #define vst4_lane_f16(__p0, __p1, __p2) __extension__ ({ \ float16x4x4_t __s1 = __p1; \ __builtin_neon_vst4_lane_v(__p0, __s1.val[0],

Hi On AArch64 (ARM 64-Bit Platform), I see there is an inconsistency in the values accepted by -march option between clang and llc. --- $ llc -march=aarch64 -mattr=help 2>&1 | grep error $ #No Error $ llc -march=armv8a -mattr=help 2>&1 | grep error llc: error: invalid target 'armv8a'. $ clang -march=armv8a -E - < /dev/null 2>&1 | grep error $ #No Error $

Hello everyone, It took a bit longer than planned, but Release Candidate 3 is now here. It was tagged as llvmorg-10.0.0-rc3 on the release branch at 3a843031a5 and contains 95 commits since the previous release candidate. If no new problems arise, this is what the final release will look like. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc3 and

--_e6765d9c-a0eb-4881-9b60-b9820e4c5665_ Content-Type: multipart/alternative; boundary="_520e6e4d-4f2c-47c0-83c1-2fa2fb28184f_" --_520e6e4d-4f2c-47c0-83c1-2fa2fb28184f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Murdoch=2C Attached file is the error message after installing 2.7.1/ or it patched wi= ndow version. After

We see the MOVQ instruction but this patch deliberately uses it rather than MOVQDA (load 128-bits aligned). We were seeing that with the trace below, the final invocation is not 128-bit aligned but MOVQDA insists on it (the calling function was pitch_sse4_1.c:90, in the 4-way N - i >= 4 loop). 07-31 11:00:13.469 210 2540 <(469)%20210-2540> D opus_sse1: RBE celt_inner_prod_sse4_1: x

Hello everyone, We're a little bit behind schedule, but RC1 is now here. It was tagged earlier today as llvmorg-11.0.0-rc1. Source code and docs are available at https://prereleases.llvm.org/11.0.0/#rc1 and https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc1 Pre-built binaries will be added as they become available. Please file bug reports for any issues you find as

Signed-off-by: Scott Seago <sseago at redhat.com> --- AUTHORS | 17 ++++++ README | 10 +++ conf/ovirt-agent | 12 ++++ conf/ovirt-db-omatic | 12 ++++ conf/ovirt-host-browser | 12 ++++