guile-devel
[Top][All Lists]
Advanced

[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 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]