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 ...