[GHC] #12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info'

16 May 2016

      #12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info'
-------------------------------------+-------------------------------------
           Reporter:  ezyang         |             Owner:
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.0.1-rc2
  (CodeGen)                          |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 This is basically the same thing as #11155 but triggered differently.

 {{{
 -- M.hs
 {-# OPTIONS_GHC -O0 #-}
 module M(f) where

 import GHC.Exts

 {-# NOINLINE z #-}
 z = ()

 f :: () -> ()
 f _ = let x = lazy z
       in g x x

 {-# NOINLINE g #-}
 g :: () -> () -> ()
 g _ _ = ()

 -- MM.hs
 import M
 main = f `seq` return ()
 }}}

 On GHC 8.0, I get:

 {{{
 ezyang@sabre:~$ ghc-8.0 --make MM.hs -fforce-recomp
 [1 of 2] Compiling M                ( M.hs, M.o )
 [2 of 2] Compiling Main             ( MM.hs, MM.o )
 Linking MM ...
 ./M.o: In function `r2aD_info':
 (.text+0x4a): undefined reference to `stg_ap_0_upd_info'
 collect2: error: ld returned 1 exit status
 `gcc' failed in phase `Linker'. (Exit code: 1)
 }}}

 Error goes away when you turn on optimization. My understanding is that
 removing `lazy` in `CorePrep` is too late, because there's no pass
 afterwards that eliminates the trivial thunk assignment.

 This is blocking Phab:D2211, where the insertion of a `noinline` (which is
 optimized out similarly to `lazy`) triggers a stage 2 linker failure when
 you don't compile with optimization (unfortunately, this is NOT caught
 validate since we build GHC with optimization... but with this test it
 will be!)

 Perhaps there should be an ASSERT in the codegen so it doesn't create this
 symbol?

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12076
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler