After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 307947 - The check for growing stack pointer in configure can fail
The check for growing stack pointer in configure can fail
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
2.6.x
Other opensolaris
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2005-06-16 17:11 UTC by Joel Fredrikson
Modified: 2013-11-25 01:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Joel Fredrikson 2005-06-16 17:11:24 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.
Comment 1 Tim Janik 2006-09-14 14:42:03 UTC
(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 ;)
Comment 2 Behdad Esfahbod 2006-12-18 03:07:21 UTC
another way to avoid the inlining may be to use a recursive function.
Comment 3 Tim Janik 2006-12-18 09:26:03 UTC
(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;
> }
Comment 4 Behdad Esfahbod 2006-12-18 16:16:01 UTC
Ah, right.  I had a quick look at your function and thought you are using volatile to avoid inlining.
Comment 5 Tim Rice 2010-03-11 18:00:48 UTC
(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
$
Comment 6 Tim Janik 2010-04-06 09:32:14 UTC
(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?
Comment 7 Behdad Esfahbod 2010-04-06 15:33:10 UTC
Tim, isn't comment 5 suggesting that your proposed solution doesn't work?  Confused.
Comment 8 Tim Janik 2010-04-07 08:27:02 UTC
(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.
Comment 9 Behdad Esfahbod 2010-04-07 16:14:11 UTC
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.
Comment 10 Tim Rice 2013-11-25 01:06:39 UTC
I see the status has changed to RESOLVED FIXED
What was the fix?