similar to: [PATCH] float_cast: Fix MSVC ARM build

_WIN32, WIN32, WIN64, and _WIN64 are the wrong definitions to be gating this on in the first place. They aren't at all meant to be x86/x86-64 specific. At best, they're 32-bit/64-bit specific, but that's not the intended use in the code. The correct definitions are _M_IX86 and _M_X64, as Martin said. I sent a patch to this ML that fixed these a few months ago but it was

Yeah that's the one. On Nov 6, 2014 1:23 PM, "Tristan Matthews" <le.businessman at gmail.com> wrote: > On Thu, Nov 6, 2014 at 4:20 PM, Cameron Gutman <aicommander at gmail.com> > wrote: > > _WIN32, WIN32, WIN64, and _WIN64 are the wrong definitions to be gating > this > > on in the first place. They aren't at all meant to be x86/x86-64 >

On Thu, Nov 6, 2014 at 4:20 PM, Cameron Gutman <aicommander at gmail.com> wrote: > _WIN32, WIN32, WIN64, and _WIN64 are the wrong definitions to be gating this > on in the first place. They aren't at all meant to be x86/x86-64 specific. > At best, they're 32-bit/64-bit specific, but that's not the intended use in > the code. The correct definitions are _M_IX86 and

Is there any consensus on what's the correct fix here? Jean-Marc On 06/11/14 04:26 PM, Cameron Gutman wrote: > Yeah that's the one. > > On Nov 6, 2014 1:23 PM, "Tristan Matthews" <le.businessman at gmail.com > <mailto:le.businessman at gmail.com>> wrote: > > On Thu, Nov 6, 2014 at 4:20 PM, Cameron Gutman > <aicommander at gmail.com

On Thu, 6 Nov 2014, Hugo Beauz?e-Luyssen wrote: > --- > celt/float_cast.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/celt/float_cast.h b/celt/float_cast.h > index ede6574..4892e2c 100644 > --- a/celt/float_cast.h > +++ b/celt/float_cast.h > @@ -90,14 +90,14 @@ > #include <math.h> > #define float2int(x) lrint(x) > >

Hi All, Cortex-M4 is a single issue CPU whereas A8 is dual issue so this is the main reason you are seeing a slow-down, use of NEON I would say is secondary, certainly for CELT. We (ESPICO) have done optimisation work on OPUS v1.1 and have ARM implementations about twice the speed of the 'off the shelf' version. Please contact me directly if you want to discuss further. Cliff

Hi Jean-Marc, I've been compiling CELT for 64-bit Windows and it all seems to work fine (with the occasional benign warning message) except for one place, and that is in "float_cast.h" where there is some inline assembly language that gets complied for Windows. Since the Microsoft 64-bit compiler won't allow inline assembly language (and *still* doesn't have

On Thu, 6 Nov 2014, Jean-Marc Valin wrote: > Is there any consensus on what's the correct fix here? Cameron's fix looks correct to me (I didn't read the code closely enough in my first comment). // Martin

The following tiny patches make opus and opusfile to use xmm intrinsics for lrintf() with mingw-w64 builds when targetting x64 instead of their default x87 asm. Regards. -- O.S. diff --git a/celt/float_cast.h b/celt/float_cast.h index ed5a39b..b9b8484 100644 --- a/celt/float_cast.h +++ b/celt/float_cast.h @@ -61,7 +61,14 @@ ** the config.h file. */ -#if (HAVE_LRINTF) +#if

Hi Marcus, Thanks for the fixes. I did some more cmake build testing and encountered a few issues: The option -DFORTIFY_SOURCE=2 should be -D_FORTIFY_SOURCE=2, as the macro has a leading underscore. In the autotools build it defines this if it is not already defined (m4/ax_add_fortify_source.m4). When custom modes are not enabled, the cmake build is nevertheless installing the include file

On Mon, 10 Nov 2014, Hugo Beauzee-Luyssen wrote: > On 11/06/2014 10:55 PM, Martin Storsj? wrote: >> On Thu, 6 Nov 2014, Jean-Marc Valin wrote: >> >>> Is there any consensus on what's the correct fix here? >> >> Cameron's fix looks correct to me (I didn't read the code closely enough >> in my first comment). >> > > That looks good

On 11/06/2014 10:55 PM, Martin Storsj? wrote: > On Thu, 6 Nov 2014, Jean-Marc Valin wrote: > >> Is there any consensus on what's the correct fix here? > > Cameron's fix looks correct to me (I didn't read the code closely enough > in my first comment). > > // Martin > _______________________________________________ > opus mailing list > opus at

From the neighbouring list, http://lists.xiph.org/pipermail/opus/2014-April/002592.html "proper architecture-specific MSVC definitions, _M_IX86 and _M_X64" So this patch changes _WIN64 to _M_X64 (the corresponding code enables _BitScanReverse64) -------------- next part -------------- A non-text attachment was scrubbed... Name: bitmath.patch Type: application/octet-stream Size: 938

I?ve been working on a Windows Phone 8 app that uses libopus for audio decoding. I used the included MSVC project files by switching the toolchain to WP8?s. I ran into a compilation issue in float_cast.h where it was trying to use the MSVC x86 code path (with x86 assembly). This was because WIN32 and _WIN32 are defined in ARM projects for WP8 libraries (for source compatibility reasons I assume).

On Wed, Apr 10, 2019 at 5:30 PM Marcus Asteborg <xnorpx at outlook.com> wrote: > Hi Mark, > > Thanks for the feedback. > > By default CMake is building the static library in debug, to get other > things one has to explicit turn it on. > > Hi, By default CMake uses the "empty" build, which is used in combination with the environment variables CFLAGS and

Josh Coalson wrote: > for recent code changes I find myself needing some workarounds > for MSVC6: Yep. MSVC is borked. Its missing most of the new maths functions that were introduced in the C99 standard. The way I solved this problem for libsndfile was to stop using MSVC, (allowing it to break for that compiler) and use MinGW. I also release a pre-compiled win32 binary so

for recent code changes I find myself needing some workarounds for MSVC6: 1st, I need a fast way to swap bytes (for endianness) of a 32-bit int. I could not find a builtin like bswap; the closest thing I found was ntohl() which appears to be a function call and also requires linking with winsock2 (ws2_32.lib) to get it. 2nd, I need an equivalent for lround() (or round() is ok), which is not in

From: Thorvald Natvig <slicer at users.sourceforge.net> --- celt.pc.in | 2 +- configure.ac | 2 ++ libcelt/Makefile.am | 12 ++++++------ tests/Makefile.am | 2 +- tools/Makefile.am | 4 ++-- 5 files changed, 12 insertions(+), 10 deletions(-) diff --git a/celt.pc.in b/celt.pc.in index 98cc008..67a830b 100644 --- a/celt.pc.in +++ b/celt.pc.in @@ -10,5

Hi, The attached patch fixes build on Windows/ARM platform, as it doesn't have inline assembly. Regards, -- Hugo Beauz?e-Luyssen hugo at beauzee.fr -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_msvc_build.patch Type: text/x-patch Size: 489 bytes Desc: not available Url :

Okay, so trying a straight compile of the Python interpreter with clang-cl, I used the following commands: cd \python-2.7.10\pcbuild copy C:\llvm\build\Release\bin\clang-cl.exe cl.exe rd /q /s amd64 rd /q /s win32-temp-debug rd /q /s win32-temp-release rd /q /s x64-temp-debug rd /q /s x64-temp-release msbuild /p:Configuration=Release /v:diag /fileLogger pcbuild.sln (The second line is the one