https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91468
kugan at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kugan at gcc dot gnu.org
--- Comment #2 from kugan at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #1)
> (In reply to Feng Xue from comment #0)
> >
> > In function update_jump_functions_after_inlining(),
> >
> > if (dst->type == IPA_JF_ANCESTOR)
> > {
> > ......
> >
> > if (src->type == IPA_JF_PASS_THROUGH
> > && src->value.pass_through.operation == NOP_EXPR)
> > {
> > ......
> > }
> > else if (src->type == IPA_JF_PASS_THROUGH
> > && TREE_CODE_CLASS (src->value.pass_through.operation) ==
> > tcc_unary)
> > {
> > dst->value.ancestor.formal_id = src->value.pass_through.formal_id;
> > dst->value.ancestor.agg_preserved = false;
> > }
> > ......
> > }
> >
> > If we suppose pass_through operation is "negate_expr" (while it is not a
> > reasonable operation on pointer type), the code might be incorrect. It's
> > better to specify expected unary operations here.
>
> Kugan, you added this in 2016 and unfortunately I think it is wrong.
> Are there any unary operations we could possibly want to handle?
> In any event, the information that there was an arithmetic function in
> the path of the parameter would be completely lost if the code ever
> executed. (Which I don't think it ever does, I think it would take
> crazy code that employs LTO to pass an integer to a pointer parameter
> to trigger).
>
> So I plan to remove the whole if.
>
Yes, i think this is a mistake and should go. Thanks for doing that.
