[opaque pointer types] Fix the CallInfo passed to EmitCall in some
authorJames Y Knight <jyknight@google.com>
Tue, 5 Feb 2019 16:05:50 +0000 (16:05 +0000)
committerJames Y Knight <jyknight@google.com>
Tue, 5 Feb 2019 16:05:50 +0000 (16:05 +0000)
commitb92d290e48e908c083976ef3a807ed1fcc9bf209
tree7e50929d62c9d59ad910c86a83d9e95220511427
parentb3b896811730dc527a461a18c5e73c0db5de4aea
[opaque pointer types] Fix the CallInfo passed to EmitCall in some
edge cases.

Currently, EmitCall emits a call instruction with a function type
derived from the pointee-type of the callee. This *should* be the same
as the type created from the CallInfo parameter, but in some cases an
incorrect CallInfo was being passed.

All of these fixes were discovered by the addition of the assert in
EmitCall which verifies that the passed-in CallInfo matches the
Callee's function type.

As far as I know, these issues caused no bugs at the moment, as the
correct types were ultimately being emitted. But, some would become
problematic when pointee types are removed.

List of fixes:

* arrangeCXXConstructorCall was passing an incorrect value for the
  number of Required args, when calling an inheriting constructor
  where the inherited constructor is variadic. (The inheriting
  constructor doesn't actually get passed any of the user's args, but
  the code was calculating it as if it did).

* arrangeFreeFunctionLikeCall was not including the count of the
  pass_object_size arguments in the count of required args.

* OpenCL uses other address spaces for the "this" pointer. However,
  commonEmitCXXMemberOrOperatorCall was not annotating the address
  space on the "this" argument of the call.

* Destructor calls were being created with EmitCXXMemberOrOperatorCall
  instead of EmitCXXDestructorCall in a few places. This was a problem
  because the calling convention sometimes has destructors returning
  "this" rather than void, and the latter function knows about that,
  and sets up the types properly (through calling
  arrangeCXXStructorDeclaration), while the former does not.

* generateObjCGetterBody: the 'objc_getProperty' function returns type
  'id', but was being called as if it returned the particular
  property's type. (That is of course the *dynamic* return type, and
  there's a downcast immediately after.)

* OpenMP user-defined reduction functions (#pragma omp declare
  reduction) can be called with a subclass of the declared type. In
  such case, the call was being setup as if the function had been
  actually declared to take the subtype, rather than the base type.

Differential Revision: https://reviews.llvm.org/D57664

llvm-svn: 353181
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CGExprCXX.cpp
clang/lib/CodeGen/CGObjC.cpp
clang/lib/CodeGen/CodeGenTypes.h
clang/lib/CodeGen/ItaniumCXXABI.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/test/CodeGenObjC/getter-property-mismatch.m