#12076 closed bug (fixed)

"lazy" leads to undefined reference to `stg_ap_0_upd_info'

Reported by: ezyang Owned by: ezyang
Priority: high Milestone: 8.0.2
Component: Compiler (CodeGen) Version: 8.0.1-rc2
Keywords: Cc: simonpj
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D2309
Wiki Page:

Description (last modified by ezyang)

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. Here's the STG:

z_r2aC :: ()
[GblId, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] =
    NO_CCS ()! [];

g_r2aD :: () -> () -> ()
[GblId, Arity=2, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] =
    sat-only \r srt:SRT:[] [ds_s2rW ds1_s2rX] () [];

M.f :: () -> ()
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] =
    \r srt:SRT:[] [ds_s2rY]
        let {
          x_s2rZ :: ()
          [LclId, Str=DmdType, Unf=OtherCon []] =
              \u srt:SRT:[] [] z_r2aC;
        } in  g_r2aD x_s2rZ x_s2rZ;

so we need, instead, something like x_s2rZ = z_r2aC.

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?

Change History (11)

comment:1 Changed 18 months ago by ezyang

Description: modified (diff)

comment:2 Changed 18 months ago by bgamari

Milestone: 8.0.2

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

+1. It's silly that we get all the way to linking with this code.

comment:3 Changed 18 months ago by Ben Gamari <ben@…>

In 5f1557ee/ghc:

Failing test case for #12076.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2229

GHC Trac Issues: #12076

comment:4 Changed 18 months ago by ezyang

Owner: set to ezyang

comment:5 Changed 18 months ago by ezyang

Differential Rev(s): Phab:D2309
Status: newpatch

comment:6 Changed 18 months ago by Edward Z. Yang <ezyang@…>

In 11ff1df8/ghc:

Fix #12076 by inlining trivial expressions in CorePrep.

Summary:
This mostly follows the plan detailed by the discussion
Simon and I had, with one difference: instead of grabbing
the free variables of the trivial expressions to get the
embedded Ids, we just use getIdFromTrivialExpr_maybe to extract
out the Id.  If there is no Id, the expression cannot
refer to a function (as there are no literal functions)
and thus we do not need to saturate.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2309

GHC Trac Issues: #12076

comment:7 Changed 18 months ago by ezyang

Status: patchmerge

comment:8 Changed 17 months ago by bgamari

Priority: normalhigh

This actually seems to affect a number of packages (e.g. servant-server), especially when built with -O0.

comment:9 Changed 16 months ago by bgamari

Resolution: fixed
Status: mergeclosed
Last edited 15 months ago by bgamari (previous) (diff)

comment:10 Changed 15 months ago by bgamari

Status: closedmerge

Phab:D2471 fixes a performance regression in the binary-tree nofib test introduced by comment:6. It was merged to master as 83b326cda759cfd4c538595cf38ee23eb81a4c76.

It should likely be merged to ghc-8.0.

comment:11 Changed 15 months ago by bgamari

Status: mergeclosed

comment:6 was merged to ghc-8.0 as 2a9767ed596679ddf21b7edfa9fc6410443c2a01. The binary-trees regression fix was merged as 47d589ef52ded1ab3f81994f6567dac666e08587.

Note: See TracTickets for help on using tickets.