On 9/5/24 9:44 AM, Hans-Peter Nilsson wrote:
Tested adding 0..more-than-four environment variables,
running cris-sim+cris-elf. I also checked that foo stays
the same generated code regardless of the new code: this is
not obviously true as foo is "just" noinline, not __noipa__.
Ok to commit?
-- >8 --
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.
So I've got this test marked as flakey and thus it's currently being
skipped everywhere.
If one was to look at the changes it's pretty clear that it only affects
cris right now. I wouldn't be surprised if other targets need similar
handling.
Ok for the trunk. I'll remove it from my list of flakey tests after you
push this to the trunk. Hopefully we'll see any flip-flops in behavior
on other targets over time and we can fix them.
jeff
