On 11/30/17 18:29, Jason Merrill wrote:
> On Thu, Nov 30, 2017 at 11:07 AM, Bernd Edlinger
> <[email protected]> wrote:
>> On 11/30/17 16:45, Jason Merrill wrote:
>>> On Thu, Nov 30, 2017 at 10:14 AM, Bernd Edlinger
>>> <[email protected]> wrote:
>>>> On 11/29/17 22:57, Jason Merrill wrote:
>>>>> On 10/09/2017 06:30 PM, Bernd Edlinger wrote:
>>>
>>>>>> + if (INTEGRAL_TYPE_P (t1)
>>>>>> + && INTEGRAL_TYPE_P (t2)
>>>>>> + && TYPE_PRECISION (t1) == TYPE_PRECISION (t2)
>>>>>> + && (TYPE_UNSIGNED (t1) == TYPE_UNSIGNED (t2)
>>>>>> + || TYPE_PRECISION (t1) >= TYPE_PRECISION (integer_type_node)))
>>>>>> + return true;
>>>>>
>>>>> This section needs a comment explaining what you're allowing and why.
>>>>
>>>> Okay. I will add a comment here:
>>>>
>>>> /* The signedness of the parameter matters only when an integral
>>>> type smaller than int is promoted to int, otherwise only the
>>>> precision of the parameter matters.
>>>> This check should make sure that the callee does not see
>>>> undefined values in argument registers. */
>>>
>>> If we're thinking about argument promotion, should this use
>>> type_passed_as rather than assume promotion to int?
>>
>> I don't know, it is only a heuristic after all, and even if there is no
>> warning for a bogus type cast that does not mean any
>> correctness-guarantee at all.
>>
>> Would type_passed_as make any difference for integral types?
>
> Yes, type_passed_as expresses promotion to int on targets that want
> that behavior.
>
Hmm, I see, mostly arm, sh and msp430 (whatever that may be).
So how would you like this:
if (INTEGRAL_TYPE_P (t1)
&& INTEGRAL_TYPE_P (t2)
&& TYPE_PRECISION (t1) == TYPE_PRECISION (t2)
&& (TYPE_UNSIGNED (t1) == TYPE_UNSIGNED (t2)
|| !targetm.calls.promote_prototypes (t1)
|| !targetm.calls.promote_prototypes (t2)
|| TYPE_PRECISION (t1) >= TYPE_PRECISION (integer_type_node)))
Thanks
Bernd.
