diff options
author | Hans-Peter Nilsson <hp@axis.com> | 2024-09-05 17:02:23 +0200 |
---|---|---|
committer | Hans-Peter Nilsson <hp@bitrange.com> | 2024-09-19 04:22:58 +0200 |
commit | b1ea710b1bcdda233f96538c5404228d2b244e01 (patch) | |
tree | 46cde55fc4c93ed78870558f37d92cc8ba4e587d /gcc/tree-vectorizer.h | |
parent | 57faabfbb3e58c66d924fced96c0fd2b5b3fc0c7 (diff) | |
download | gcc-b1ea710b1bcdda233f96538c5404228d2b244e01.zip gcc-b1ea710b1bcdda233f96538c5404228d2b244e01.tar.gz gcc-b1ea710b1bcdda233f96538c5404228d2b244e01.tar.bz2 |
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.
Diffstat (limited to 'gcc/tree-vectorizer.h')
0 files changed, 0 insertions, 0 deletions