#7307: Share top-level code for strings -------------------------------------+------------------------------------ Reporter: simonpj | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Yeah, this code is buggy. Here are the problems I can find from a quick pass: * TOP_UNPACK is declared to have a thunk-representation. In that case, it needs to use a `StgThunkHeader`, so that the extra padding required to allow for lock-less thunk update in multithreaded code. * Similarly, it should be given the THU and SRT flags. Since these thunks are emitted into the data section (i.e. are static data), they also need the static flag (like THUNK_STATIC). So really TOP_UNPACK is a bad name. * I am not sure this is a good idea, but it seems like this mechanism could be generalized to variadic THUNK_STATICs, which are essentially THUNK_STATIC but have some payload attached to the end. You don't even have to hard-code the infotable anymore. * The GC code is wrong; TOP_UNPACK should be handled like a THUNK_STATIC. * I know for a fact you're missing this case from a number of other giant switch statements in the RTS. Do a grep. * The generated info table never pushes an update frame to adjust itself. So what happens when a reference to a TOP_UNPACK is inside generated code? I think you will end up repeatedly unpacking the string, though I am not 100% sure here. * As for whether or not your C-- is right, you should double-check it with the old C-- we were generating for handling unpacking per thunk. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7307#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler