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