CLISP - an ANSI Common Lisp

> * Bruno Haible <oehab@...> [2004-01-12 20:21:29 +0100]:
>>
>>  - why did you restore the -fomit-frame-pointer trick?
>>    we discussed that and you approved removing this option.
>
> I did not restore -fomit-frame-pointer. You eliminated
> -fomit-frame-pointer from makemake.in, but a user who thinks he's
> clever might add it to the CFLAGS nevertheless. I restored the
> _protection_ against -fomit-frame-pointer generating buggy code for
> interpret_bytecode_, after I verified that even with the newest GCCs,
> it has the desired effect.

Is it really worth it?
You are making life easier for a "clever user" at the expense of making
an additional system call for everyone else!

Moreover, __EVEN WITH__ this alloca() trick, clisp segfaults on the
first GC on mingw, i.e., this "clever user" might win today on _some_
platforms, but might lose on the same platform tomorrow!

how is this better than just removing the alloca() trick and putting a
note in INSTALL that -fomit-frame-pointer is not supported?

Let us be consistent: if we want -fomit-frame-pointer to work - at
least sometimes - keep the trick and add -fomit-frame-pointer in
makemake.in (conditional on mingw where it does not work now).
if we do not want it - remove all vestiges of it.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Illiterate?  Write today, for free help!

Sam wrote:
> Is it really worth it?
> You are making life easier for a "clever user" ...

I am eliminating a possible cause of "handler_fault...". The cost is 5 lines
of code.

> at the expense of making an additional system call for everyone else!

alloca(1) is a single machine instruction, not a system call. And it occurs
in an "if (never_never)" branch of code.

> Moreover, __EVEN WITH__ this alloca() trick, clisp segfaults on the
> first GC on mingw

Is is related?

> how is this better than just removing the alloca() trick and putting a
> note in INSTALL that -fomit-frame-pointer is not supported?

It reduces the number of things that an installer must be aware of, by 1.

> Let us be consistent: if we want -fomit-frame-pointer to work - at
> least sometimes - keep the trick and add -fomit-frame-pointer in
> makemake.in (conditional on mingw where it does not work now).

This is not about being consistent. It's about safety and speed.
Since our measurements indicate the -fomit-frame-pointer brings
absolutely no speed advantage, why should I add it back to makemake.in?

> if we do not want it - remove all vestiges of it.

No. We don't recommend -fomit-frame-pointer but we don't forbid it either.
Similarly, we don't recommend gcc-2.7.2, but we don't forbid it either.

Bruno

> * Bruno Haible <oehab@...> [2004-01-12 22:44:19 +0100]:
> Sam wrote:
>> Is it really worth it?
>> You are making life easier for a "clever user" ...
>
> I am eliminating a possible cause of "handler_fault...".
on some platforms only.

> The cost is 5 lines of code.
which add to be maintainer overhead.

>> at the expense of making an additional system call for everyone else!
>
> alloca(1) is a single machine instruction, not a system call.

didn't know that.
actually, I don't see why it is not converted to a
          char foo;
and then eliminated as an unused variable.

> And it occurs in an "if (never_never)" branch of code.

indeed - sorry, missed that.

>> Moreover, __EVEN WITH__ this alloca() trick, clisp segfaults on the
>> first GC on mingw
>
> Is is related?

<http://article.gmane.org/gmane.lisp.clisp.devel/10726/match=fomit>
<http://article.gmane.org/gmane.lisp.clisp.devel/10727/match=fomit>

>> how is this better than just removing the alloca() trick and putting a
>> note in INSTALL that -fomit-frame-pointer is not supported?
>
> It reduces the number of things that an installer must be aware of, by 1.

People who pass arguments to configure or make which are not mentioned
in the configure help output are on their own anyway.

How would you like to answer this question:

"Is it okay for a user to do
    $ CFLAGS=-fomit-frame-pointer ./configure
?"

the choice is :

  1. yes, on some platforms.  it does not work on gcc 3.3 mingw.
     [it might not work on gcc 3.4 solaris or gcc 3.2 hp/ux.
      it did work with gcc 3.2 on mingw though :-]
     you are on your own on your platform.
     there is no advantage in this option anyway.

  2. no on any platforms - there is no advantage in this option anyway.

which answer is more clear?

>> if we do not want it - remove all vestiges of it.
>
> No. We don't recommend -fomit-frame-pointer but we don't forbid it either.
> Similarly, we don't recommend gcc-2.7.2, but we don't forbid it either.

I bet 2.7.2 cannot compile CLISP anyway, so, effectively, it is forbidden.

anyway this issue is not worth arguing.
if you want to keep the trick - keep it.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Programming is like sex: one mistake and you have to support it for a lifetime.

>>>>> "Bruno" == Bruno Haible <bruno@...> writes:

    Bruno> Sam wrote:
    >> Is it really worth it?
    >> You are making life easier for a "clever user" ...

    Bruno> I am eliminating a possible cause of "handler_fault...". The cost is 5 lines
    Bruno> of code.

    >> at the expense of making an additional system call for everyone else!

    Bruno> alloca(1) is a single machine instruction, not a system call. And it occurs

Maybe a single instruction on x86, but on Solaris/sparc it's a
half-dozen or so.  But still, it's not a system call.

Ray

Sam wrote:
> >> Moreover, __EVEN WITH__ this alloca() trick, clisp segfaults on the
> >> first GC on mingw
> >
> > Is is related?
>
> <http://article.gmane.org/gmane.lisp.clisp.devel/10726/match=fomit>
> <http://article.gmane.org/gmane.lisp.clisp.devel/10727/match=fomit>

So it is not related. Since we have FAST_SP turned off for gcc >= 3.1
since 2002-05-28, it must be a bug introduced by "-O2 -fomit-frame-pointer"
in other places than this one.

> People who pass arguments to configure or make which are not mentioned
> in the configure help output are on their own anyway.
>
> How would you like to answer this question:
>
> "Is it okay for a user to do
>     $ CFLAGS=-fomit-frame-pointer ./configure
> ?"
>
> the choice is :
>
>   1. yes, on some platforms.  it does not work on gcc 3.3 mingw.
>      [it might not work on gcc 3.4 solaris or gcc 3.2 hp/ux.
>       it did work with gcc 3.2 on mingw though :-]
>      you are on your own on your platform.
>      there is no advantage in this option anyway.
>
>   2. no on any platforms - there is no advantage in this option anyway.
>
> which answer is more clear?

3. it is okay on all platforms, modulo gcc bugs (e.g. don't use gcc-2.96),
   but there is no advantage in this option.

Bruno

> * Bruno Haible <oehab@...> [2004-01-13 19:21:25 +0100]:
>
> Sam wrote:
>> >> Moreover, __EVEN WITH__ this alloca() trick, clisp segfaults on the
>> >> first GC on mingw
>> >
>> > Is is related?
>>
>> <http://article.gmane.org/gmane.lisp.clisp.devel/10726/match=fomit>
>> <http://article.gmane.org/gmane.lisp.clisp.devel/10727/match=fomit>
>
> So it is not related. Since we have FAST_SP turned off for gcc >= 3.1
> since 2002-05-28, it must be a bug introduced by "-O2
> -fomit-frame-pointer" in other places than this one.

in that case, how do we know that -fomit-frame-pointer does not give us
any benefit?
maybe if FAST_SP were enabled, -fomit-frame-pointer would have made a
difference?


>> People who pass arguments to configure or make which are not mentioned
>> in the configure help output are on their own anyway.
>>
>> How would you like to answer this question:
>>
>> "Is it okay for a user to do
>>     $ CFLAGS=-fomit-frame-pointer ./configure
>> ?"
>>
>> the choice is :
>>
>>   1. yes, on some platforms.  it does not work on gcc 3.3 mingw.
>>      [it might not work on gcc 3.4 solaris or gcc 3.2 hp/ux.
>>       it did work with gcc 3.2 on mingw though :-]
>>      you are on your own on your platform.
>>      there is no advantage in this option anyway.
>>
>>   2. no on any platforms - there is no advantage in this option anyway.
>>
>> which answer is more clear?
>
> 3. it is okay on all platforms, modulo gcc bugs (e.g. don't use gcc-2.96),
>    but there is no advantage in this option.

all software has bugs, GCC included.
clisp stresses the CC like no other program.
saying the "the works in clisp modulo cc bugs" does not convey any
useful information, it's just a truism.
saying that "this works on such and such platforms" or
"this is not expected to work, ever" does.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Type louder, please.

Sam wrote:
> > So it is not related. Since we have FAST_SP turned off for gcc >= 3.1
> > since 2002-05-28, it must be a bug introduced by "-O2
> > -fomit-frame-pointer" in other places than this one.
>
> in that case, how do we know that -fomit-frame-pointer does not give us
> any benefit?

Good point. We should have measured with gcc-2.95.3, not gcc-3.2 or gcc-3.3.
But anyway, the rest of clisp also constributes to the timings. And it didn't
make any difference.

> maybe if FAST_SP were enabled, -fomit-frame-pointer would have made a
> difference?

That's hypothetic. With today's GCC, FAST_SP and -fomit-frame-pointer are
incompatible.

Bruno