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. Jason
