On 11/30/17 19:05, Jason Merrill wrote: > On Thu, Nov 30, 2017 at 12:55 PM, Bernd Edlinger > <bernd.edlin...@hotmail.de> wrote: >> On 11/30/17 18:29, Jason Merrill wrote: >>> On Thu, Nov 30, 2017 at 11:07 AM, Bernd Edlinger >>> <bernd.edlin...@hotmail.de> wrote: >>>> On 11/30/17 16:45, Jason Merrill wrote: >>>>> On Thu, Nov 30, 2017 at 10:14 AM, Bernd Edlinger >>>>> <bernd.edlin...@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, but if you strongly prefer to use type_passed_as, I can use your suggestion in the C++ FE instead. Thanks Bernd.
