[ lame-Bugs-3150289 ] Existence of xmmintrin.h does not imply that it is usable

Bugs item #3150289, was opened at 2011-01-03 03:45
Message generated for change (Comment added) made by dmichelsen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=3150289&group_id=290

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: configure/Makefiles
Group: Portability
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dagobert Michelsen (dmichelsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Existence of xmmintrin.h does not imply that it is usable

Initial Comment:
I am compiling lame 3.98.4 on Solaris x86 with -xarch=386 for an older system on Solaris 9. Although Solaris 9 in general provides xmmintrin.h it is usable only for architectures that support SSE, which is not the case for the 386 arch. It would be better to also check for the usability of xmmintrin.h in addition to existence.

----------------------------------------------------------------------

>Comment By: Dagobert Michelsen (dmichelsen)
Date: 2012-04-27 03:41

Message:
I added a patch for a proper detection whether the intrinsics are there and
actually usable. It cleanly applies to 3.99.5.

----------------------------------------------------------------------

Comment By: Dagobert Michelsen (dmichelsen)
Date: 2011-01-12 05:57

Message:
I found a construct in the configure.ac from xerces-c which makes a compile
test for a similar header:
        AC_COMPILE_IFELSE(  [AC_LANG_PROGRAM([[#include <xmmintrin.h>]],
[[__m128 one;]])],
                                                [XMMINTRIN_H=yes],
                                                [XMMINTRIN_H=no]


----------------------------------------------------------------------

Comment By: Dagobert Michelsen (dmichelsen)
Date: 2011-01-06 00:34

Message:
The problem is slightly different from a distribution as compilation
already fails. I want to compile on a platform which essentially may
support SSE, but the requested architecture of the build does not, so the
compiler throws an error.

configure does not seem to understand --noasm. In my understanding it
should be sufficient to not use --enable-nasm, which I have not set. I used
the hackery ac_cv_header_xmmintrin_h=no in my invocation of configure to
let it think there are no SSE headers available.

I think it would be best to test after the availability of xmmintrin.h the
compilation of a short program using one of the intrinsics like _mm_set_ss
and see if it compiles. This would not solve the distribution problem, but
would allow at last allow compilation under all conditions of different
compilation flags without hackery.

----------------------------------------------------------------------

Comment By: Rogério Theodoro de Brito (rbrito)
Date: 2011-01-04 10:25

Message:
Hi, Dagobert.

Indeed, the availability of SSE is not sufficient for the usability of the
instructions. But the problem that you are facing is exactly the same as
that faced by distributions, since one can compile the program on a host
and run it on a very different machine.

That being said, can you successfully compile lame? Can you use the --noasm
command line option? Does it work without generating a SIGILL?

I am not exactly sure how to address the problem that you're having, apart
from, at runtime, detecting and falling back to what is usable on the
particular machine. Or, of course, using the --noasm option...

Suggestions?

Regards.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=3150289&group_id=290

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Lame-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lame-dev