similar to: Questions about libFLAC and SSE/SSE2/...

Erik de Castro Lopo wrote: > lvqcl.mail wrote: >> now. Removing OS check will greatly simplify src/libFLAC/cpu.c. > > That makes sense. Should I post a patch that removes OS check and keeps only CPU check? >> 2. >> "configure" build system adds -msse2 option by default. It means that >> x86 (32-bit) library won't work on older, non-SSE2

lvqcl.mail wrote: > 1. > A program can use SSE instructions only if both CPU and OS support SSE. > Currently libFLAC tests both CPU and OS for this support, but is it really > necessary? Maybe CPU check is enough? Operating systems that don't support > SSE (Win95, WinNT 4.0, Linux kernel 2.2 (iirc), ...) are really outdated > now. Removing OS check will greatly simplify

Hi, I am trying to build R 2.2.1 with Kazushige Goto's BLAS library (libgoto) and encountered a problem: I have two computers with the almost identical hardware (P4 Northwood CPU, i875 chipset, 2GB DDR400 RAM) and identical Linux OS. I have the latest version of libgoto for this CPU installed on both boxes (libgoto_northwood32p-r1.00.so) and I am using gcc compiler flags "-O2

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > The biggest of these tweaks weas to disable the intrinsics version > fero FLAC__CPU_IA32 because I couldn't get this to compile on > i386-linux (and we have the nasm versions). Still open to re-enabling > this if someone can get it to work. I know you're a skilled programmer, but... maybe you forgot to add -msse

Thomas Zander wrote: > In any case, the disable-SSE matter is still important. People are > still using flac on x86 machines without SSE, for instance AMD Geode > CPUs seem to live forever. libFLAC detects CPU SSE support in runtime, so --disable-sse is necessary for cuch CPUs only because it disables -msse2 switch. Maybe it makes sense to add new switch, --no-force-sse2 or

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: >> -msse for SSE code, -msse2 for SSE2 code, -msse4.1 for SSE4.1 code > > Yes, that was it. Brain fart. These flags were not needed on x86_64. > > Erik But now all C code is compiled with -msse2 and it won't work on older CPUs. Isn't it better to compile only necessary files with this flag?

Dave Yeo wrote: >>> >on other OSes: >>> > --enable-sse: >>> > add -msse2 to the compiler switches >>> > test SSE OS support (why?) >>> >It's a bit contradictory: why test whether *BSD etc support SSE or not >>> >but at the same time allow compiler to use SSE/SSE2 unconditionally? >> Yes,

First off, this code is horrible to read and work on. The recent commits are the first of what I hope is a massive clean up of this code. lvqcl wrote: > So if I understand things correctly, the current meaning of --(en|dis)able-sse is: > > on Linux: > --enable-sse: > add -msse2 to the compiler switches > do not test SSE OS support (assume that SSE is

lvqcl wrote: > 1) if FLAC__SSE_OS==1 then MSVC cannot compile current cpu.c: > "#include <windows.h>" line is inactive and MSVC complains: > cpu.c(278): error C2065: 'EXCEPTION_EXECUTE_HANDLER': undeclared identifier > cpu.c(279): error C2065: 'STATUS_ILLEGAL_INSTRUCTION': undeclared identifier > > 2) the current code (simplified): > >

1) to the author of test/test_replaygain.sh There are 2 identical lines in this file: line 137 and next. Is it intended or just a copy/paste error? 2) to ALL: I attached a small program. Compile and run it. * Does it work correctly when compiled with -O3 -msse2 options? * If yes, does it work correctly when compiled with -O3 -funroll-loops -msse2 options? ( and what is the version of your

Dave Yeo wrote: > Doesn't SSE support imply SSE2+ support? Not for the CPU. Just because a CPU supports SSE, does not mean it is guaranteed to support SSE2+. For OS support, I'm not sure. Didn't later version of SSE add new registers? > I have a '96 install of an OS, it has been upgraded until end of life, > and it handles SSE4+ instructions fine even though the

It's not possible to use ia32/*.nasm code in 64-bit compiles. There's still no 64-bit asm code in FLAC. I'm not familiar with asm too, so I wrote SSE-accelerated code using intrinsics. This code uses two new preprocessor macros: FLAC__CPU_X86_64 (analogous to FLAC__CPU_IA32) and FLAC__HAS_X86INTRIN (analogous to FLAC__HAS_NASM) Patch for cpu.c/cpu.h adds CPU features (sse3, ssse3)

Jean-Marc, Are you sure that you don't need to add just -msse to enable the intrinsics rather than a full fledged -march=pentium3? I did some playing around and I can get intrinsics code to compile with -march=i686 -msse on linux with that. Check out:

On 03/09/15 03:59 PM, lvqcl wrote: > Tristan Matthews wrote: > >> >Unable to test on win32 at the moment, please give this a try. Feedback welcome. > > I wonder why misaligned stack is a problem only for the FLAC library. > There are many other libraries inside VLC... > > BTW: FLAC 1.3.1 uses -msse2 option by default. Do you remove it? > Otherwise libFLAC may crash

Unable to test on win32 at the moment, please give this a try. Feedback welcome. Avoids crashes due to unaligned ops when built with mingw. --- src/libFLAC/include/private/cpu.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/libFLAC/include/private/cpu.h b/src/libFLAC/include/private/cpu.h index 8927897..bd40012 100644 --- a/src/libFLAC/include/private/cpu.h +++

On 03/14/16 03:51 PM, lvqcl wrote: > With --disable-sse, FLAC__SSE_OS is undefined and FLAC__cpu_info() uses > sigemptyset/sigaction to determine OS SSE support. That's not quite right as I have to build binaries with --disable-sse (I build and distribute both with and without) so that some users on PII's don't get a sigill, even though the OS supports SSE. So it seems to

On Sat, Mar 12, 2016 at 2:38 PM, Tim Northover <t.p.northover at gmail.com> wrote: > On 12 March 2016 at 11:51, Rail Shafigulin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I tried every possible combination of --target I could think of but > nothing > > worked. Would you mind helping me out? > > First, 64-bit x86 is "x86_64", and 32-bit

Current sources (git-b1b6caf) were compiled with GCC 4.8.2 and GCC 4.9.0 with various -msseN options (the default is -msse2). Then I took two WAV files (one is 16-bit and the other is 24-bit) and compressed them using best compression mode. The results are in the table below. (please remember that the resulting value is an encoding time, not encoding speed) CPU: Intel Core i7 950 (up to SSE4.2)

I'm getting the following error when compiling OpenCV 2.0 with OpenMP and SSE intrinsics enabled with GCC+DragonEgg(newest SVN version): /usr/lib64/ccache/c++ -Wall -Wno-long-long -pthread -ffunction-sections -D_GLIBCXX_PARALLEL -fopenmp -D__STDC_CONSTANT_MACROS -fplugin=/home/John/Documents/Project/DragonEgg/dragonegg/dragonegg.so -O3 -DNDEBUG -fomit-frame-pointer -O3 -ffast-math -mmmx

What do you base this on? Per https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html : "For the x86-32 compiler, you must use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default." That reads to me like we're fine for SSE2. As stated in my comments, SSSE3 support must be