Displaying 20 results from an estimated 10000 matches similar to: "[PATCH] for cpu.h"
2016 Jun 28
2
Please test more libFLAC/cpu.c changes
lvqcl wrote:
> Found a bug in Android OS SSE test.
Sorry, what is the bug and how does this fix it?
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
2016 Jun 30
2
Please test more libFLAC/cpu.c changes
lvqcl wrote:
> Erik de Castro Lopo wrote:
>
> >> Found a bug in Android OS SSE test.
> >
> > Sorry, what is the bug and how does this fix it?
>
> FLAC__cpu_info(FLAC__CPUInfo *info): detects CPU features
> that can be used and sets corresponding flags in the info
> struct.
This code is in flux and in the current state the logic probably
has
2014 Aug 07
1
[PATCH] for cpu.c
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:
2013 Sep 24
1
PATCHES for cpu.h/cpu.c
The first patch adds SSE4.1/SSE4.2 detection.
The second patch removes union data in struct FLAC__CPUInfo and
replaces it with #ifdefs. Reason: currently it's possible to set or
get data.ia32.sse3 value from x86-64 code, etc. It's a potential
source of errors (at least that's true for me).
(the 2nd patch requires the 1st to be applied)
-------------- next part --------------
A
2015 Nov 06
1
[PATCH] for FLAC__cpu_info() in cpu.c
Function FLAC__cpu_xgetbv_x86() is declared and defined only
if FLAC__HAS_X86INTRIN is defined. But now FLAC__cpu_info()
tries to call it even if FLAC__HAS_X86INTRIN is undefined,
which results in link error. This patch fixes the bug.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpu_xgetbv.patch
Type: application/octet-stream
Size: 653 bytes
Desc: not
2016 Mar 14
2
Broken build on musl libc
On 14 March 2016 at 09:02, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:
> commit a9f84425cfd5d1dbfb564730ca80d0b588cb4f24
> Author: Erik de Castro Lopo <erikd at mega-nerd.com>
> Date: Mon Mar 14 18:14:31 2016 +1100
>
> libFLAC/cpu.c: Use `sigemptyset` instead of `__sigemptyset`
>
> The former is POSIX while the later is a GNU
2019 Aug 18
1
1.3.3: powerpc portability problems
The PowerPC-related changes in FLAC 1.3.3 have caused some portability
problems.
libFLAC/cpu.c assumes that the <sys/auxv.h> header and the getauxval()
function are universally available on PowerPC platforms. They are not.
On FreeBSD/powerpc, <sys/auxv.h> is available, but getauxval() is
not. Equivalent functionality is provided by elf_aux_info().
On OpenBSD/powerpc, neither is
2013 Aug 21
2
PATCH for cpu.c
1) Some time ago all project files for MSVC 6 were removed; it makes sense to remove the code that is necessary only for MSVC 6 and older compilers.
--- a\src\libFLAC\cpu.c 2013-08-13 13:30:24.000000000 +0400
+++ b\src\libFLAC\cpu.c 2013-08-16 21:46:42.177485300 +0400
@@ -285,14 +285,7 @@
# ifdef USE_TRY_CATCH_FLAVOR
_try {
__asm {
-# if _MSC_VER <= 1200
- /* VC6 assembler
2014 Mar 21
1
PATCH for cpu.c
Explanation of changes in this patch:
1)
'CALLBACK' was changed to 'WINAPI' because the signature of
an unhandled exception filter is
LONG (WINAPI *unhandled_func)(struct _EXCEPTION_POINTERS);
2)
The code
if(info->ia32.fxsr || info->ia32.sse || info->ia32.sse2) {
[...]
}
was replaced by
if(info->ia32.sse) {
[...]
}
else
2016 Mar 14
1
Broken build on musl libc
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
2014 Jul 27
1
[PATCH] remove obsolete cpu_info from struct FLAC__BitReader
In FLAC 1.2.0, a new field 'FLAC__CPUInfo cpu_info' was added to the
struct FLAC__BitReader. It became useless in 1.3.0 because of
various bitreader optimizations. The first patch removes it
and also removes FLAC__CPUInfo argument of FLAC__bitreader_init() function.
The second patch removes a comment about struct FLAC__BitReader.
It seems that it should really belong to
2013 Sep 08
7
PATCH: x86-64 support and SSE intrinscis code
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)
2004 Sep 10
1
checking OS support for SSE
Here is patch for checking OS SSE support for systems
having vfork()/fork() function.
Index: src/libFLAC/cpu.c
===================================================================
RCS file: /cvsroot/flac/flac/src/libFLAC/cpu.c,v
retrieving revision 1.8
diff -u -r1.8 cpu.c
--- src/libFLAC/cpu.c 2001/07/18 00:24:46 1.8
+++ src/libFLAC/cpu.c 2001/07/27 08:57:04
@@ -21,6 +21,20 @@
2017 Feb 20
0
Flac build issue in debug win x32
Here is a patch that fixes the issue.
There are multiple way to fix it though.
Le 14/02/2017 à 15:08, Olivier Tristan a écrit :
> Hi Guys,
>
> The following code in CPU.c (line 155) won't link if you don't have
> NASM code built even if FLAC__HAS_X86INTRIN is true as
> FLAC__cpu_info_asm_ia32 don't exists and the else is compiled if there
> is no dead code
2014 Nov 26
2
Changelog: improved decoding
There's an entry in the changelog:
"Improved decoding efficiency of all bit depths but especially so for 24 bits (lvqcl)"
A couple of comments:
1) The patch that improves encoding for all depths was proposed by Miroslav Lichvar
<http://git.xiph.org/?p=flac.git;a=commit;h=4eab6313cd2198b5647d925bdb3847590505fa21>
2) "Performance checks" graph posted by Martijn van
2016 Dec 03
2
Q: test for CPUID instruction presence
I found that FLAC__cpu_have_cpuid_x86() was removed in the commit
<http://git.xiph.org/?p=flac.git;a=commitdiff;h=fa24613ad94ba8fb8e23bcb9ca80b4548bb617e6>
with the message:
"Remove `FLAC__cpu_have_cpuid_x86` altogether as it wasn't actually
being used but that was difficult to tell because of all the #ifdef
nonsense."
But FLAC__cpu_have_cpuid_x86() actually WAS used
2018 Jul 10
9
[PATCH 0/7] PowerPC64 performance improvements
The following series adds initial vector support for PowerPC64.
On POWER9, flac --best is about 3.3x faster.
Amitay Isaacs (2):
Add m4 macro to check for C __attribute__ features
Check if compiler supports target attribute on ppc64
Anton Blanchard (5):
configure.ac: Remove SPE detection code
configure.ac: Add VSX enable/disable
configure.ac: Fix FLAC__CPU_PPC on little endian, and add
2015 Dec 29
2
FLAC__BYTES_PER_WORD==8 test results
I wrote a patch that enables FLAC__BYTES_PER_WORD==8 in
libFLAC/bitreader.c and libFLAC\bitwriter.c.
The tests were done on an Intel Nehalem CPU, and flac was compiled
with CGG 4.9.x.
Average speed increase for FLAC__BYTES_PER_WORD change from 4 to 8:
Decoding speed:
ia32 architecture
16-bit .flac: -15%
24-bit .flac: -11%
x86-64 architecture
16-bit .flac:
2016 Dec 05
1
Q: test for CPUID instruction presence
Erik de Castro Lopo wrote:
> lvqcl.mail wrote:
>
>> Currently libFLAC doesn't check the existence of CPUID instruction if
>> FLAC__HAS_X86INTRIN is set to 1.
>> It's not a real problem because x86 CPUs without CPUID are probably
>> extinct, but if libFLAC performs this check then it should do it
>> in all cases (when NASM is available or intrinsics are
2014 Mar 19
3
building issue on OSX GCC 4.2 / Xcode
Hi Guys,
The current trunk do not build with GCC 4.2 on OSX when compiling cpu.c
<cpuid.h> does not exists and __get_cpuid() is not defined
This version of GCC is required if you want to support pre 10.7 systems
which are still pretty common.
It seems other project had the same issue
https://bugzilla.mozilla.org/show_bug.cgi?id=836824
Don't know much what would be the right fix.