Re: trouble linking with -O and unboxed tuple

18 Mar 2003

...
/home/bjpop/woo/lib/buddha-0.5/libbuddha_p.a(Partial.o): 
   In function `s1jZ_fast1':
   Partial.o(.text+0xa44): undefined reference to `GHCziPrim_zdwZ2H_entry'
1) libbuddha_p.a is a library built from a number of modules. Each of these
      modules is compiled with:
      -O -cpp -prof -fglasgow-exts -package lang -package-name buddha
2) The problem occurs when I try to use an unboxed tuple in one of the
      modules:
newtype Comp a = C (CompState -> (# a, CompState #))
If I remove the unboxing, the linking problem disappears
3) removing the -prof flag doesn't seem to fix anything
4) compiling without -O fixes the problem
And some more information about the problem:

     5) If I compile everything with -auto-all then the linking problem 
        disappears.

     6) If I swtich back from an unboxed tuple to a normal tuple and only
        recompile the module that contains that type (not every module
        in the program). Then I get this message:

        Compiling ParseLib_Buddha  ( ParseLib_Buddha.hs, ParseLib_Buddha.o )
        ghc-5.04.2: panic! (the `impossible' happened, GHC version 5.04.2):
           Missing alternative
           GHCziPrim.Z2H{-84-}
              (DataziTuple.Z2T{-74-},
              [result1{-r3Au-}, newState{-r3At-}],
              next{-r3Av-} result1{-r3Au-} newState{-r3At-})

     7) I only export the type Comp, not its constructor. 

There looks to be an interaction between profiling, optimisation and the 
unboxed tuple. The problem may very well be with me, but I'm not sure how to
find out.

You may wonder why I'm compiling things with -prof. This is for my declarative
debugger (buddha). I'm abusing the -prof option to get the string names of
constructors in the heap representation of values. I know it is a hack, but
for the moment it works well enough.

Cheers,
Bernie.

----- End of forwarded message from Bernard James POPE -----