[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gcc optimisation breaks guile floating point
From: |
Han-Wen Nienhuys |
Subject: |
gcc optimisation breaks guile floating point |
Date: |
Wed, 28 Aug 2002 00:30:16 +0200 |
address@hidden writes:
>
> Apparently, "according to ANSI C" (no direct quotation available), the
> compiler can assume that *((unsigned long *) z) and *((double *) z)
> refer to different locations and reorder the statements!
>
> I don't know what would be needed to make Guile conform to such
> stringent interpretation of the standard, but I don't think it would
> be easy to determine that it was correct and that it would always stay
> that way. Perhaps we should just add the -fno-strict-aliasing option
> if the compiler supports it?
I think that these double (as in twice) initializations are weird, and
should go. Why not
scm_t_double bla;
bla.tag = scm_double_tag
bla.pad = 0x0
bla.double = z;
return scm_double_cell (
((scm_t_double_cell*) &bla) -> car,
((scm_t_double_cell*) &bla) -> cbr,
((scm_t_double_cell*) &bla) -> ccr,
((scm_t_double_cell*) &bla) -> cdr);
If we use -fno-strict-aliasing (a kludge, IMO), we should double check
that all inline functions are correct , for clients might not compile
with -fno-strict-aliasing.
Another option
*((unsigned long *) z) = 0;
scm_remember ((SCM) z);
*((double *) z) = x;
return z;
--
Han-Wen Nienhuys | address@hidden | http://www.cs.uu.nl/~hanwen