[Bug middle-end/112510] [11/12/13/14 Regression]: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

--- Comment #17 from Vladimir Sadovnikov  ---
Reproducible with 11.4.0

~$ export ASAN_OPTIONS=detect_stack_use_after_return=1
~$ g++ -fsanitize=address -Og test-case.cpp
~$ ./a.out 
Aborted (core dumped)
~$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Not reproducible with 7.5.0:

sadko@tuf-gaming:~/tmp> export ASAN_OPTIONS=detect_stack_use_after_return=1
sadko@tuf-gaming:~/tmp> g++ -fsanitize=address -Og test-case.cpp
sadko@tuf-gaming:~/tmp> ./a.out 
sadko@tuf-gaming:~/tmp> gcc --version
gcc (SUSE Linux) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Generated code for 11.4.0:

11e9 <_Z3barP1SPc>:
11e9:   f3 0f 1e fa endbr64 
11ed:   40 f6 c7 3f test   $0x3f,%dil
11f1:   75 01   jne11f4 <_Z3barP1SPc+0xb>
11f3:   c3  ret
11f4:   48 83 ec 08 sub$0x8,%rsp
11f8:   e8 c3 fe ff ff  call   10c0
<__asan_handle_no_return@plt>
11fd:   e8 9e fe ff ff  call   10a0 

1202 <_Z3foov>:
1202:   f3 0f 1e fa endbr64 
1206:   55  push   %rbp
1207:   48 89 e5mov%rsp,%rbp
120a:   41 55   push   %r13
120c:   41 54   push   %r12
120e:   53  push   %rbx
120f:   48 83 e4 c0 and$0xffc0,%rsp
1213:   48 81 ec 00 01 00 00sub$0x100,%rsp
121a:   48 8d 5c 24 20  lea0x20(%rsp),%rbx
121f:   49 89 ddmov%rbx,%r13
1222:   83 3d e7 2d 00 00 00cmpl   $0x0,0x2de7(%rip)# 4010
<__asan_option_detect_stack_use_after_return@@Base>
1229:   0f 85 bb 00 00 00   jne12ea <_Z3foov+0xe8>
122f:   48 c7 03 b3 8a b5 41movq   $0x41b58ab3,(%rbx)
1236:   48 8d 05 c7 0d 00 00lea0xdc7(%rip),%rax# 2004
<_IO_stdin_used+0x4>
123d:   48 89 43 08 mov%rax,0x8(%rbx)
1241:   48 8d 05 ba ff ff fflea-0x46(%rip),%rax# 1202
<_Z3foov>
1248:   48 89 43 10 mov%rax,0x10(%rbx)
124c:   49 89 dcmov%rbx,%r12
124f:   49 c1 ec 03 shr$0x3,%r12
1253:   41 c7 84 24 00 80 ffmovl   $0xf1f1f1f1,0x7fff8000(%r12)
125a:   7f f1 f1 f1 f1 
125f:   41 c7 84 24 04 80 ffmovl   $0xf1f1f1f1,0x7fff8004(%r12)
1266:   7f f1 f1 f1 f1 
126b:   41 c7 84 24 08 80 ffmovl   $0xf201f1f1,0x7fff8008(%r12)
1272:   7f f1 f1 01 f2 
1277:   41 c7 84 24 14 80 ffmovl   $0xf3f3f3f3,0x7fff8014(%r12)
127e:   7f f3 f3 f3 f3 
1283:   64 48 8b 04 25 28 00mov%fs:0x28,%rax
128a:   00 00 
128c:   48 89 84 24 f8 00 00mov%rax,0xf8(%rsp)
1293:   00 
1294:   31 c0   xor%eax,%eax
1296:   48 8d 73 50 lea0x50(%rbx),%rsi
129a:   48 8d 7b 60 lea0x60(%rbx),%rdi
129e:   e8 46 ff ff ff  call   11e9 <_Z3barP1SPc>
12a3:   49 39 ddcmp%rbx,%r13
12a6:   75 5d   jne1305 <_Z3foov+0x103>
12a8:   49 c7 84 24 00 80 ffmovq   $0x0,0x7fff8000(%r12)
12af:   7f 00 00 00 00 
12b4:   41 c7 84 24 08 80 ffmovl   $0x0,0x7fff8008(%r12)
12bb:   7f 00 00 00 00 
12c0:   41 c7 84 24 14 80 ffmovl   $0x0,0x7fff8014(%r12)
12c7:   7f 00 00 00 00 
12cc:   48 8b 84 24 f8 00 00mov0xf8(%rsp),%rax
12d3:   00 
12d4:   64 48 2b 04 25 28 00sub%fs:0x28,%rax
12db:   00 00 
12dd:   75 65   jne1344 <_Z3foov+0x142>
12df:   48 8d 65 e8 lea-0x18(%rbp),%rsp
12e3:   5b  pop%rbx
12e4:   41 5c   pop%r12
12e6:   41 5d   pop%r13
12e8:   5d  pop%rbp
12e9:   c3  ret
12ea:   bf c0 00 00 00  mov$0xc0,%edi
12ef:   e8 ec fd ff ff  call   10e0 <__asan_stack_malloc_2@plt>
12f4:   48 85 c0test   %rax,%rax
12f7:   0f 84 32 ff ff ff   je 122f <_Z3foov+0x2d>
12fd:   48 89 c3mov%rax,%rbx
1300:   e9 2a ff ff ff  jmp122f <_Z3foov+0x2d>
1305:   48 c7 03 0e 36 e0 

[Bug middle-end/112510] [11/12/13/14 Regression]: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

--- Comment #15 from Vladimir Sadovnikov  ---
Hmmm. But why not? We're just looking for the value stored in %rbx register...

Here's scenario for GCC 7.5.0:

~/tmp> gcc --version
gcc (SUSE Linux) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~/tmp> g++ -fsanitize=address -mavx512f -Og test.cpp
~/tmp> export ASAN_OPTIONS=detect_stack_use_after_return=1
~/tmp> ./a.out 
Illegal instruction (core dumped)
~/tmp> gdb ./a.out 
GNU gdb (GDB; SUSE Linux Enterprise 15) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...
(gdb) r
Starting program: /home/sadko/tmp/a.out 
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.31-150300.63.1.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x004007ce in gate_x1_curve(float*, float const*, dsp::gate_knee_t
const*, unsigned long) ()
Missing separate debuginfos, use: zypper install
libasan4-debuginfo-7.5.0+r278197-15.4.35.1.x86_64
libgcc_s1-debuginfo-13.2.1+git7813-15.1.3.3.x86_64
libstdc++6-debuginfo-13.2.1+git7813-15.1.3.3.x86_64
(gdb) disp /16i $pc
2: x/16i $pc
=> 0x4007ce <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+167>: vbroadcastss
(%r15),%zmm0
   0x4007d4 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+173>: vbroadcastss
0x4(%r15),%zmm1
   0x4007db <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+180>: vbroadcastss
0x8(%r15),%zmm2
   0x4007e2 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+187>: vbroadcastss
0xc(%r15),%zmm3
   0x4007e9 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+194>: vbroadcastss
0x10(%r15),%zmm4
   0x4007f0 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+201>: vbroadcastss
0x14(%r15),%zmm5
   0x4007f7 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+208>: vbroadcastss
0x18(%r15),%zmm6
   0x4007fe <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+215>: vbroadcastss
0x1c(%r15),%zmm7
   0x400805 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+222>: vmovaps
%zmm0,0x140(%rbx)
   0x40080c <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+229>: vmovaps
%zmm1,0x180(%rbx)
   0x400813 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+236>: vmovaps
%zmm2,0x1c0(%rbx)
   0x40081a <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+243>: vmovaps
%zmm3,0x200(%rbx)
   0x400821 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+250>: vmovaps
%zmm4,0x240(%rbx)
   0x400828 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+257>: vmovaps
%zmm5,0x280(%rbx)
   0x40082f <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+264>: vmovaps
%zmm6,0x2c0(%rbx)
   0x400836 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+271>: vmovaps
%zmm7,0x300(%rbx)
(gdb) i r rbx
rbx0x7390  140737279688704

[Bug middle-end/112510] [11/12/13/14 Regression]: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

--- Comment #14 from Vladimir Sadovnikov  ---
Seems that with GCC 7.6 it also will be reproducible because we have the same
code there:

```
  40089c:   bf 80 03 00 00  mov$0x380,%edi
  4008a1:   e8 6a fd ff ff  call   400610
<__asan_stack_malloc_4@plt>
  4008a6:   48 85 c0test   %rax,%rax
  4008a9:   0f 84 bb fe ff ff   je 40076a
<_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+0x43>
  4008af:   48 89 c3mov%rax,%rbx
  4008b2:   e9 b3 fe ff ff  jmp40076a
<_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+0x43>
  4008b7:   48 c7 03 0e 36 e0 45movq   $0x45e0360e,(%rbx)
```

I'm not able to run it because it is compiled on machine which does not support
AVX512.

[Bug middle-end/112510] [11/12/13/14 Regression]: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

--- Comment #13 from Vladimir Sadovnikov  ---
Here is the full scenario:

~$ g++ --version
g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~$ g++ -fsanitize=address -mavx512f -Og test.cpp
~$ export ASAN_OPTIONS=detect_stack_use_after_return=0
~$ ./a.out 
~$ export ASAN_OPTIONS=detect_stack_use_after_return=1

~$ ./a.out 
AddressSanitizer:DEADLYSIGNAL
=
==1507764==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x5573dbd162dc
bp 0x7fffd196ba60 sp 0x7fffd196b640 T0)
==1507764==The signal is caused by a READ memory access.
==1507764==Hint: this fault was caused by a dereference of a high value address
(see register values below).  Dissassemble the provided pc to learn which
register was used.
#0 0x5573dbd162dc in gate_x1_curve(float*, float const*, dsp::gate_knee_t
const*, unsigned long) (/home/sadko/a.out+0x12dc)
#1 0x5573dbd1664e in main (/home/sadko/a.out+0x164e)
#2 0x7f50b61f0d8f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#3 0x7f50b61f0e3f in __libc_start_main_impl ../csu/libc-start.c:392
#4 0x5573dbd16124 in _start (/home/sadko/a.out+0x1124)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/home/sadko/a.out+0x12dc) in
gate_x1_curve(float*, float const*, dsp::gate_knee_t const*, unsigned long)
==1507764==ABORTING

~$ gdb a.out
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...
(gdb) r
Starting program: /home/sadko/a.out 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x52dc in gate_x1_curve(float*, float const*, dsp::gate_knee_t
const*, unsigned long) ()
(gdb) display /10i $pc
1: x/10i $pc
=> 0x52dc <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+243>:   vmovaps
%zmm0,0x120(%rbx)
   0x52e6 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+253>:   vmovaps
%zmm1,0x160(%rbx)
   0x52f0 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+263>:   vmovaps
%zmm2,0x1a0(%rbx)
   0x52fa <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+273>:   vmovaps
%zmm3,0x1e0(%rbx)
   0x5304 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+283>:   vmovaps
%zmm4,0x220(%rbx)
   0x530e <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+293>:   vmovaps
%zmm5,0x260(%rbx)
   0x5318 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+303>:   vmovaps
%zmm6,0x2a0(%rbx)
   0x5322 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+313>:   vmovaps
%zmm7,0x2e0(%rbx)
   0x532c <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+323>:   cmp   
%rbx,0x18(%rsp)
   0x5331 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+328>:   jne   
0x53a8 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+447>
(gdb) i r rbx
rbx0x73df9000  140737284902912
(gdb)

[Bug middle-end/112510] [11/12/13/14 Regression]: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

--- Comment #12 from Vladimir Sadovnikov  ---
Oh wow, it seems that this makes the code to crash:

```
export ASAN_OPTIONS=detect_stack_use_after_return=1

./test
```

[Bug middle-end/112510] [11/12/13/14 Regression]: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

--- Comment #11 from Vladimir Sadovnikov  ---
I mean, this code may work in improper way if ASAN allocates only 0x20 bytes on
the stack:

```
138d:   bf 80 03 00 00  mov$0x380,%edi
1392:   e8 39 fd ff ff  call   10d0 <__asan_stack_malloc_4@plt>
1397:   48 85 c0test   %rax,%rax
139a:   0f 84 88 fe ff ff   je 1228
<_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+0x3f>
13a0:   48 89 c3mov%rax,%rbx
13a3:   e9 80 fe ff ff  jmp1228
<_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+0x3f>
13a8:   48 c7 03 0e 36 e0 45movq   $0x45e0360e,(%rbx)
13af:   48 be f5 f5 f5 f5 f5movabs $0xf5f5f5f5f5f5f5f5,%rsi
```

[Bug middle-end/112510] [11/12/13/14 Regression]: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

--- Comment #10 from Vladimir Sadovnikov  ---
Sorry, I messed up %rbx with loading %rdx from stack.

But it seems that the ASAN-reladed code somehow modifies %rbx.
And now I'm not sure that the code generated by GCC 11.4.0 will work under
certain conditions.

It looks like the problem is not in the header of the function but at the tail,
where the additional ASAN-related code is added.

[Bug middle-end/112510] Regression: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

--- Comment #7 from Vladimir Sadovnikov  ---
Disassembly for GCC 11.4.0:

```
11e9 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm>:
11e9:   f3 0f 1e fa endbr64 
11ed:   55  push   %rbp
11ee:   48 89 e5mov%rsp,%rbp
11f1:   41 57   push   %r15
11f3:   41 56   push   %r14
11f5:   41 55   push   %r13
11f7:   41 54   push   %r12
11f9:   53  push   %rbx
11fa:   48 83 e4 c0 and$0xffc0,%rsp
11fe:   48 81 ec c0 03 00 00sub$0x3c0,%rsp
1205:   49 89 fcmov%rdi,%r12
1208:   49 89 f5mov%rsi,%r13
120b:   49 89 d7mov%rdx,%r15
120e:   49 89 cemov%rcx,%r14
1211:   48 8d 5c 24 20  lea0x20(%rsp),%rbx
1216:   48 89 5c 24 18  mov%rbx,0x18(%rsp)
121b:   83 3d ee 2d 00 00 00cmpl   $0x0,0x2dee(%rip)# 4010
<__asan_option_detect_stack_use_after_return@@Base>
1222:   0f 85 65 01 00 00   jne138d
<_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+0x1a4>
1228:   48 c7 03 b3 8a b5 41movq   $0x41b58ab3,(%rbx)
122f:   48 8d 05 d2 0d 00 00lea0xdd2(%rip),%rax# 2008
<_IO_stdin_used+0x8>
1236:   48 89 43 08 mov%rax,0x8(%rbx)
123a:   48 8d 05 a8 ff ff fflea-0x58(%rip),%rax# 11e9
<_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm>
1241:   48 89 43 10 mov%rax,0x10(%rbx)
1245:   48 89 d8mov%rbx,%rax
1248:   48 c1 e8 03 shr$0x3,%rax
124c:   c7 80 00 80 ff 7f f1movl   $0xf1f1f1f1,0x7fff8000(%rax)
1253:   f1 f1 f1 
1256:   c7 80 08 80 ff 7f f2movl   $0xf2f2f2f2,0x7fff8008(%rax)
125d:   f2 f2 f2 
1260:   c7 80 1c 80 ff 7f f2movl   $0xf2f2f2f2,0x7fff801c(%rax)
1267:   f2 f2 f2 
126a:   c7 80 20 80 ff 7f f2movl   $0xf2f2f2f2,0x7fff8020(%rax)
1271:   f2 f2 f2 
1274:   c7 80 64 80 ff 7f f3movl   $0xf3f3f3f3,0x7fff8064(%rax)
127b:   f3 f3 f3 
127e:   c7 80 68 80 ff 7f f3movl   $0xf3f3f3f3,0x7fff8068(%rax)
1285:   f3 f3 f3 
1288:   c7 80 6c 80 ff 7f f3movl   $0xf3f3f3f3,0x7fff806c(%rax)
128f:   f3 f3 f3 
1292:   64 48 8b 14 25 28 00mov%fs:0x28,%rdx
1299:   00 00 
129b:   48 89 94 24 b8 03 00mov%rdx,0x3b8(%rsp)
12a2:   00 
12a3:   31 d2   xor%edx,%edx
12a5:   62 d2 7d 48 18 07   vbroadcastss (%r15),%zmm0
12ab:   62 d2 7d 48 18 4f 01vbroadcastss 0x4(%r15),%zmm1
12b2:   62 d2 7d 48 18 57 02vbroadcastss 0x8(%r15),%zmm2
12b9:   62 d2 7d 48 18 5f 03vbroadcastss 0xc(%r15),%zmm3
12c0:   62 d2 7d 48 18 67 04vbroadcastss 0x10(%r15),%zmm4
12c7:   62 d2 7d 48 18 6f 05vbroadcastss 0x14(%r15),%zmm5
12ce:   62 d2 7d 48 18 77 06vbroadcastss 0x18(%r15),%zmm6
12d5:   62 d2 7d 48 18 7f 07vbroadcastss 0x1c(%r15),%zmm7
12dc:   62 f1 7c 48 29 83 20vmovaps %zmm0,0x120(%rbx)
12e3:   01 00 00 
12e6:   62 f1 7c 48 29 8b 60vmovaps %zmm1,0x160(%rbx)
12ed:   01 00 00 
12f0:   62 f1 7c 48 29 93 a0vmovaps %zmm2,0x1a0(%rbx)
12f7:   01 00 00 
12fa:   62 f1 7c 48 29 9b e0vmovaps %zmm3,0x1e0(%rbx)
1301:   01 00 00 
1304:   62 f1 7c 48 29 a3 20vmovaps %zmm4,0x220(%rbx)
130b:   02 00 00 
130e:   62 f1 7c 48 29 ab 60vmovaps %zmm5,0x260(%rbx)
1315:   02 00 00 
1318:   62 f1 7c 48 29 b3 a0vmovaps %zmm6,0x2a0(%rbx)
131f:   02 00 00 
1322:   62 f1 7c 48 29 bb e0vmovaps %zmm7,0x2e0(%rbx)
1329:   02 00 00 
```

Here we have offsets multiple of 0x20 but not multiple of 0x40 but missing
strange load of %rbx from stack. It is reasonable because of this instruction:
```
1211:   48 8d 5c 24 20  lea0x20(%rsp),%rbx
```

All works fine.

gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug middle-end/112510] Regression: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

--- Comment #6 from Vladimir Sadovnikov  ---
Here is disassembly of `test.cpp` function for GCC 7.5.0:

```
00400727 <_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm>:
  400727:   4c 8d 54 24 08  lea0x8(%rsp),%r10
  40072c:   48 83 e4 c0 and$0xffc0,%rsp
  400730:   41 ff 72 f8 push   -0x8(%r10)
  400734:   55  push   %rbp
  400735:   48 89 e5mov%rsp,%rbp
  400738:   41 57   push   %r15
  40073a:   41 56   push   %r14
  40073c:   41 55   push   %r13
  40073e:   41 54   push   %r12
  400740:   41 52   push   %r10
  400742:   53  push   %rbx
  400743:   48 81 ec 80 03 00 00sub$0x380,%rsp
  40074a:   49 89 fcmov%rdi,%r12
  40074d:   49 89 f5mov%rsi,%r13
  400750:   49 89 d7mov%rdx,%r15
  400753:   49 89 cemov%rcx,%r14
  400756:   48 8d 9d 50 fc ff fflea-0x3b0(%rbp),%rbx
  40075d:   83 3d 1c 19 00 00 00cmpl   $0x0,0x191c(%rip)#
402080 <__asan_option_detect_stack_use_after_return@@Base>
  400764:   0f 85 32 01 00 00   jne40089c
<_Z13gate_x1_curvePfPKfPKN3dsp11gate_knee_tEm+0x175>
  40076a:   48 c7 03 b3 8a b5 41movq   $0x41b58ab3,(%rbx)
  400771:   48 c7 43 08 f8 0c 40movq   $0x400cf8,0x8(%rbx)
  400778:   00 
  400779:   48 c7 43 10 27 07 40movq   $0x400727,0x10(%rbx)
  400780:   00 
  400781:   48 89 dfmov%rbx,%rdi
  400784:   48 c1 ef 03 shr$0x3,%rdi
  400788:   c7 87 00 80 ff 7f f1movl   $0xf1f1f1f1,0x7fff8000(%rdi)
  40078f:   f1 f1 f1 
  400792:   c7 87 04 80 ff 7f f1movl   $0xf1f1f1f1,0x7fff8004(%rdi)
  400799:   f1 f1 f1 
  40079c:   c7 87 0c 80 ff 7f f2movl   $0xf2f2f2f2,0x7fff800c(%rdi)
  4007a3:   f2 f2 f2 
  4007a6:   c7 87 20 80 ff 7f f2movl   $0xf2f2f2f2,0x7fff8020(%rdi)
  4007ad:   f2 f2 f2 
  4007b0:   c7 87 24 80 ff 7f f2movl   $0xf2f2f2f2,0x7fff8024(%rdi)
  4007b7:   f2 f2 f2 
  4007ba:   c7 87 68 80 ff 7f f3movl   $0xf3f3f3f3,0x7fff8068(%rdi)
  4007c1:   f3 f3 f3 
  4007c4:   c7 87 6c 80 ff 7f f3movl   $0xf3f3f3f3,0x7fff806c(%rdi)
  4007cb:   f3 f3 f3 
  4007ce:   62 d2 7d 48 18 07   vbroadcastss (%r15),%zmm0
  4007d4:   62 d2 7d 48 18 4f 01vbroadcastss 0x4(%r15),%zmm1
  4007db:   62 d2 7d 48 18 57 02vbroadcastss 0x8(%r15),%zmm2
  4007e2:   62 d2 7d 48 18 5f 03vbroadcastss 0xc(%r15),%zmm3
  4007e9:   62 d2 7d 48 18 67 04vbroadcastss 0x10(%r15),%zmm4
  4007f0:   62 d2 7d 48 18 6f 05vbroadcastss 0x14(%r15),%zmm5
  4007f7:   62 d2 7d 48 18 77 06vbroadcastss 0x18(%r15),%zmm6
  4007fe:   62 d2 7d 48 18 7f 07vbroadcastss 0x1c(%r15),%zmm7
  400805:   62 f1 7c 48 29 43 05vmovaps %zmm0,0x140(%rbx)
  40080c:   62 f1 7c 48 29 4b 06vmovaps %zmm1,0x180(%rbx)
  400813:   62 f1 7c 48 29 53 07vmovaps %zmm2,0x1c0(%rbx)
  40081a:   62 f1 7c 48 29 5b 08vmovaps %zmm3,0x200(%rbx)
  400821:   62 f1 7c 48 29 63 09vmovaps %zmm4,0x240(%rbx)
  400828:   62 f1 7c 48 29 6b 0avmovaps %zmm5,0x280(%rbx)
  40082f:   62 f1 7c 48 29 73 0bvmovaps %zmm6,0x2c0(%rbx)
  400836:   62 f1 7c 48 29 7b 0cvmovaps %zmm7,0x300(%rbx)
```

gcc --version
gcc (SUSE Linux) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

As we see, there is  no load of %rbx from stack and all offsets are multiple of
0x40.

[Bug c++/112510] Regression: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

Vladimir Sadovnikov  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |---

--- Comment #3 from Vladimir Sadovnikov  ---
The resolution was set invalid because I explicitly specify the alignment of
variables on the stack.

[Bug c++/112510] Regression: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

Vladimir Sadovnikov  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from Vladimir Sadovnikov  ---
I actually do this by specifying:

```
#define __lsp_aligned64 __attribute__ ((aligned (64)))
```

[Bug c++/112510] New: Regression: ASAN code injection breaks alignment of stack variables

[sadko4u at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112510

Bug ID: 112510
   Summary: Regression: ASAN code injection breaks alignment of
stack variables
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sadko4u at gmail dot com
  Target Milestone: ---

Created attachment 56568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56568=edit
Code snippet that can cause the problem

Hello!

I've met a problem on Github CI while introducing AVX-512 support to my DSP
code when using ASAN and was able to find out what's happening only in few
launches.

The problem run starts here:
https://github.com/lsp-plugins/lsp-plugins-beat-breather/actions/runs/6843768144/job/18606721058#step:12:49

We observe a disassembly code that crashed:
```
=> 0x7f3bdb82df53
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm+247>:vmovaps
%zmm0,0x120(%rbx)
   0x7f3bdb82df5d
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm+257>:vmovaps
%zmm1,0x160(%rbx)
   0x7f3bdb82df67
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm+267>:vmovaps
%zmm2,0x1a0(%rbx)
   0x7f3bdb82df71
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm+277>:vmovaps
%zmm3,0x1e0(%rbx)
   0x7f3bdb82df7b
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm+287>:vmovaps
%zmm4,0x220(%rbx)
   0x7f3bdb82df85
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm+297>:vmovaps
%zmm5,0x260(%rbx)
   0x7f3bdb82df8f
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm+307>:vmovaps
%zmm6,0x2a0(%rbx)
   0x7f3bdb82df99
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm+317>:vmovaps
%zmm7,0x2e0(%rbx)
```

As we see, the offset to the %rbx register is not 64-byte aligned while the
%rbx register is:
```
rbx0x7f3bd9d20400  139895034217472
```

If we disassemble the heading of the function, then we see:
```
(gdb) Dump of assembler code for function
_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm:
   0x7f3bdb82de5c <+0>: push   %rbp
   0x7f3bdb82de5d <+1>: mov%rsp,%rbp
   0x7f3bdb82de60 <+4>: push   %r15
   0x7f3bdb82de62 <+6>: push   %r14
   0x7f3bdb82de64 <+8>: push   %r13
   0x7f3bdb82de66 <+10>:push   %r12
   0x7f3bdb82de68 <+12>:push   %rbx
   0x7f3bdb82de69 <+13>:and$0xffc0,%rsp
   0x7f3bdb82de6d <+17>:sub$0x3c0,%rsp
   0x7f3bdb82de74 <+24>:mov%rdi,%r12
   0x7f3bdb82de77 <+27>:mov%rsi,%r13
   0x7f3bdb82de7a <+30>:mov%rdx,%r14
   0x7f3bdb82de7d <+33>:mov%rcx,0x18(%rsp)
   0x7f3bdb82de82 <+38>:lea0x20(%rsp),%rbx
   0x7f3bdb82de87 <+43>:mov%rbx,%r15
   0x7f3bdb82de8a <+46>:mov0x15f13f(%rip),%rax#
0x7f3bdb98cfd0
   0x7f3bdb82de91 <+53>:cmpl   $0x0,(%rax)
   0x7f3bdb82de94 <+56>:jne0x7f3bdb82eba0
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm+3396>
   0x7f3bdb82de9a <+62>:movq   $0x41b58ab3,(%rbx)
   0x7f3bdb82dea1 <+69>:lea0x95bb0(%rip),%rax#
0x7f3bdb8c3a58
   0x7f3bdb82dea8 <+76>:mov%rax,0x8(%rbx)
   0x7f3bdb82deac <+80>:lea-0x57(%rip),%rax# 0x7f3bdb82de5c
<_ZN3lsp6avx51213gate_x1_curveEPfPKfPKNS_3dsp11gate_knee_tEm>
   0x7f3bdb82deb3 <+87>:mov%rax,0x10(%rbx)
   0x7f3bdb82deb7 <+91>:mov%rbx,%rax
   0x7f3bdb82deba <+94>:shr$0x3,%rax
   0x7f3bdb82debe <+98>:movl   $0xf1f1f1f1,0x7fff8000(%rax)
   0x7f3bdb82dec8 <+108>:   movl   $0xf2f2f2f2,0x7fff8008(%rax)
   0x7f3bdb82ded2 <+118>:   movl   $0xf2f2f2f2,0x7fff801c(%rax)
   0x7f3bdb82dedc <+128>:   movl   $0xf2f2f2f2,0x7fff8020(%rax)
   0x7f3bdb82dee6 <+138>:   movl   $0xf3f3f3f3,0x7fff8064(%rax)
   0x7f3bdb82def0 <+148>:   movl   $0xf3f3f3f3,0x7fff8068(%rax)
   0x7f3bdb82defa <+158>:   movl   $0xf3f3f3f3,0x7fff806c(%rax)
   0x7f3bdb82df04 <+168>:   mov%fs:0x28,%rdx
   0x7f3bdb82df0d <+177>:   mov%rdx,0x3b8(%rsp)
   0x7f3bdb82df15 <+185>:   xor%edx,%edx
   0x7f3bdb82df17 <+187>:   mov0x18(%rsp),%rdx
   0x7f3bdb82df1c <+192>:   vbroadcastss (%r14),%zmm0
   0x7f3bdb82df22 <+198>:   vbroadcastss 0x4(%r14),%zmm1
   0x7f3bdb82df29 <+205>:   vbroadcastss 0x8(%r14),%zmm2
   0x7f3bdb82df30 <+212>:   vbroadcastss 0xc(%r14),%zmm3
   0x7f3bdb82df37 <+219>:   vbroadcastss 0x10(%r14),%zmm4
   0x7f3bdb82df3e <+226>:   vbroadcastss 0x14(%r14),%zmm5
   0x7f3bdb82df45 <+233>:   vbroadcastss 0x18(%r14),%zmm6
   0x7f3bdb82df4c <+240>:   vbroadcastss 0x1c(%r14),%zmm7
=> 0x7f3bdb82df53 <+247>:   vmovaps %zmm0,0x120(%rbx)
   0x7f3bdb82df5d <+257>:   vmovaps %zmm1,0x160(%rbx)
   0x7f3bdb82df67 <+267>: