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

[Eric Christopher via cfe-commits]

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.


> 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.

-eric


> -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> 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> 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
>> 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/dd78c135/attachment.html>