#7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Keywords: | Os: MacOS X Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: 7590 | Blocking: 7588, 7589 Related: #7571, #7575 | ---------------------------------+------------------------------------------ Comment(by thoughtpolice): I'm a bit confused by your response. But it is my fault for not communicating better as I should have. For one, my OS X machine is running both 3.2 and 3.3svn, isolated. 3.2 is my primary installation. I mostly run both to narrow down bugs and out of curiosity, in this case it was identical output so there was otherwise no relevance. I should probably just not mentioned 3.3. I only have 3.3 for one personal thing I work on anyway. It's out of $PATH and out of mind. I just use 3.2 for everything else (including GHC.) Two, as for ARM, this ticket isn't about ARM? I imagine you meant #7575 where I do have a bug I found on ARM? And I'm not cross compiling in any of these tickets. I'm compiling on the ARM device itself with an existing 7.4.1 build provided by Ubuntu - so this would (I expect) work the same as any self-hosted 32bit build, modulo whatever ARM bugs I find. My ARM build of LLVM 3.3 is significantly older than what is in trunk now (because it takes a while to build,) and is much closer to the 3.2 branch. I can just put 3.2 on it anyway - I have a script to manually automate LLVM builds (and by default it just built trunk, not a released version. Likewise I am compiling here on OS X using LLVM 3.2. The host compiler is 64bit GHC 7.6.1. I am producing a 64bit compiler. The fix and patch for this issue were tested on that combo with that bootstrap compiler as well. For reference, here's the low down on my machines: Machine 1: 64-bit Quad core Mac OS X 10.8.2. ```xcodebuild -version``` reveals xcode version 4.5.2, build version 4G2008a. Host compiler is GHC 7.6.1, installed from a binary distribution. LLVM version is 3.2. This ticket is relevant to that. Machine 2: 32-bit Quad core ARM Linux. Ubuntu 12.10 derivative. GCC version is 4.6.3. LLVM version is 3.3svn as of about 3 weeks ago, but I'm going to replace that with 3.2 stable now. Bootstrap compiler is GHC 7.4.1 from Ubuntu repositories. Tickets #7571 and #7575 were filed against this machine. There is no cross compilation happening anywhere. All builds are standard with recent copies of HEAD. Karel Gardas has also reported success using my patch in #7571 for his ARM machine using LLVM 3.0, I believe. I reproduced #7571 with a hand-written Cmm file on OS X as well, which you [http://hackage.haskell.org/trac/ghc/attachment/ticket/7571/0001-Test-for- Trac-7571.patch can see in the ticket]. (Please try that test without this patch applied using the LLVM backend, and see if it fails.) I figured #7571 was probably due to the new code generator taking in a higher-level Cmm representation when parsing (because the bug came from the RTS, where a lot of Cmm was rewritten when the code generator went in.) I don't know what else to say - most of these are bugs long before the version of LLVM even matters as much. #7571 #7575 and this ticket are all outright compiler panics before code generation ever happen for me, so the actual version of LLVM doesn't seem as relevant. I unfortunately can't give you direct access to my machine OS X machine for various reasons. You are welcome to use my ARM machines if you'd like once I get them properly DMZ'd. Are there any other tests or examples you can think of? Could you try the testsuite test in #7571 with and without the patch? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7580#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler