trouble linking with -O and unboxed tuple

Bernard James POPE
Wed, 19 Mar 2003 15:49:10 +1100 (EST)

>    /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 

     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
              [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.


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