On Tue, Aug 18, 2015 at 11:05 AM Dimitry Andric <dimi...@andric.com> wrote:
> > On 18 Aug 2015, at 19:52, Eric Christopher <echri...@gmail.com> wrote: > > > > > > > > On Tue, Aug 18, 2015 at 10:51 AM Dimitry Andric <dimi...@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
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
