Fix to PR41012

[Xinliang David Li]

I will prepare a different patch, also with a test case.

Thanks,

David

On Sun, Aug 9, 2009 at 10:57 AM, Richard
Guenther<richard.guenther@gmail.com> wrote:
> On Sun, Aug 9, 2009 at 7:34 PM, Xinliang David Li<davidxl@google.com> wrote:
>> On Sun, Aug 9, 2009 at 3:28 AM, Richard
>> Guenther<richard.guenther@gmail.com> wrote:
>>> On Sun, Aug 9, 2009 at 8:41 AM, Xinliang David Li<davidxl@google.com> wrote:
>>>> The attached patch is meant to fix 41012. With this patch,
>>>> check_call_args will use the DECL_ARGUMENTS associated with the
>>>> func_decl of the newly generated direct call to do the check, and it
>>>> will match the actuals.
>>>>
>>>> One possible problem is that if there are other places (other than in
>>>> check_call_args) setting the cannot_inline attribute to the indirect
>>>> call,, the bit will be lost -- but this is probably a moot point.
>>>>
>>>>
>>>> Bootstraped/Regression tested on x86_64/linux
>>>>
>>>> Ok to commit?
>>>
>>> I would rather have you rework the disabling of inlining because of argument
>>> type mismatches to do this matching during computing the inlining decision,
>>> not upfront.  That would also address the problems we likely get with LTO in
>>> this area.  And of course it will fix the PR.
>>
>> The type checking is not done during inlining but pretty early in the
>> pipeline -- all it sees is a summary bit. Of course the type check can
>> be delayed.   On the other hand, is this a simple and safe fix?
>
> Yes, at the moment only the inliner (and maybe the cloning) code cares.
> IIRC there is a predicate that tells both if a call can be inlined/cloned, the
> check should be moved there.
>
> Thanks,
> Richard.
>