> Am 14.04.2025 um 18:19 schrieb Jakub Jelinek <ja...@redhat.com>:
>
> Hi!
>
> This is a regression on some targets introduced I believe by r6-2055
> which added mode argument to set_src_cost.
>
> The problem here is that in the first iteration, mode is always QImode
> and we get as -Os zero cost set_src_cost (const0_rtx, QImode, false).
> But then we use the mode variable for iterating over int, partial int
> and vector int modes, so for the second iteration we call set_src_cost
> with mode which is at that time (machine_mode) (MAX_MODE_VECTOR_INT + 1).
>
> In the x86 case that happens to be V2HFmode and we don't crash (and
> compute the same 0 cost as we would for QImode).
> But e.g. in the SPARC case (machine_mode) (MAX_MODE_VECTOR_INT + 1) is
> MAX_MACHINE_MODE and that does all kinds of weird things especially
> when doing ubsan bootstrap.
>
> Fixed by always using QImode.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok
Richard
>
> 2025-04-14 Jakub Jelinek <ja...@redhat.com>
>
> PR rtl-optimization/119785
> * expmed.cc (init_expmed): Always pass QImode rather than mode to
> set_src_cost passed to set_zero_cost.
>
> --- gcc/expmed.cc.jj 2025-04-08 14:08:51.234282102 +0200
> +++ gcc/expmed.cc 2025-04-14 12:17:48.334123928 +0200
> @@ -285,7 +285,7 @@ init_expmed (void)
> for (speed = 0; speed < 2; speed++)
> {
> crtl->maybe_hot_insn_p = speed;
> - set_zero_cost (speed, set_src_cost (const0_rtx, mode, speed));
> + set_zero_cost (speed, set_src_cost (const0_rtx, QImode, speed));
>
> for (mode = MIN_MODE_INT; mode <= MAX_MODE_INT;
> mode = (machine_mode)(mode + 1))
>
> Jakub
>
