https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84526
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> >
> > What is the TREE_OPERAND (expr, 0) in:
> > base = get_inner_reference (expr, &bitsize, &bitpos, &var_off,
> > &mode, &sign, &reverse, &vol);
> >
> > poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
> >
> > HOST_WIDE_INT const_off;
> > if (!base || !bytepos.is_constant (&const_off))
> > {
> > base = get_base_address (TREE_OPERAND (expr, 0));
> > return;
> > }
> > doing? It doesn't seem you've checked what expr actually is before using
> > TREE_OPERAND (expr, 0) on it. The cases that fall through into this code
> > are
> > either that expr is an operand of ADDR_EXPR, or SSA_NAME, or in theory some
> > constant. I don't think get_inner_reference ever returns NULL though.
>
> This bit was left over from the previous version that used
> get_addr_base_and_unit_offset() where the function can return null. If
> get_inner_reference() cannot return null and if the byte offset is
get_inner_reference can't return NULL, just see what it does. bytepos in
theory could be non-constant on aarch64 with SVE, still, what do you know about
expr that you think you can safely use the operand of it (it couldn't have
one).
Why don't you treat non-constant bytepos as var_off? Why do you think var_off
must be non-negative? Perhaps if base is a DECL in correct programs it should
be, but if base is a MEM_REF it can be anything.
And again for if (TREE_CODE (base) == MEM_REF) you set base = TREE_OPERAND
(base, 0);, so what used to be at that point the base of the reference becomes
its address; though if base is instead say a DECL_P or something even
different, you don't do that.
