[Bug 206620] audio/lame: fix build with clang 3.8.0 (and gcc >= 4.9.0)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206620

            Bug ID: 206620
           Summary: audio/lame: fix build with clang 3.8.0 (and gcc >=
                    4.9.0)
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: netchild at FreeBSD.org
          Reporter: dim at FreeBSD.org
          Assignee: netchild at FreeBSD.org
             Flags: maintainer-feedback?(netchild at FreeBSD.org)

Created attachment 166113
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166113&action=edit
Fix lame's configure script to correctly detect SSE support

During the exp-run in bug 206074, it was found that audio/lame gives errors
with a recent clang 3.8.0 snapshot, but only on i386 [1]:

xmm_quantize_sub.c:65:34: error: always_inline function '_mm_loadu_ps' requires
target feature 'mmx', but would be inlined into function 'init_xrpow_core_sse'
that is compiled without support for 'mmx'
    const __m128 vec_fabs_mask = _mm_loadu_ps(&fabs_mask._float[0]);
                                 ^

And many more of such errors, in lame's SSE (vector) support routines.  The
actual message is a little misleading, as it is really SSE support that is
missing.  E.g., the program is compiled on i386-freebsd, which has i486 as
default target CPU, but there is no -msse flag on the command line.  (Note that
these messages go away if you set CPUTYPE to a CPU which does support SSE.)

When you compile with recent versions of gcc (4.9 and higher), you get similar
errors:

In file included from xmm_quantize_sub.c:37:0:
/usr/local/lib/gcc49/gcc/i386-portbld-freebsd11.0/4.9.4/include/xmmintrin.h:929:1:
error: inlining failed in call to always_inline '_mm_loadu_ps': target specific
option mismatch
 _mm_loadu_ps (float const *__P)
 ^

The cause is that lame's configure script simply checks for the existence of
<xmmintrin.h>, and if it exists, and can be compiled, it assumes SSE intrinsics
are available.  This is not generally true anymore, because recent versions of
gcc and clang removed the #ifdef __SSE__ checks from their xmmintrin.h files,
and therefore a test program which only does "#include <xmmintrin.h>" will
always compile, even if SSE support is turned off.

I have attempted to fix lame's configure.in and configure scripts, by letting
them compile a function which actually calls an SSE intrinsic.  It works
correctly for me, but my knowledge of autoconf is limited, so a double-check by
an expert would be nice.

This should probably be upstreamed too.

[1]
http://package18.nyi.freebsd.org/data/headi386PR206074-default/2016-01-17_07h20m29s/logs/errors/lame-3.99.5_2.log

-- 
You are receiving this mail because:
You are the assignee for the bug.