https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79690
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> But an extra assert like the following triggers during bootstrap so we can't
> really avoid the casting (in all cases).
>
> Index: gcc/tree-ssa-address.c
> ===================================================================
> --- gcc/tree-ssa-address.c (revision 245681)
> +++ gcc/tree-ssa-address.c (working copy)
> @@ -708,6 +702,9 @@ create_mem_ref (gimple_stmt_iterator *gs
> tree mem_ref, tmp;
> struct mem_address parts;
>
> + if (base_hint)
> + gcc_assert (POINTER_TYPE_P (TREE_TYPE (base_hint)));
> +
> addr_to_parts (type, addr, iv_cand, base_hint, &parts, speed);
> gimplify_mem_ref_parts (gsi, &parts);
> mem_ref = create_mem_ref_raw (type, alias_ptr_type, &parts, true);
>
> OTOH it looks harmless for a few cases I tried (the base_hint won't match
> in the search for it). Testing w/o that assert.
Ok, so we'd move an integer to ->base and then later when building the
TARGET_MEM_REF we'd refuse that base and do
else if (addr->base
&& POINTER_TYPE_P (TREE_TYPE (addr->base)))
{
base = addr->base;
index2 = NULL_TREE;
}
else
{
base = build_int_cst (build_pointer_type (type), 0);
index2 = addr->base;
}
which cost-wide wasn't expected? It's probably also not a good idea
in general to generate a zero-based TARGET_MEM_REF....
It's also against the very first check:
if (verify
&& !valid_mem_ref_p (TYPE_MODE (type), TYPE_ADDR_SPACE (type), addr))
return NULL_TREE;
which btw also uses a bogus type to get the address-space from.
So I think a better fix would be to ensure that TREE_TYPE (mem-ref) has
the same address-space as its pointed-to type in operand 0 ...
