]> git.ipfire.org Git - thirdparty/gcc.git/commit
testsuite/gcc.dg/pr84877.c: Add machinery to stabilize stack aligmnent
authorHans-Peter Nilsson <hp@axis.com>
Thu, 5 Sep 2024 15:02:23 +0000 (17:02 +0200)
committerHans-Peter Nilsson <hp@bitrange.com>
Thu, 19 Sep 2024 02:22:58 +0000 (04:22 +0200)
commitb1ea710b1bcdda233f96538c5404228d2b244e01
tree46cde55fc4c93ed78870558f37d92cc8ba4e587d
parent57faabfbb3e58c66d924fced96c0fd2b5b3fc0c7
testsuite/gcc.dg/pr84877.c: Add machinery to stabilize stack aligmnent

This test awkwardly "blinks"; xfails and xpasses apparently
randomly for cris-elf using the "gdb simulator".  On
inspection, I see that the stack address depends on the
number of environment variables, deliberately passed to the
simulator, each adding the size of a pointer.

This test is IMHO important enough not to be just skipped
just because it blinks (fixing the actual problem is a
different task).

I guess a random non-16 stack-alignment could happen for
other targets as well, so let's try and add a generic
machinery to "stabilize" the test as failing, by allocating
a dynamic amount to make sure it's misaligned.  The most
target-dependent item here is an offset between the incoming
stack-pointer value (within main in the added framework) and
outgoing (within "xmain" as called from main when setting up
the p0 parameter).  I know there are other wonderful stack
shapes, but such targets would fall under the "complicated
situations"-label and are no worse off than before.

* gcc.dg/pr84877.c: Try to make the test result consistent by
misaligning the stack.
gcc/testsuite/gcc.dg/pr84877.c