<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 18, 2015 at 10:51 AM Dimitry Andric <<a href="mailto:dimitry@andric.com">dimitry@andric.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>The problems from my earlier mail still stand, even with trunk r245199.</div><div><br></div><div>1) Various configure scripts (e.g. lame and others) try to check for intrinsics using fragments similar to the following:</div><div><br></div><div>#include <xmmintrin.h></div><div><br></div><div>then running that through "clang -E". If preprocessing succeeds, the intrinsics are assumed to be available, otherwise they are not.</div><div><br></div><div>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.</div><div><br></div></div></blockquote><div><br></div><div>I fundamentally disagree with you. As does everyone else that ships these headers these days.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>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:</div><div><br></div><div>SplitVectorResult #0: 0x2bbd2f3c: v4f32 = <a href="http://llvm.x86.sse.sqrt.ps" target="_blank">llvm.x86.sse.sqrt.ps</a> 0x2bbd53a8, 0x2bbd2ea0 [ORD=11] [ID=0]</div><div><br></div><div>fatal error: error in backend: Do not know how to split the result of this operator!</div><div><br></div><div>This problem is reported in <a href="https://llvm.org/bugs/show_bug.cgi?id=24335" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=24335</a> .</div></div><div style="word-wrap:break-word"><div><br></div></div></blockquote><div><br></div><div>This will be a better error soon (next day or so) and come out of the front end.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>-Dimitry</div></div><div style="word-wrap:break-word"><div><br></div><div><blockquote type="cite"><div>On 18 Aug 2015, at 00:08, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><br><div><div dir="ltr">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.<div><br></div><div>Any configure script that was depending on error conditions from this is already broken by gcc as well, and likely icc.</div><div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 17, 2015 at 3:04 PM Dimitry Andric <<a href="mailto:dimitry@andric.com" target="_blank">dimitry@andric.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>[Re-sending, used the old cfe-commits address by accident]</div><div><br></div><div>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.</div></div><div style="word-wrap:break-word"><div><br></div><div>-Dimitry</div><div><br></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On 03 Aug 2015, at 18:48, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><br></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" class="gmail_quote"><br>
<br>
Where are the negative test cases? Diagnosing uses of these functions<br>
when they aren't valid is really important - it's a pretty serious<br>
regression if we don't.<br></blockquote><div><br></div><div>Two threads, I'm going to take this in the other thread. :)</div><div><br></div><div>-eric</div><div><div><br></div><div><br></div></div></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>
_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br></div></blockquote></div></div></blockquote></div>
</div></blockquote></div><br></div></blockquote></div></div>