#12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundominguez Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mboes: @@ -2,2 +2,2 @@ - FloatOut based static pointers support. See github.com/mboes/bug-ptr-not- - in-spt for a fully developed minimal example. + FloatOut based static pointers support. See https://github.com/mboes/bug- + ptr-not-in-spt for a fully developed minimal example. New description: I found what appears to be a regression following the merge of the new FloatOut based static pointers support. See https://github.com/mboes/bug- ptr-not-in-spt for a fully developed minimal example. It seems to be quite hard to trigger this bug: * I need to be using distributed-closure (not bare `StaticPtr`). * The static pointer needs to be defined in a separate module. * The static pointer must refer to a value with at least one polymorphic argument. * Compiler optimization level 1 needs to be turned on. At any rate, I wasn't able to trigger it without all conditions above being true. Initial investigations by facundominguez point to static pointer unpacking in distributed-closure as the culprit. Likely unpacked static pointers are no longer recognized as such by the FloatOut pass and therefore never floated to top-level, hence breaking a fundamental invariant about static pointers. This might explain why sometimes static pointers don't get added to the static pointer table (SPT), as in the above minimal example. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12622#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler