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. > 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 <echri...@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 <dimi...@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 <echri...@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-comm...@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
