https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69156
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 8 Jan 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69156 > > --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #3) > > (In reply to Jakub Jelinek from comment #2) > > > Created attachment 37266 [details] > > > gcc6-pr69156.patch > > > > > > Untested fix. Not sure if it is the best spot though. And the testcase > > > is > > > really nasty. > > > > Hmm, but this means things were mismatched in the first place (earlier) and > > thus this should be checked somewhere else? > > This happens in gimple-match-head.c: > 714 tree decl = TREE_OPERAND (fn, 0); > 715 if (DECL_BUILT_IN_CLASS (decl) != BUILT_IN_NORMAL > 716 || !gimple_builtin_call_types_compatible_p (stmt, > decl)) > 717 return false; > and the problem is that gimple_builtin_call_types_compatible_p is extremely > lose (basically, for return type or arguments considers all integral types > equal, or all pointer types equal, or all RECORD_TYPEs equal etc.). > Bet for this purpose (but don't about all the others) it might be better to > check useless_type_conversion_p equality instead. > I guess the question is when is a mere validate_type instead of > types_compatible_p useful. Ick. That's the code "copied" from builtins.c. I suppose we should simply exchange the validate_type calls with useless_type_conversion_p () (in the correct order). That should be coarse enough these days.
