Use of float type in unregistered build freezes program

[dterei]

If you compile a ghc HEAD version in unregistered mode there is a bug that causes any programs compiled by this ghc to freeze when they try to access a float.

build.mk

SRC_HC_OPTS     = -O -H64m
GhcStage1HcOpts = -O
GhcStage2HcOpts = -O2
GhcHcOpts       = -Rghc-timing
GhcLibHcOpts    = -O2 -XGenerics
GhcLibWays     += p
SplitObjs       = NO

HADDOCK_DOCS         = NO
BUILD_DOCBOOK_HTML   = NO
BUILD_DOCBOOK_PS     = NO
BUILD_DOCBOOK_PDF    = NO

GhcUnregisterised    = YES
GhcWithNativeCodeGen = NO

Program which produces bug:

main = do
    putStrLn "Print float test"
    putStrLn (show (1.2312341::Float))

Steps to reproduce

1. Compile latest version of ghc from darcs using the above build.mk configuration (other build.mk trigger the bug as well, must be unregistered though).
2. Compile the above haskell program with this ghc.
3. Run the program, it will freeze indefinitely
4. The test case arith006 also triggers the bug.

My machine

• x86, Ubuntu 9.04, 32 bit.
• uname -v

  Linux david-laptop 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux
  

  • gcc -v

    Using built-in specs.
    Target: i486-linux-gnu
    Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
    Thread model: posix
    gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
    

[simonmar]

Fascinating. I can reproduce on our unregisterised nightly build. I'll take a look.

[dterei]

Another test failing in unregistered mode is 1852. Given it deals with floats I assume its related to this bug. However unlike all the other tests which fail by freezing, this one fails quite spectacularly by printing out 4 huge numbers instead of the expected '[1,2,3,4]'. The output produces 11M of data.

[simonmar]

Fixed (nice bug!)

Mon Sep 28 05:44:55 PDT 2009  Simon Marlow <marlowsd@gmail.com>
  * emitRetUT: cope with arguments overlapping with results (#3546)
  
  In decodeFloat_Int# we have the C-- code:
  
      mp_tmp1  = Sp - WDS(1);
      mp_tmp_w = Sp - WDS(2);
      
      /* arguments: F1 = Float# */
      arg = F1;
      
      /* Perform the operation */
      foreign "C" __decodeFloat_Int(mp_tmp1 "ptr", mp_tmp_w "ptr", arg) [];
      
      /* returns: (Int# (mantissa), Int# (exponent)) */
      RET_NN(W_[mp_tmp1], W_[mp_tmp_w]);
  
  Which all looks quite reasonable.  The problem is that RET_NN() might
  assign the results to the stack (with an unregisterised back end), and
  in this case the arguments to RET_NN() refer to the same stack slots
  that will be assigned to.
  
  The code generator should do the right thing here, but it wasn't - it
  was assuming that it could assign the results sequentially.  A 1-line
  fix to use emitSimultaneously rather than emitStmts (plus comments).

[igloo]

Merged.