similar to: Two questions about RG in flac

On 6/3/14, Robert Kausch <robert.kausch at freac.org> wrote: > Am 03.06.2014 16:45, schrieb lvqcl: >> 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

Am 03.06.2014 16:45, schrieb lvqcl: > 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 GCC? ) I further reduced the testcase (attached). The bug only occurs if N >= 64;

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

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: > I just built FLAC and noticed that the size of flac.exe is noticeably bigger, > so I compared the generated Makefiles before ang after this change. > > The difference is: "-g -O2" options were added to CFLAGS. > > before: > CFLAGS = -O3 -funroll-loops -Wall -W -Winline -Wall -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Waggregate-return

Martijn van Beurden wrote: > op 25-07-14 19:32, Scott Brown schreef: > > ./configure -enable-static -disable-shared CFLAGS=" -isysroot > > /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6" > > make > > Well, the use of CFLAGS 'disables' the -O3 and unroll-loops > optimisation. I'm quite sure that's the culprit. Add -O3 to your

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,

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

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 src/libFLAC/cpu.c. 2. "configure" build

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

Hello! Asterisk "CVS-HEAD-08/06/04-14:55:13" won't start on two of three different Gentoo machines. This is the output of gdb: ultra asterisk # gdb /usr/sbin/asterisk GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.

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?

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

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)

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

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

2009/9/16 Olivier Meurant <meurant.olivier at gmail.com>: >         Average 13836499.46     12447973.17     1388526.29      10.03 >         Standard deviation      53189.13        515638.56 > 522400.98       3.77 That was pretty much what I was expecting from the article... numbers. It doesn't matter who's best, you can't be best in all areas, but profiling must be

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

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