Speex dev - Jan 2006 - Re: sigsegv in _mm_load_ups (linux/gcc 3.x)

That's definitely strange and I've never encountered that. Normally, the
only way for _mm_load_ups to generate a segfault is for the input to be
invalid memory, in which case the C version should crash too. I suspect
the compiler (or something else) may be hiding the real problem. Can you
get a debugger and see exactly what assembly statement is causing the
crash and what the operands are?

	Jean-Marc
> So, has anyone else seen this issue?
> 
> I am working off svn- the crash is always in the same spot,
> in the decoder, in nb_celp,  in  both filter_mem2
> (if st->lpc_enh_enabled == 1) and iir_mem2 (if == 0)
> 
> The function in question is filter_mem2_10 or
> iir_mem2_10
> 
> _mm_loadu_ps is an unaligned load and all of the
> data seems to be ok, and no sigill- get a sigsegv.
> 
> Same code works fine on windoze.  CPU in question
> is a 2.8 ghz hyperthread- xmm/SSE supported.  C
> versions of same functions solve the issue-  same
> problem with multiple 3.3, 3.4 gcc versions.
> 
> Thanks!
> 
> Tom
> ______________________________________________
> 
> Tom Harper
> Lead Software Engineer
> SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/
> 
> 918 Parker St, Suite A14
> Berkeley, CA 94710
> 
> Email: tharper@sightspeed.com
> Phone: 510-665-2920
> Fax: 510-649-9569
> My SightSpeed Video Link: http://tom.sightspeed.com 
> 
>

> That's definitely strange and I've never encountered that.
Normally, the
> only way for _mm_load_ups to generate a segfault is for the input to be
> invalid memory, in which case the C version should crash too. I suspect
> the compiler (or something else) may be hiding the real problem. Can you
> get a debugger and see exactly what assembly statement is causing the
> crash and what the operands are?
I've seen the exact same in my version (mingw on win32), and the problem 
was that the stack was misaligned when entering the function, so the temp 
registers weren't at 16-byte boundries.

> I've seen the exact same in my version (mingw on win32), and the
problem
> was that the stack was misaligned when entering the function, so the temp 
> registers weren't at 16-byte boundries.
That's a possibility. It's easy to check by printing the address of the
variables. I know that gcc 3.3 had some alignment issues with _m128 that
were supposed to be fixed in version 3.4 and above.

	Jean-Marc