On 12/18/24 1:17 PM, Patrick O'Neill wrote:
Based on a comment from Andreas I suspect Filip's patch is causing an out of memory issue. That would be consistent with the failure mode in the log file I saw *and* the build time regression Andreas and Mark W. have reported.On 12/18/24 15:09, Jeff Law wrote:On 12/17/24 8:27 AM, Robin Dapp wrote:Pre-commit testing showed a build failure. No really useful error messages in the log and I'm not 100% convinced its your patch.Hi, in PR117682 we build an interleaving pattern { 1, 201, 209, 25, 161, 105, 113, 185, 65, 9, 17, 89, 225, 169, 177, 249, 129, 73, 81, 153, 33, 233, 241, 57, 193, 137, 145, 217, 97, 41, 49, 121 }; with negative step expecting wraparound semantics due to -fwrapv. For building interleaved patterns we have an optimization that does e.g. {1, 209, ...} = { 1, 0, 209, 0, ...} and {201, 25, ...} >> 8 = { 0, 201, 0, 25, ...} and IORs those. The optimization only works if the lowpart bits are zero. When overflowing e.g. with a negative step we cannot guarantee this. This patch makes us fall back to the generic merge handling for negative steps. I'm not 100% certain we're good even for positive steps. If the step or the vector length is large enough we'd still overflow and have non-zero lower bits. I haven't seen this happen during my testing, though and the patch doesn't make things worse, so... Regtested on rv64gcv_zvl512b. Let's see what the CI says. Regards Robin PR target/117682 gcc/ChangeLog: * config/riscv/riscv-v.cc (expand_const_vector): Fall back to merging if either step is negative. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr117682.c: New test.g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE - fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno- error=narrowing -Wwrite-strings -Wcast-qual -Wmissing-format- attribute -Wconditionally-supported -Woverloaded-virtual -pedantic - Wno-long-long -Wno-variadic-macros -Wno-overlength-strings - DHAVE_CONFIG_H -fno-PIE -I. -I. -I../../../gcc/gcc -I../../../gcc/ gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/ include -I../../../gcc/gcc/../libcody -I../../../gcc/gcc/../ libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace -o gimple-match-4.o -MT gimple- match-4.o -MMD -MP -MF ./.deps/gimple-match-4.TPo gimple-match-4.cc make[2]: Leaving directory '/home/runner/work/gcc-precommit-ci/gcc- precommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage1/gcc'g++: fatal error: Killed signal terminated program cc1plus compilation terminated. make[2]: *** [Makefile:1208: gimple-match-4.o] Error 1Note how we didn't get a backtrace. Hard to know if it's really your patch or not given the lack of data here.jeffEdwin noticed this yesterday - It hasn't been fully investigated yet but Github's runners seem to have some instability recently.
Jeff
