flac dev - Sep 2013 - PATCH: x86-64 support and SSE intrinscis code

Erik de Castro Lopo wrote:
> When should FLAC__HAS_X86INTRIN be defined? What header file should I be
> checking for?
Ah, should be checking for <x86intrin.h>.

The rest seems to be coming together. Testing this now.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Erik de Castro Lopo wrote:
> Erik de Castro Lopo wrote:
> 
> > When should FLAC__HAS_X86INTRIN be defined? What header file should I
be
> > checking for?
> 
> Ah, should be checking for <x86intrin.h>.
> 
> The rest seems to be coming together. Testing this now.
There is a segfault happening in the new code when compiling with
-DDEBUG. Trying to track it down.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Erik de Castro Lopo wrote:
> There is a segfault happening in the new code when compiling with
> -DDEBUG. Trying to track it down.
This turned out somewhat nasty.

The segfault was only happening in the libFLAC++ code and only when
compiled with -DDEBUG. Debugging with GDB and Valgrind only managed
to track the problem down to code where constructors or destructors
would be.

I then added -Weffc++ to CXXFLAGS and found a number of classes which
contained pointer data members but which had no copy constructors or
assignment operator methods. The other problem we related in missing
data member initializers.

Fixing all these issues made the segfault disappear.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Erik de Castro Lopo wrote:
>> > When should FLAC__HAS_X86INTRIN be defined? What header file
should I be
>> > checking for?
>>
>> Ah, should be checking for <x86intrin.h>.
I simply don't know. In MSVS there's no x86intrin.h, but it has
intrin.h.

> There is a segfault happening in the new code when compiling with
> -DDEBUG. Trying to track it down.
I suspect that it's inline asm code for cpuid. It will be replaced with
__get_cpuid().