GNOME Bugzilla – Bug 307947
The check for growing stack pointer in configure can fail
Last modified: 2013-11-25 01:06:39 UTC
Distribution/Version: 5.9 x86 During some bug-hunting I noticed that the definition of G_HAVE_GROWING_STACK in glibconfig.h changed depending on the switches to the compiler. Parhaps it is a good idea to turn off any user-supplied compiler-switches during this specific test. % cat foo.c volatile int *a = 0, *b = 0; void foo (void); int main () { volatile int y = 7; a = &y; foo (); return b > a; } void foo (void) { volatile int x = 5; b = &x; } % cc -O foo.c % ./a.out % echo $? 0 % cc -xO4 foo.c % ./a.out % echo $? 1 % cc -xO4 -xinline=no foo.c % ./a.out % echo $? 0 This was tested with Sun Studio 8, 9 and 10 on Solaris 9 x86. With the same compiler-versions on Solaris 9 sparc the problem do not occur.
(In reply to comment #0) > Distribution/Version: 5.9 x86 > > During some bug-hunting I noticed that the definition of G_HAVE_GROWING_STACK in > glibconfig.h changed depending on the switches to the compiler. > > Parhaps it is a good idea to turn off any user-supplied compiler-switches during > this specific test. > > % cat foo.c > volatile int *a = 0, *b = 0; > void foo (void); > int main () { volatile int y = 7; a = &y; foo (); return b > a; } > void foo (void) { volatile int x = 5; b = &x; } > % cc -O foo.c > % ./a.out > % echo $? > 0 > % cc -xO4 foo.c > % ./a.out > % echo $? > 1 > % cc -xO4 -xinline=no foo.c > % ./a.out > % echo $? > 0 > > This was tested with Sun Studio 8, 9 and 10 on Solaris 9 x86. > With the same compiler-versions on Solaris 9 sparc the problem do not occur. thanks you. this test is fairly important to get right (despite compiler flags even), can you please check whether the following fixes your test results? static int stack_grows = 0; volatile int* foo (int d) { volatile int *p, x = 5, *xaddr = &x; if (d--) { p = foo (d); if (!d) stack_grows = p > xaddr; } return xaddr; } int main () { foo (9999); return stack_grows; } this test should be impossible to inline ;)
another way to avoid the inlining may be to use a recursive function.
(In reply to comment #2) > another way to avoid the inlining may be to use a recursive function. huh? the function foo() from comment #1 _is_ recursive: > static int stack_grows = 0; > volatile int* foo (int d) function: foo > { > volatile int *p, x = 5, *xaddr = &x; > if (d--) { > p = foo (d); calls: foo > if (!d) > stack_grows = p > xaddr; > } > return xaddr; > }
Ah, right. I had a quick look at your function and thought you are using volatile to avoid inlining.
(In reply to comment #1) > (In reply to comment #0) [....] > thanks you. this test is fairly important to get right (despite compiler flags > even), can you please check whether the following fixes your test results? > > static int stack_grows = 0; > volatile int* foo (int d) > { > volatile int *p, x = 5, *xaddr = &x; > if (d--) { > p = foo (d); > if (!d) > stack_grows = p > xaddr; > } > return xaddr; > } > int main () { foo (9999); return stack_grows; } > > > this test should be impossible to inline ;) I tested this on my opensolaris box w/ Sun Studio 12 $ cc x.c $ ./a.out $ echo $? 0 $ cc -xO4 x.c $ ./a.out $ echo $? 1 $ uname -a SunOS opensolaris01 5.11 snv_130 i86pc i386 i86pc $
(In reply to comment #5) > (In reply to comment #1) > > (In reply to comment #0) > [....] > > thanks you. this test is fairly important to get right (despite compiler flags > > even), can you please check whether the following fixes your test results? > > > > static int stack_grows = 0; > > volatile int* foo (int d) > > { > > volatile int *p, x = 5, *xaddr = &x; > > if (d--) { > > p = foo (d); > > if (!d) > > stack_grows = p > xaddr; > > } > > return xaddr; > > } > > int main () { foo (9999); return stack_grows; } > > > > > > this test should be impossible to inline ;) > > I tested this on my opensolaris box w/ Sun Studio 12 > $ cc x.c > $ ./a.out > $ echo $? > 0 > $ cc -xO4 x.c > $ ./a.out > $ echo $? > 1 > $ uname -a > SunOS opensolaris01 5.11 snv_130 i86pc i386 i86pc > $ Thanks a lot for this, Bratsche could we get this in please?
Tim, isn't comment 5 suggesting that your proposed solution doesn't work? Confused.
(In reply to comment #7) > Tim, isn't comment 5 suggesting that your proposed solution doesn't work? > Confused. (Reread comments...) Sorry, thanks for the catch, i must have misinterpreted the result here. This makes me wonder about the inlining facilities with the Solaris compiler. Seems we need to come up with a more sophisticated check.
Someone should inspect the assembler code for that I guess. Another way around it would be to make that function an extern symbol and link to another file. But takes more configure magic.
I see the status has changed to RESOLVED FIXED What was the fix?