Opened 8 months ago

Closed 4 months ago

#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 8 months ago by ezyang

  • Description modified (diff)

comment:2 Changed 8 months ago by bgamari

  • Milestone set to 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 8 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 8 months ago by ezyang

  • Owner set to ezyang

comment:5 Changed 7 months ago by ezyang

  • Differential Rev(s) set to Phab:D2309
  • Status changed from new to patch

comment:6 Changed 7 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 7 months ago by ezyang

  • Status changed from patch to merge

comment:8 Changed 6 months ago by bgamari

  • Priority changed from normal to high

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

comment:9 Changed 5 months ago by bgamari

  • Resolution set to fixed
  • Status changed from merge to closed
Last edited 4 months ago by bgamari (previous) (diff)

comment:10 Changed 5 months ago by bgamari

  • Status changed from closed to merge

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 4 months ago by bgamari

  • Status changed from merge to closed

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.