similar to: MSVC ARM compilation issue with patch

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 >

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, 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

_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

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) > >

--- 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) -#elif (defined(_MSC_VER) && _MSC_VER >= 1400) && (defined (WIN64) || defined (_WIN64))

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

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

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

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

I am noticing a problem with Samba not dropping/removing file locks. Here's what I've got: Samba 2.0.6 on a Sun E450 running Solaris 2.6 PC running Win95 and WordPerfect 8 smb.conf is pretty much standard, with oplocks enabled. Here's what happens: A user will open a file, the lock will be set, and even when the file is closed, the lock remains (as confirmed by smbstatus). The

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

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

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

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

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

I built the LLVM 2.2 distribution under Visual Studio for x86-64 just fine, but then trying to run my first "hello world" application, found that the JIT compiler was not enabled. I'm completely new to LLVM, so I didn't know exactly where to look to see why the JIT for my platform wasn't being built (is it in the configure steps, or in the C++ code itself?). My educated guess

Does anyone know if it is possible to use the "printer" with WordPerfect 9-Linux and WINE? I think that I have set up the configuration files correctly, but I don't see the fonts in the application (I don't know if they would print since I cannot select them). Note: my "printer" is GhostScript but WINEPS shouldn't know the difference, and I am using the

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