r239883 - Update the intel intrinsic headers to use the target attribute support.

[Dimitry Andric via cfe-commits]

> On 18 Aug 2015, at 19:52, Eric Christopher <echristo at gmail.com> wrote:
> 
> 
> 
> On Tue, Aug 18, 2015 at 10:51 AM Dimitry Andric <dimitry at andric.com> wrote:
> The problems from my earlier mail still stand, even with trunk r245199.
> 
> 1) Various configure scripts (e.g. lame and others) try to check for intrinsics using fragments similar to the following:
> 
> #include <xmmintrin.h>
> 
> then running that through "clang -E".  If preprocessing succeeds, the intrinsics are assumed to be available, otherwise they are not.
> 
> The changes in r239883 break this assumption.  In my opinion, intrinsics headers should always cause a compilation error, when the specific intrinsics asked for are not available.  Of course configure scripts can always be hacked up to cope, but this is really the wrong way around.
> 
> 
> I fundamentally disagree with you. As does everyone else that ships these headers these days.

Aha, I see now what you mean:

$ cat simple-detect.c
#include <xmmintrin.h>

$ gcc47 -c simple-detect.c
In file included from simple-detect.c:1:0:
/usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include/xmmintrin.h:32:3: error: #error "SSE instruction set not enabled"

$ gcc48 -c simple-detect.c
In file included from simple-detect.c:1:0:
/usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.5/include/xmmintrin.h:31:3: error: #error "SSE instruction set not enabled"
 # error "SSE instruction set not enabled"
   ^

$ gcc49 -c simple-detect.c
<no problem>

E.g., somewhere between gcc 4.8 and 4.9, they also removed the include guards from their intrinsics headers.  (It seems to be this commit: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=200349 )

So since this old method of just attempting to include certain intrinsics headers is not working anymore, what would be the correct new method of detecting whether certain classes of intrinsic are available with the current compilation flags?  For example, actually trying to call such an intrinsic?  Or maybe even attempt to link the program, and see if linking fails?


>  2) When those configure scripts erroneously assume specific intrinsics are available, while they really are not, and the program attempts to use them, clang dies with a fatal backend error, for example:
> 
> SplitVectorResult #0: 0x2bbd2f3c: v4f32 = llvm.x86.sse.sqrt.ps 0x2bbd53a8, 0x2bbd2ea0 [ORD=11] [ID=0]
> 
> fatal error: error in backend: Do not know how to split the result of this operator!
> 
> This problem is reported in https://llvm.org/bugs/show_bug.cgi?id=24335 .
> 
> 
> This will be a better error soon (next day or so) and come out of the front end.

Thank you.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150818/9db70560/attachment.sig>