Eric Botcazou wrote: >> No, the stack never gets misaligned - my patch doesn't change that at all. > > Yes, it does.
No. Look at the diffs, there is not a single change in alignment anywhere for all of the alloca variants. If the alignment is incorrect after my patch, it is also incorrect before my patch. This is the diff for pr78668.c on AArch64: >diff pr78668.before pr78668.after < add x0, x0, 18 --- > add x0, x0, 15 90c90 < add x0, x0, 18 --- > add x0, x0, 15 120c120 < add x0, x0, 22 --- > add x0, x0, 15 149c149 < add x0, x0, 22 --- > add x0, x0, 15 179c179 < add x0, x0, 30 --- > add x0, x0, 15 208c208 < add x0, x0, 30 --- > add x0, x0, 15 238c238 < add x0, x0, 46 --- > add x0, x0, 31 268c268 < add x0, x0, 46 --- > add x0, x0, 31 The mid-end always ensures that the stack is decremented by a value that is a multiple of STACK_BOUNDARY. My change does not make any difference here, but if SP is not aligned to STACK_BOUNDARY then it's obviously broken before my patch. For example the relevant instructions for t2_a8 are: add x0, x0, 15 and x0, x0, -16 sub sp, sp, x0 add x0, sp, 32 As you can see, it always rounds up and aligns to STACK_BOUNDARY before adjusting SP. When computing the final alloca address (the last add above) you must also keep that STACK_BOUNDARY alignment. To conclude my change just avoids inserting redundant padding based on the alignment promise that is made by the backend. The alignment itself is unchanged and is already incorrect on Sparc before my change. >> The issue is that Sparc backend doesn't correctly set STACK_BOUNDSARY and >> neither aligns the outgoing args. Run my test which proves alloca was >> broken before my patch. > > How could this have been broken for so long, realistically? The SPARC back- > end is parameterized according to the ABI and the documented interface > between > middle-end and back-end. It clearly gets the ABI wrong as it sets STACK_BOUNDARY and then doesn't keep the alignment promise it makes. Wilco