https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #8 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
> expmed.c.214r.reload:
>
> ;; Function long unsigned int choose_multiplier(long unsigned int, int, int,
> long unsigned int*, int*, int*) (_Z17choose_multipliermiiPmPiS0_,
> funcdef_no=1085, decl_uid=47659, symbol_order=801)
>
> ...
> 557: r13:DI=0x7ffffff78
> REG_EQUIV 0x7ffffff78
> ...
> 547: debug this => debug_implicit_ptr
> 548: debug D#64 => debug_implicit_ptr
> 549: debug D#37 => D#64
> 550: debug this => D#37
> 551: debug len => optimized away
> 552: debug D#65 => debug_implicit_ptr
> 553: debug D#39 => D#65
> 554: debug this => D#39
> 555: debug high => [sp:DI+0x800000038]
> 556: debug res => 0
> 560: NOTE_INSN_DELETED
> 1334: NOTE_INSN_DELETED
> 1367: ax:DI=[sp:DI+r13:DI+0xc0]
>
OK. This is actually not reachable.
Only if wi::divmod_internal would return 0, which it does not.
But in this case get_len() would return 0, and then
generic_wide_int <storage>::uhigh () const
{
return this->get_val ()[this->get_len () - 1];
}
would access exactly SP+32GB.
So this is actually one more case, where it would be incorrect
and potentially dangerous for rtx_addr_can_trap_p_1 to return 0.
The crash in -fdump-rtl-all-slim is actually a different bug,
PR61461 which has most likely nothing to do with this issue.
