Re: gcc optimisation breaks guile floating point

[Gary Houston]

> From: address@hidden (Carl R. Witty)
> Date: 11 Sep 2002 18:46:47 -0700
> 
> Han-Wen Nienhuys <address@hidden> writes:
> 
> > address@hidden writes:
> > > 
> > > However scm_double_cell itself probably needs to be fixed, otherwise
> > > this problem will turn up again some day, or in user code (I'll look
> > > at it myself if it's still a problem in a couple of weeks.)
> > 
> > I think the proper solution is some kind of asm/gcc statement that
> > prevents the reordering. Any C gurus that know a portable way of
> > ensuring that?  A function call like scm_remember() from
> > scm_[double_]cell() defeats the purpose of inlining scm_[double_]cell. 
> 
> Under gcc, the following statement:
> 
>   asm volatile ("" : : : "memory");
> 
> is approximately what you want.  This specifies the empty string as
> inline assembly (so nothing is actually inserted into the assembly
> output), but tells gcc that the instruction may read and write memory
> in arbitrary ways.  Thus, gcc will not reorder memory reads or writes
> past this statement.

This is good, it's similar to a previous work-around in libguile/throw.c.

> Of course, this does have other undesirable effects on optimization --
> gcc cannot reorder other, unrelated memory reads or writes past this
> statement either, and it also cannot keep values from memory cached in
> registers across the statement.  It also only works with gcc.

Judging by the assembler output, it doesn't seem to do much damage.
For other compilers, calling scm_remember_upto_here_1 will avoid the
problem, with slightly greater overhead perhaps.

So I've moved the work-around into scm_double_cell itself.