This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/88291] New: [9 Regression] asan ICE in asan_clear_shadow
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 01 Dec 2018 09:57:10 +0000
- Subject: [Bug sanitizer/88291] New: [9 Regression] asan ICE in asan_clear_shadow
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88291
Bug ID: 88291
Summary: [9 Regression] asan ICE in asan_clear_shadow
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
As mentioned in PR88289, e.g. on clone-test-1.c with -Os gcc ICEs on
powerpc64-linux.
I get the same ICE on x86_64-linux with -fsanitize=address -Os
-mstringop-strategy=libcall on:
void bar (void *, void *);
void
foo (void)
{
int b;
char __attribute__((aligned(16))) a[(1 << 20) + 1];
bar (&a, &b);
}
The assert that the length is a multiple of 4 is done only if clear_storage
decided to use a libcall, which is why it doesn't trigger all the time
everywhere.
Like for the initialization of the shadow memory at the start of the function,
the clearing at the end should also do the rounding to multiples of 32 of the
offset and similarly pad the size to multiples of 32 (before the >> 3).