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,247
    • Issues 5,247
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 577
    • Merge requests 577
  • 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
  • #17151
Closed
Open
Issue created Sep 04, 2019 by Alexey Kuleshevich@lehinsReporter

Optimizer produces Core with an infinite <<loop>> v2

Summary

I am not quite sure what it is? Is it coincidence, my coding style or just luck. Two years later after I reported a bug #13429 (closed) about optimizer generating an infinite loop, I stumble upon exactly the same bug, while implementing the same algorithm (convolution), but in a completely different library and using a totally different approach. There are some similarities in types, but I can't draw a concrete comparison.

Unlike previous bug #13429 (closed), which was applicable to ghc-8.0 and was supposably fixed in ghc-8.2, this one is triggered in ghc-8.2 and up, but not for the prior version.

It is way too easy not not trigger the bug, in fact I initially noticed my tests failing for ghc-8.4.4 only, but once I reduced it to a smaller example, my tests started failing for ghc-8.6.5 as well as ghc-8.8.1

I apologize for the size of the uploaded module, but it took me a while to reduce it even to that level.

Steps to reproduce

Uploaded are the two files needed to reproduce the bug:

  • Main.hs
  • Array.hs

Those modules only depend on primitive package, but this is only for convenience, since this bug could equally well be reproduced using either ForeignPtr or by dropping down to ByteArray# or MutableByteArray# prims.

Compiling with optimizations is necessary to trigger the bug:

$ ghc Main.hs Array.hs -O1 -fforce-recomp && ./Main 
[1 of 2] Compiling Array            ( Array.hs, Array.o )
[2 of 2] Compiling Main             ( Main.hs, Main.o )
Linking Main ...
Main: <<loop>>

When inspecting Core we can see where the loop occurs right away:

Rec {
-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}
$s$fConstructPixe1 :: Index Int
$s$fConstructPixe1 = $s$fConstructPixe1
end Rec }

I found something peculiar, which could be useful for debugging this issue, is that the Construct instance for P representation is not used anywhere directly in the source code.

Expected behavior

No infinite loop in the produced binary.

Environment

  • GHC version used: 8.2.2 - 8.8.1

Optional:

  • Operating System: Ubuntu 18.04 LTS
  • System Architecture: x86_64
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking