On Tue, Mar 10, 2015 at 07:03:16PM -0700, John McCall wrote: > On Tue, Mar 10, 2015 at 6:37 PM, Joerg Sonnenberger <[email protected] > > wrote: > > > On Tue, Mar 10, 2015 at 05:44:00PM -0700, John McCall wrote: > > > I'm sorry, I missed your early request, and your response to my review. > > > I'm much more likely to respond quickly if you keep me as a recipient. > > > > > > I really would like you to diagnose this in Sema, please. > > Target-specific > > > restrictions are not new, especially on builtin functions. But if you do > > > that, it's approved for merge. > > > > But Sema is too early, it breaks valid use cases that are never going to > > hit the backend at all. Consider clang --analyze or clang-modernize. > > Especially the latter is completely target independent, so it shouldn't > > get fail on code that is valid on one platform and only fails on another > > because of LLVM bugs. > > > > It's target-independent except for the thousands of ways that C code is not > target-independent. Headers need to be in place and provide the right > declarations, hordes of warnings turn out differently based on type size, > printf format checking has target-specific logic, etc.
A refactoring tool knows how to deal with many of those variations... > The way we (don't) implement them, __builtin_setjmp and __builtin_longjmp > are target-specific builtin functions, and they should be diagnosed along > with the rest of them. But that we don't implement them is a choice of CodeGen. Ideally, that wouldn't be needed if the IR intrinsics were cleanly separated, so this is really an implementation detail of the contract between Clang and LLVM IR and nothing about the semantic analysis of the source code. Why do you insist on violating the layering? Joerg _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
