#9142: LLVM HEAD rejects aliases used by LLVM codegen -------------------------------------+------------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.2 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 bgamari): Replying to [comment:4 scpmw]:
Not quite sure I understand how your patch works - isn't this basically allocating a bunch of static null-initialized `i8` fields to point to? That's hardly what we want, even if it compiles.
It would be really interesting to get a statement from LLVM people on
Frankly I'm not too clear on this either. I modelled the change after similar [https://github.com/llvm- mirror/llvm/commit/38048cdb1c016e1429004ddf4adfa40a8d853cbf#diff- 6888511bd2c39203c5f7a7e314bdd2ebL40 changes] made in the commit in question to testcases. However, you are right, it would appear that the local definitions will be used in lieu of the external symbols the references are supposed to use. All I know at the moment is that the code compiles. It likely does the wrong thing. this.
If they think that we are mis-using aliases, that's reason enough to do something else. One possible solution could again be type aliases - but instead of writing the definitions at the end of the session we'd close
Indeed it would. At this point my next goal is to chase down the relevant LLVM people. the file and /prepend/ them. That could be a cheap and easy way to get the LLVM parser to like us again. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9142#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler