https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #7 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- The dumps show some differences I'd expect, but debugging libgomp testcases is awkward because they are so complicated. In the pre-patched era, Gcc's dynamic allocation on the stack was a bit too large most of the time (roughly by one allocated element, but not always). This served as some kind of "saftey" padding where programs with off-by-one bugs would write the "excess" data. In reduction-10.c there are just two dynamic allications (for a and b in foo) that seem to be good. However, there are more differences in the assembler dumps, probably generated by libgomp: --- reduction-10.s.242589 2016-11-22 15:20:27.421251695 +0100 +++ reduction-10.s.242590 2016-11-22 15:20:35.842210558 +0100 @@ -8,7 +8,7 @@ ld [%i0+16], %i2 add %i2, 1, %l5 sll %l5, 2, %g1 - add %g1, 10, %g1 + add %g1, 7, %g1 and %g1, -8, %g1 mov 0, %g2 sub %sp, %g1, %sp @@ -42,7 +42,7 @@ stb %g0, [%i2+%g1] add %i3, 1, %l6 sll %l6, 2, %g1 - add %g1, 10, %g1 + add %g1, 7, %g1 and %g1, -8, %g1 mov 0, %g2 sub %sp, %g1, %sp @@ -57,7 +57,6 @@ add %g1, 4, %g1 add %i4, 1, %l7 sll %l7, 3, %g1 - add %g1, 8, %g1 <--- somewhat suspicious mov 0, %g2 sub %sp, %g1, %sp add %sp, 96, %i3 @@ -70,7 +69,7 @@ add %g1, 8, %g1 add %i5, 1, %o5 sll %o5, 2, %g1 - add %g1, 10, %g1 + add %g1, 7, %g1 and %g1, -8, %g1 mov 0, %g2 sub %sp, %g1, %sp @@ -87,7 +86,7 @@ mov 0, %g1 add %l4, %l4, %g2 mov -6, %g4 - add %g2, 8, %g2 + add %g2, 7, %g2 and %g2, -8, %g2 sub %sp, %g2, %sp add %sp, 92, %i5 @@ -427,12 +426,11 @@ add %g4, 4, %o7 add %g4, %g4, %o4 sll %o7, 3, %o3 - add %o4, 8, %g1 - add %o3, 8, %g2 <--- somewhat suspicious + add %o4, 7, %g1 + sub %sp, %o3, %sp and %g1, -8, %g1 - sub %sp, %g2, %sp ... Note that some allocation sizes were reduces from x+10 or x+8 to x+7. This is what the patch is about. The two "add ... 8 ..." that have vanished may or may not have something to do with the problem. Possible causes of the symptom are: 1) The patch does not handle some corener case correctly. 2) There is an off-by-one bug in foo() that I've missed. 3) Off-by-one in libgomp. 4) 32 bit stack layout on SPARC is slightly broken. (32 bit AIX had such a problem caused by bad alignment of the dynamic stack variables.) To pin it down, it would help to have some simpler failing testcase than the ones from libgomp, and if possible reduced to the minimum. Is this limited to libgomp or are there other testcases that started failing? Also, access to such a SPARC system would help.