https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The trunk branch has been updated by Richard Sandiford <rsand...@gcc.gnu.org>: https://gcc.gnu.org/g:0970ff46ba6330fc80e8736fc05b2eaeeae0b6a0 commit r15-1244-g0970ff46ba6330fc80e8736fc05b2eaeeae0b6a0 Author: Richard Sandiford <richard.sandif...@arm.com> Date: Thu Jun 13 12:48:21 2024 +0100 aarch64: Fix invalid nested subregs [PR115464] The testcase extracts one arm_neon.h vector from a pair (one subreg) and then reinterprets the result as an SVE vector (another subreg). Each subreg makes sense individually, but we can't fold them together into a single subreg: it's 32 bytes -> 16 bytes -> 16*N bytes, but the interpretation of 32 bytes -> 16*N bytes depends on whether N==1 or N>1. Since the second subreg makes sense individually, simplify_subreg should bail out rather than ICE on it. simplify_gen_subreg will then do the same (because it already checks validate_subreg). This leaves simplify_gen_subreg returning null, requiring the caller to take appropriate action. I think this is relatively likely to occur elsewhere, so the patch adds a helper for forcing a subreg, allowing a temporary pseudo to be created where necessary. I'll follow up by using force_subreg in more places. This patch is intended to be a minimal backportable fix for the PR. gcc/ PR target/115464 * simplify-rtx.cc (simplify_context::simplify_subreg): Don't try to fold two subregs together if their relationship isn't known at compile time. * explow.h (force_subreg): Declare. * explow.cc (force_subreg): New function. * config/aarch64/aarch64-sve-builtins-base.cc (svset_neonq_impl::expand): Use it instead of simplify_gen_subreg. gcc/testsuite/ PR target/115464 * gcc.target/aarch64/sve/acle/general/pr115464.c: New test.
