Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • 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 4,838
    • Issues 4,838
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 452
    • Merge requests 452
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #18024

Closed
Open
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