[cmucl-imp] Build failure on gcc-4.6 [resend with other user]
Hello all, If one uses gcc-4.6 to recompile cmucl then the test defined in: src/lisp/os-common.c: os_stack_grows_down always returns 0, even on x86/Linux where the correct answer is 1. I'm guessing that this is due to the added smarts in gcc-4.6. This causes the resulting lisp binary to segfault on startup, see Debian bug 483331. I 'fixed' this by making the function always return 1 as I'm only concerned about x86/Linux :). After this major hurdle expect 20c in Debian soonish... Best regards, Peter -- signature -at- pvaneynd.mailworks.org http://pvaneynd.dreamwidth.org/ God, root, what is difference?-Pitr|God is more forgiving.-Dave Aronson|
On Mon, Jan 16, 2012 at 11:25 PM, Peter Van Eynde <pvaneynd@mailworks.org>wrote:
Hello all,
If one uses gcc-4.6 to recompile cmucl then the test defined in:
src/lisp/os-common.c: os_stack_grows_down
always returns 0, even on x86/Linux where the correct answer is 1. I'm guessing that this is due to the added smarts in gcc-4.6.
This causes the resulting lisp binary to segfault on startup, see Debian bug 483331.
I 'fixed' this by making the function always return 1 as I'm only concerned about x86/Linux :).
Interesting. I wonder if os_stack_grows_down_1 were moved to another file would fix this. I'll also look around to see if I have gcc 4.6 somewhere on my machines Thanks for the tip,
After this major hurdle expect 20c in Debian soonish...
Fantastic! Thanks, Ray
On Tue, Jan 17, 2012 at 9:52 AM, Raymond Toy <toy.raymond@gmail.com> wrote:
Interesting. I wonder if os_stack_grows_down_1 were moved to another file would fix this.
If you think the call is being optimized away, you can try to add a "noinline" attribute to limit the optimization. Aside from the PA-RISC, don't all of the ports have a downward growing stack? Maybe it is time to make this a #define instead of using a clever runtime check.
On Tue, Jan 17, 2012 at 10:52 AM, Carl Shapiro <carl.shapiro@gmail.com>wrote:
On Tue, Jan 17, 2012 at 9:52 AM, Raymond Toy <toy.raymond@gmail.com>wrote:
Interesting. I wonder if os_stack_grows_down_1 were moved to another file would fix this.
If you think the call is being optimized away, you can try to add a "noinline" attribute to limit the optimization.
I don't have gcc 4.6 around anywhere so I can't test this.
Aside from the PA-RISC, don't all of the ports have a downward growing stack? Maybe it is time to make this a #define instead of using a clever runtime check.
A quick grep shows that this is only used for the stack guard zones, and those functions are called only on x86. For sparc, the C stack grows down, but the Lisp control stack grows up, so those routines aren't used. It looks like ppc never had the stack overflow support, and PA-RISC was pretty much dead before I even started using cmucl. So let's just get rid of them and fix up guard_zones to have a fixed assumption on the stack direction. Ray
participants (3)
-
Carl Shapiro -
Peter Van Eynde -
Raymond Toy