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

[Eric Christopher via cfe-commits]

On Tue, Aug 18, 2015 at 11:05 AM Dimitry Andric <dimitry at andric.com> wrote:

> > 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?
>
>
I think the best bet is going to be a compile test. Though I really worry
about a configure time check for this kind of feature in that it's not
particularly portable. :\

That ship has probably sailed though.


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

Yep. Thanks for being patient :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150818/5df0e041/attachment.html>