[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: [PATCHv2] Add a warning for invalid function casts
From:       Jason Merrill <jason () redhat ! com>
Date:       2017-11-30 18:38:14
Message-ID: CADzB+2kQx6ExiO7bGf6UhWEC8wLZHB+3bpkc16n5=BDDzE4DTg () mail ! gmail ! com
[Download RAW message or body]

On Thu, Nov 30, 2017 at 1:23 PM, Bernd Edlinger
<bernd.edlinger@hotmail.de> wrote:
> On 11/30/17 19:05, Jason Merrill wrote:
>> On Thu, Nov 30, 2017 at 12:55 PM, Bernd Edlinger
>> <bernd.edlinger@hotmail.de> wrote:
>>> On 11/30/17 18:29, Jason Merrill wrote:
>>>> On Thu, Nov 30, 2017 at 11:07 AM, Bernd Edlinger
>>>> <bernd.edlinger@hotmail.de> wrote:
>>>>> On 11/30/17 16:45, Jason Merrill wrote:
>>>>>> On Thu, Nov 30, 2017 at 10:14 AM, Bernd Edlinger
>>>>>> <bernd.edlinger@hotmail.de> 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)))
>>
>> I was thinking
>>
>>          && (TYPE_UNSIGNED (t1) == TYPE_UNSIGNED (t2)
>>              || type_passed_as (t1) == t1))
>>
>
> Which should be hopefully equivalent, since type_passed_as also compares
> size(t1) with sizeof(int), and calls the same hook.
>
> It is unfortunate that I don't see an equivalent function to use in the
> C FE.
>
> But they just have to agree on this target dependency.
>
> So in the C front-end I would have to use the target hook as above,
> unless Joseph can point out a more appropriate way.
>
> I personally would like to keep the symmetry between C and C++ here,

OK, that makes sense.

Jason
[prev in list] [next in list] [prev in thread] [next in thread]