Re: gcc optimisation breaks guile floating point

[cwitty@newtonlabs.com (Carl R. Witty)]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> ghouston@arglist.com 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.

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.

I'm unfamiliar with the exact definition of ANSI C, but I wonder if
something like this might be correct:

typedef union {
	long l;
	double d;
} long_or_double;

...
  *((long_or_double *)z).l = 0;
  *((long_or_double *)z).d = x;

Carl Witty


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel