[Bug objc/124260] [16 Regression] ICE during IPA pass: cp when producing 64b objective-c code on 32b host

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Martin Jambor from comment #6)
> (In reply to Iain Sandoe from comment #5)
> > (In reply to Richard Biener from comment #4)
> > > So varasm.cc:output_constructor_regular_field "supports" a NULL FIELD_DECL in
> > > CTORs by "appending" and advancing according to the types size.  That
> > > suggests
> > > that ipa_analyze_var_static_initializer would need to support that as well,
> > > or that it had to get a "failure" mode.  OTOH it does not seem to be
> > > conservative given it's TODO, so a do-nothing is correct here?  In that
> > > case adding || !index to the continue case would be correct?
> > 
> > I have not looked at the IPA stuff .. it's outside what I'm comfortable with.
> > 
> 
> I assume Richi meant to do the following.  I cannot test it helps now since
> I no longer have an easy access to a 32bit host.  If an address to a
> function is skipped, it may result in a "bad" decision to speculatively
> "devirtualize" or not.  But since it is speculative, things will remain
> correct.
> 
> diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
> index 385912c3790..e5b401b9d3f 100644
> --- a/gcc/ipa-prop.cc
> +++ b/gcc/ipa-prop.cc
> @@ -3637,7 +3637,8 @@ ipa_analyze_var_static_initializer (varpool_node *node)
>                             val)
>      {
>        if (TREE_CODE (val) != ADDR_EXPR
> -         || TREE_CODE (TREE_OPERAND (val, 0)) != FUNCTION_DECL)
> +         || TREE_CODE (TREE_OPERAND (val, 0)) != FUNCTION_DECL
> +         || !index)
>         continue;
>        HOST_WIDE_INT elt_offset = int_bit_position (index);
>        if ((elt_offset % BITS_PER_UNIT) != 0)

I am testing this (separately from the FE fixes).