> 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? > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
