Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[opaque pointer types] Fix the CallInfo passed to EmitCall in some edge cases. #2

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jyknight
Copy link
Contributor

@jyknight jyknight commented Feb 2, 2019

Currently, EmitCall is emitting a call instruction using 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 (but would
potentially cause problems when removing pointee types.)

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 'id',
    but was being called as if it returned the property type. (The
    return value gets downcast to the propererty type after the call).

  • 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.

edge cases.

Currently, EmitCall is emitting a call instruction using 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 (but would
potentially cause problems when removing pointee types.)

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 'id',
  but was being called as if it returned the property type. (The
  return value gets downcast to the propererty type after the call).

* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant