https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88619
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Ok, so the problem was latent, for:
$ cat /tmp/ice.i
typedef int aligned __attribute__((aligned(64)));
int main () {
aligned b;
int *p = &b;
*(p - 1) = 123;
__builtin_alloca(b);
}
if I apply following debugging patch:
diff --git a/gcc/asan.c b/gcc/asan.c
index 45906bf8fee..3bf956c0aef 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1423,6 +1423,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned
int alignb,
prev_offset = base_offset;
for (l = length; l; l -= 2)
{
+ fprintf (stderr, "RZ: %d - %d\n", offsets[l-1], offsets[l-2]);
if (l == 2)
cur_shadow_byte = ASAN_STACK_MAGIC_RIGHT;
offset = offsets[l - 1];
I see before the revision:
RZ: -96 - -64
RZ: -60 - -64
and:
This frame has 1 object(s):
[32, 36) 'b' (line 3) <== Memory access at offset 28 underflows this ...
0x10007fff7b60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7b70: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1[f1]
0x10007fff7b80: 04 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
which is problematic as -60 > -64, the ranges should be increasing. As seen we
end with a wrong red zone ending with f2. That's caused by the old code that
emits always 4B of shadow memory at once.
So the problem is the alignment manipulation in expand_stack_vars that causes
the discrepancy. Jakub any idea how to fix that?
