r230255 - Only lower __builtin_setjmp / __builtin_longjmp to
Joerg Sonnenberger
joerg at britannica.bec.de
Tue Mar 10 19:16:41 PDT 2015
On Tue, Mar 10, 2015 at 07:03:16PM -0700, John McCall wrote:
> On Tue, Mar 10, 2015 at 6:37 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> > 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
More information about the cfe-commits
mailing list