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

[Dimitry Andric via cfe-commits]

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.

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 .

-Dimitry

> On 18 Aug 2015, at 00:08, Eric Christopher <echristo at gmail.com> wrote:
> 
> There is nothing broken about not having the include guards there, it's just not helpful. I'm working on the infrastructure for an error if you call a function from within an incompatible routine at the moment (without duplicating a lot of code it's actually a bit annoying), but there's nothing actually wrong with the code. It's just the same as basically saying asm("invalid_instruction") in a random function.
> 
> Any configure script that was depending on error conditions from this is already broken by gcc as well, and likely icc.
> 
> -eric
> 
> On Mon, Aug 17, 2015 at 3:04 PM Dimitry Andric <dimitry at andric.com <mailto:dimitry at andric.com>> wrote:
> [Re-sending, used the old cfe-commits address by accident]
> 
> Where is the other thread?  This problem still exists, for both trunk and the upcoming 3.7.0 RC3.  I'll try to submit a patch tomorrow to partially restore the include guards, so we won't have a broken release.
> 
> -Dimitry
> 
>> On 03 Aug 2015, at 18:48, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote:
>> 
> 
>> 
>> 
>> Where are the negative test cases? Diagnosing uses of these functions
>> when they aren't valid is really important - it's a pretty serious
>> regression if we don't.
>> 
>> Two threads, I'm going to take this in the other thread. :)
>> 
>> -eric
>> 
>> 
> 
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150818/436bb781/attachment.html>
-------------- 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/436bb781/attachment.sig>