Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,411
    • Issues 5,411
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 606
    • Merge requests 606
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #18024
Closed
Open
Issue created Apr 07, 2020 by Travis Whitaker@tmobileReporter

uniqFromMask Returns Duplicate Uniques with -jN, N > 1

uniqFromMask can return duplicate uniques when running stage 1 GHC with more than one thread. There is a primitive test here to verify this: tmobile/ghc@fb6c708f. This seems to have nothing to do with cross-compilation as originally suspected; cross compilers are always stage 1 compilers, cross-compilation targeting aarch64 uses LLVM, and opt simply complains in a way that reveals the issue.

Original description:

When cross-compiling packages (from x86_64 to aarch64, with GHC 8.8.x) I sometimes see errors of the form:

opt: /build/ghc119_0/ghc_103.ll:997:3: error: multiple definition of local value named 'ln5hca'
  %ln5hca = inttoptr i64 %ln5hca to i64*
  ^

<no location info>: error:
    `opt' failed in phase `LLVM Optimiser'. (Exit code: 1)

It seems that GHC sometimes uses stale names when generating IR, but I have no idea what this might have to do with cross-compilation. I have never seen this with a native build on Intel or aarch64. Since names are generated randomly (as far as I remember), the error may often be bypassed by simply trying again. Naturally, packages with large modules are more likely to encounter this issue.

Previously, it would've been a pain to setup a cross compiler to reproduce this, but thanks to IOHK's excellent work at https://github.com/input-output-hk/haskell.nix , this is now quite easy.

Edited May 05, 2020 by Travis Whitaker
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking