Patch to fix an invalid AST of a locally redeclared built-in which causes an IRGen crash

Richard Smith richard at metafoo.co.uk
Thu May 22 11:40:35 PDT 2014


On Thu, May 22, 2014 at 11:06 AM, jahanian <fjahanian at apple.com> wrote:

>
> On May 21, 2014, at 5:19 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
>
> How about this: drop the setInvalidDecl() call. In its place, when we get
> a type mismatch between two function declarations, if Old is implicit then
> check whether it used to be a builtin. If so, check the type against the
> most recent declaration instead.
>
>
> Without adding an extra flag to FunctionDecl, I am not sure how I can
> check that an implicit Old used to be a “builtin”?
> I don’t thing that checking for Builtin::NotBuiltin means this as it is a
> value of 0. Are you proposing
> addition of a new flag? Or a special BID?
>

The clang::Builtin::Context object seems to retain enough information to
work out whether an identifier was ever a builtin. But perhaps this isn't
the best approach.

Another problem with our current model is that we build a broken
redeclaration chain (the local declaration is marked as being a
redeclaration of the implicitly-declared builtin, which it isn't). This
leads to other bugs; for instance:

void f() { int memcpy(void); } void g() { memcpy(0,0,0); }

... misses the "implicitly declaring library function" warning.

If you fix *that* bug, then it should be possible to teach
FunctionDecl::getBuiltinID to do the right thing, by checking whether the
canonical decl is implicit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140522/aa323397/attachment.html>


More information about the cfe-commits mailing list