https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104932
Bug ID: 104932
Summary: [nvptx] Subreg validation error for V2SI
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When building with the patch from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104916#c2 , but allowing a shuffle
for V2SImode, we run into an assert when trying to create a subreg here:
...
case E_V2SImode:
{
rtx src0 = gen_rtx_SUBREG (SImode, src, 0);
rtx src1 = gen_rtx_SUBREG (SImode, src, 4); <<<<< HERE >>>>>
rtx dst0 = gen_rtx_SUBREG (SImode, dst, 0);
rtx dst1 = gen_rtx_SUBREG (SImode, dst, 4);
...
So, is this code otherwise not triggered and has it bitrotted, or is there
something specific about src that triggers the assert?
Assert looks like:
...
during RTL pass: mach
/home/vries/oacc/trunk/source-gcc/newlib/libc/stdlib/arc4random.c: In function
‘_rs_stir’:
/home/vries/oacc/trunk/source-gcc/newlib/libc/stdlib/arc4random.c:103:1:
internal compiler error: in gen_rtx_SUBREG, at emit-rtl.cc:1022
103 | }
| ^
0xde1b17 gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>)
/home/vries/oacc/trunk/source-gcc/gcc/emit-rtl.cc:1022
0x197aedc nvptx_gen_shuffle(rtx_def*, rtx_def*, rtx_def*, nvptx_shuffle_kind)
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:2000
0x1981165 nvptx_unisimt_handle_set
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:3303
0x19816af nvptx_reorg_uniform_simt
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:3386
0x1987bb7 nvptx_reorg
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.cc:5773
0x13c3e38 execute
/home/vries/oacc/trunk/source-gcc/gcc/reorg.cc:3927
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
...
The assert is triggered here in emit-rtl.c:
...
if (maybe_lt (osize, regsize)
&& ! (lra_in_progress && (FLOAT_MODE_P (imode) || FLOAT_MODE_P (omode))))
{
/* It is invalid for the target to pick a register size for a mode
that isn't ordered wrt to the size of that mode. */
poly_uint64 block_size = ordered_min (isize, regsize);
unsigned int start_reg;
poly_uint64 offset_within_reg;
if (!can_div_trunc_p (offset, block_size, &start_reg, &offset_within_reg)
|| (BYTES_BIG_ENDIAN
? maybe_ne (offset_within_reg, block_size - osize)
: maybe_ne (offset_within_reg, 0U)))
return false;
}
...
Specifially, this bit returns true, and causes the subreg validation error:
...
: maybe_ne (offset_within_reg, 0U)))
...
