On Thu, Nov 30, 2017 at 1:23 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > 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,
OK, that makes sense. Jason
