asan_expand_mark_ifn asserts that the length to check is a SHWI. (i.e. it uses `gcc_assert (tree_fits_shwi_p (len))` ). It attempts to ensure this by avoiding VLA's in `gimplify_decl_expr`. poly_int sized decls were added, and they were not treated as VLA's since commit 22b62991 (SVN r275870). Since then, poly_int sized variables can have ASAN_MARK called on them, which means the `len` parameter of ASAN_MARK can be a poly_int causing an ICE in asan_expand_mark_ifn (n.b. in order to emit an ASAN_CHECK on a poly_int sized variable so that the ASAN_MARK is not removed in the sanopt pass we need to pass the poly_int sized variable to a builtin memory function). An example (modified from gcc/testsuite/c-c++-common/asan/pr80308.c): (v3) work-lin:gcc [Tue 12:25:10] % cat ~/asan-ice.c #include <arm_sve.h> __attribute__((noinline, noclone)) int foo (char *a) { int i, j = 0; asm volatile ("" : "+r" (a) : : "memory"); for (i = 0; i < 12; i++) j += a[i]; return j; } int main () { int i, j = 0; for (i = 0; i < 4; i++) { char a[12]; __SVInt8_t freq; __builtin_bcmp (&freq, a, 10); __builtin_memset (a, 0, sizeof (a)); j += foo (a); } return j; } (v3) work-lin:gcc [Tue 12:31:53] % /installdir/aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -march=armv8.6-a+sve -fsanitize=address -fsanitize-address-use-after-scope ~/asan-ice.c -S -o /dev/null during GIMPLE pass: sanopt /home/matmal01/asan-ice.c: In function ‘main’: /home/matmal01/asan-ice.c:14:1: internal compiler error: in asan_expand_mark_ifn, at asan.c:3235 14 | main () | ^~~~ 0xdde454 asan_expand_mark_ifn(gimple_stmt_iterator*) /builddir/src/gcc/gcc/asan.c:3235 0xdf6b7a execute /builddir/src/gcc/gcc/sanopt.c:1341 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
I guess this may also happen for the emission of ASAN_MARK in `gimple_target_expr`, but haven't yet been able to trigger that.
Hi, Can this be actioned/ fixed? We had a related issue and would like this fixed. https://github.com/numpy/numpy/issues/25556 Thank you. Rama
Created attachment 57520 [details] Candidate patch The attached patch seems to fix it. I'm taking next week off, but I'll run the patch through proper testing when I get back.
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>: https://gcc.gnu.org/g:fca6f6fddb22b8665e840f455a7d0318d4575227 commit r14-9324-gfca6f6fddb22b8665e840f455a7d0318d4575227 Author: Richard Sandiford <richard.sandiford@arm.com> Date: Tue Mar 5 19:48:25 2024 +0000 asan: Handle poly-int sizes in ASAN_MARK [PR97696] This patch makes the expansion of IFN_ASAN_MARK let through poly-int-sized objects. The expansion itself was already generic enough, but the tests for the fast path were too strict. gcc/ PR sanitizer/97696 * asan.cc (asan_expand_mark_ifn): Allow the length to be a poly_int. gcc/testsuite/ PR sanitizer/97696 * gcc.target/aarch64/sve/pr97696.c: New test.
Thank you Richard for this patch/ fix.
The releases/gcc-13 branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>: https://gcc.gnu.org/g:86b80b049167d28a9ef43aebdfbb80ae5deb0888 commit r13-8501-g86b80b049167d28a9ef43aebdfbb80ae5deb0888 Author: Richard Sandiford <richard.sandiford@arm.com> Date: Wed Mar 27 15:30:19 2024 +0000 asan: Handle poly-int sizes in ASAN_MARK [PR97696] This patch makes the expansion of IFN_ASAN_MARK let through poly-int-sized objects. The expansion itself was already generic enough, but the tests for the fast path were too strict. gcc/ PR sanitizer/97696 * asan.cc (asan_expand_mark_ifn): Allow the length to be a poly_int. gcc/testsuite/ PR sanitizer/97696 * gcc.target/aarch64/sve/pr97696.c: New test. (cherry picked from commit fca6f6fddb22b8665e840f455a7d0318d4575227)
The releases/gcc-12 branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>: https://gcc.gnu.org/g:51e1629bc11f0ae4b8050712b26521036ed360aa commit r12-10296-g51e1629bc11f0ae4b8050712b26521036ed360aa Author: Richard Sandiford <richard.sandiford@arm.com> Date: Wed Mar 27 17:38:09 2024 +0000 asan: Handle poly-int sizes in ASAN_MARK [PR97696] This patch makes the expansion of IFN_ASAN_MARK let through poly-int-sized objects. The expansion itself was already generic enough, but the tests for the fast path were too strict. gcc/ PR sanitizer/97696 * asan.cc (asan_expand_mark_ifn): Allow the length to be a poly_int. gcc/testsuite/ PR sanitizer/97696 * gcc.target/aarch64/sve/pr97696.c: New test. (cherry picked from commit fca6f6fddb22b8665e840f455a7d0318d4575227)
The releases/gcc-11 branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>: https://gcc.gnu.org/g:d98467091bfc23522fefd32f1253e1c9e80331d3 commit r11-11296-gd98467091bfc23522fefd32f1253e1c9e80331d3 Author: Richard Sandiford <richard.sandiford@arm.com> Date: Wed Mar 27 19:26:57 2024 +0000 asan: Handle poly-int sizes in ASAN_MARK [PR97696] This patch makes the expansion of IFN_ASAN_MARK let through poly-int-sized objects. The expansion itself was already generic enough, but the tests for the fast path were too strict. gcc/ PR sanitizer/97696 * asan.c (asan_expand_mark_ifn): Allow the length to be a poly_int. gcc/testsuite/ PR sanitizer/97696 * gcc.target/aarch64/sve/pr97696.c: New test. (cherry picked from commit fca6f6fddb22b8665e840f455a7d0318d4575227)
Fixed on trunk and all active release branches.