<div dir="ltr">On Tue, Mar 10, 2015 at 6:37 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Mar 10, 2015 at 05:44:00PM -0700, John McCall wrote:<br>
> I'm sorry, I missed your early request, and your response to my review.<br>
> I'm much more likely to respond quickly if you keep me as a recipient.<br>
><br>
> I really would like you to diagnose this in Sema, please.  Target-specific<br>
> restrictions are not new, especially on builtin functions.  But if you do<br>
> that, it's approved for merge.<br>
<br>
</div></div>But Sema is too early, it breaks valid use cases that are never going to<br>
hit the backend at all. Consider clang --analyze or clang-modernize.<br>
Especially the latter is completely target independent, so it shouldn't<br>
get fail on code that is valid on one platform and only fails on another<br>
because of LLVM bugs.<br></blockquote><div> </div><div>It's target-independent except for the thousands of ways that C code is not</div><div>target-independent.  Headers need to be in place and provide the right</div><div>declarations, hordes of warnings turn out differently based on type size,</div><div>printf format checking has target-specific logic, etc.</div><div><br></div><div>The way we (don't) implement them, __builtin_setjmp and __builtin_longjmp</div><div>are target-specific builtin functions, and they should be diagnosed along</div><div>with the rest of them.</div><div><br></div><div>John.</div></div>
</div></div>