similar to: FLAC__SSE_OS change

Erik de Castro Lopo wrote: > I actually think my change is correct. It should be easier to see if you > look at the github version of the change: > > https://github.com/xiph/flac/commit/e120037f3c67b23fd9eef7ccd04d2df57fa1a9a6#diff-9f048b83ff55071de36263cf0f403b2eL209 > FLAC__NO_SSE_OS was never defined anywhere, so I think that the following changes should be made:

lvqcl wrote: > Erik de Castro Lopo wrote: > >> I actually think my change is correct. It should be easier to see if you >> look at the github version of the change: >> >> https://github.com/xiph/flac/commit/e120037f3c67b23fd9eef7ccd04d2df57fa1a9a6#diff-9f048b83ff55071de36263cf0f403b2eL209 >> P.P.S. 1) if FLAC__SSE_OS==1 then MSVC cannot compile current

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

This patch moves all info->ia32.fxsr = info->ia32.sse = info->ia32.sse2 = info->ia32.sse3 = info->ia32.ssse3 = info->ia32.sse41 = info->ia32.sse42 = false; expressions into a static function disable_sse(FLAC__CPUInfo *info). -------------- next part -------------- A non-text attachment was scrubbed... Name: simplify_cpu_c.zip Type: application/zip Size: 1163 bytes Desc:

configure.ac still has two places that aren't fully correct: 1) it creates incorrect definition of FLAC__HAS_X86INTRIN in config.h file. 2)AM_CONDITIONAL(FLaC__SSE_OS...) compares sse_os with 'true' instead of 'yes'. -------------- next part -------------- A non-text attachment was scrubbed... Name: conf_ac.patch Type: application/octet-stream Size: 1074 bytes Desc: not

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

Bryan Levin reported a problem of the FreeBSD flac port dumping core on FreeBSD 4.x: http://sourceforge.net/tracker/index.php?func=detail&aid=1099004&group_id=13478&atid=113478 It turns out that the port enabled SSE support, but FreeBSD 4.x does not support SSE by default. (FreeBSD 5.x and later do.) I have added a small patch to the port to check at runtime whether the system

lvqcl wrote: ... > P.S. I wonder what's the point to test OS SSE support in 2016? I believe > that > users of Windows 95 and Windows NT4 don't expect new software to work on > their > OSes. I do (although I am often disappointed). Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/

yErik de Castro Lopo wrote: > I think I've fixed both those in: > > commit 23778a3a6018f5dcb5fc1ad6ac97ad8391afc69d > Author: Erik de Castro Lopo <erikd at mega-nerd.com> > Date: Sat Jun 25 17:02:06 2016 +1000 > > libFLAC/cpu.c: More pre-processor cleanups > > > I've tested on this in x86, x86_64, powerpc and armhf linux as well as

On 06/25/16 10:43 PM, Erik de Castro Lopo wrote: > 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: >>

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,

lvqcl wrote: > No, FLAC__AVX_SUPPORTED is 0 (initially it's undefined, then inside cpu.h > it's defined as 0). > > MSVC cannot discard unused references in debug builds and when LTCG is on, > for example: <http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html> > > And currently LTCG is enabled for release builds. Ok, thats a problem. A large

lvqcl wrote: > Sure. > > The question is, what to do with the debug configuration. <sigh/> Is this only a problem with MSVS2005? If so, I'd be inclined to jsut drop support for it. Its over 10 years old and aren't there free versions of more recent MSVCs available? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo

Erik de Castro Lopo wrote: >> The question is, what to do with the debug configuration. > > <sigh/> > > Is this only a problem with MSVS2005? No, MSVC 2015 is also affected. I renamed __cpuid() to __cpuid22(), and it wrote: error LNK2019: unresolved external symbol ___cpuid22 referenced in function _FLAC__cpu_info_x86 fatal error LNK1120: 1 unresolved externals So, all

lvqcl wrote: > No, MSVC 2015 is also affected. I renamed __cpuid() to __cpuid22(), I thought the original problem was with `___cpuidex`, not `__cpuid`! Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

lvqcl wrote: > No, FLAC__AVX_SUPPORTED is 0 (initially it's undefined, then inside cpu.h > it's defined as 0). > > MSVC cannot discard unused references in debug builds and when LTCG is on, > for example: <http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html> > > And currently LTCG is enabled for release builds. Ok, I think I've fixed it

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 26 June 2016 at 10:17, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > For OS support, I'm not sure. Didn't later version of SSE add new > registers? No, SSE instructions operate on XMM0-8 on i386 and XMM0-15 on amd64, respectively. Register width was increased to 256 bit with the introduction of AVX (YMM0-8 on i386 and YMM0-15 on amd64, respectively) but their

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

lvqcl wrote: > It doesn't know about uint32_t type, so the definition of cpu_xgetbv_x86() fails. > It can be fixed by adding "#include share/compat.h" to cpu.c (or by using > FLAC__uint32 from FLAC/ordinals.h). Ok, added share/compat.h. > When I fix this, the following problem occurs: > > error LNK2019: unresolved external symbol ___cpuidex referenced in