headers
Peter Van Eynde | 17 Jan 2012 08:25

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|
_______________________________________________
cmucl-imp mailing list
cmucl-imp <at> cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp
Permalink | Reply |
headers
Raymond Toy | 17 Jan 2012 18:52
Picon

Re: Build failure on gcc-4.6 [resend with other user]

On Mon, Jan 16, 2012 at 11:25 PM, Peter Van Eynde <pvaneynd <at> 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!
(Continue reading)

Permalink | Reply |
headers
Carl Shapiro | 17 Jan 2012 19:52
Picon

Re: Build failure on gcc-4.6 [resend with other user]

On Tue, Jan 17, 2012 at 9:52 AM, Raymond Toy <toy.raymond <at> 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.
_______________________________________________
cmucl-imp mailing list
cmucl-imp <at> cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-imp
Permalink | Reply |
headers
Raymond Toy | 17 Jan 2012 20:29
Picon

Re: Build failure on gcc-4.6 [resend with other user]

On Tue, Jan 17, 2012 at 10:52 AM, Carl Shapiro <carl.shapiro <at> gmail.com>wrote:

> On Tue, Jan 17, 2012 at 9:52 AM, Raymond Toy <toy.raymond <at> 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.
(Continue reading)

Permalink | Reply |

Gmane