[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri May 31 10:39:00 GMT 2019


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 46437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46437&action=edit
not fully fix

So even a 1:1 implementation of gimple_builtin_call_types_compatible_p doesn't
catch this since the FE registers a bogus prototype which we of course match.
Not sure why the issue doesn't appear on GIMPLE though.

It looks like we eventually get to some intermediate IL state from the
FEs c_fully_fold_internal?  At gimplification time the callees function
decl/type is that of the actual builtin, during the time we call
c_fully_fold_internal it is not.

In fact we adjust the function decls type in pop_scope:

          /* It is possible for a decl not to have a name.  We get
             here with b->id NULL in this case.  */
          if (b->id)
            {
              gcc_assert (I_SYMBOL_BINDING (b->id) == b);
              I_SYMBOL_BINDING (b->id) = b->shadowed;
              if (b->shadowed && b->shadowed->u.type)
                TREE_TYPE (b->shadowed->decl) = b->shadowed->u.type;

Aha.  It looks like since

extern _Float128 copysignf128 ();

isn't a prototype the actual call creates one in the local binding
(adding 'void' above makes the originally intended fix work).

In the end it's premature folding that makes the fix ineffective.


More information about the Gcc-bugs mailing list