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.
