January 2013 - ghc-tickets

[GHC] #7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails
by GHC 23 Jan '13

23 Jan '13

#7580: Building PrimOps.cmm on OS X with LLVM 3.2 fails --------------------------------+------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: #7571, #7575 --------------------------------+------------------------------------------- Using LLVM 3.2 (release,) or LLVM 3.3svn, on my Mac OS X 10.8 machine, the stage1 compiler fails to compile ```PrimOps.cmm``` with this error: {{{ $ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -static -optc-DDEBUG -H64m -O0 -fllvm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O0 -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.debug_o /usr/local/bin/opt: /var/folders/f6/rjtvxfp92j3ffvm3zs7hv7vh0000gn/T/ghc99887_0/ghc99887_0.ll:6800:17: error: invalid cast opcode for cast from 'i64' to 'i64' %ln1N5 = zext i64 1 to i64 }}} This seems to occur inside ```stg_retryzh```, which looks like: {{{ ==================== LLVM Code ==================== define cc 10 void @stg_retryzh(i64* noalias nocapture %Base_Arg, i64* noalias nocapture %Sp_Arg, i64* noalias nocapture %Hp_Arg, i64 %R1_Arg, i64 %R2_Arg, i64 %R3_Arg, i64 %R4_Arg, i64 %R5_Arg, i64 %R6_Arg, i64 %SpLim_Arg) align 8 nounwind { { ... ... ccD: ... %ln1MS = call ccc i8* (i8*,i8*)* @stmStartTransaction( i8* %ln1MP, i8* %ln1MR ) nounwind %ln1MT = ptrtoint i8* %ln1MS to i64 store i64 %ln1MT, i64* %lccV %ln1MU = load i64** %Base_Var %ln1MV = getelementptr inbounds i64* %ln1MU, i32 25 %ln1MW = bitcast i64* %ln1MV to i64* %ln1MX = load i64* %ln1MW, !tbaa !4 %ln1MY = add i64 %ln1MX, 8 %ln1MZ = add i64 %ln1MY, 72 %ln1N0 = load i64* %lccV %ln1N1 = inttoptr i64 %ln1MZ to i64* store i64 %ln1N0, i64* %ln1N1, !tbaa !5 %ln1N2 = load i64* %lccU %ln1N3 = add i64 %ln1N2, 8 %ln1N4 = add i64 %ln1N3, 0 %ln1N5 = zext i64 1 to i64 <------ Invalid %ln1N6 = inttoptr i64 %ln1N4 to i64* store i64 %ln1N5, i64* %ln1N6, !tbaa !5 %ln1N7 = load i64* %lccU %ln1N8 = add i64 %ln1N7, 8 %ln1N9 = add i64 %ln1N8, 16 %ln1Na = inttoptr i64 %ln1N9 to i64* %ln1Nb = load i64* %ln1Na, !tbaa !5 store i64 %ln1Nb, i64* %R1_Var %ln1Nc = load i64** %Base_Var %ln1Nd = load i64** %Sp_Var %ln1Ne = load i64** %Hp_Var %ln1Nf = load i64* %R1_Var %ln1Ng = load i64* %SpLim_Var tail call cc 10 void (i64*,i64*,i64*,i64,i64,i64,i64,i64,i64,i64)* @stg_ap_v_fast( i64* %ln1Nc, i64* %ln1Nd, i64* %ln1Ne, i64 %ln1Nf, i64 undef, i ret void ... ... }}} Which would seem to correspond to this in ```PrimOps.cmm```: {{{ stg_retryzh /* no arg list: explicit stack layout */ { W_ frame_type; W_ frame; W_ trec; W_ outer; W_ r; ... ... (r) = ccall stmWait(MyCapability() "ptr", CurrentTSO "ptr", trec "ptr"); if (r != 0) { ... ... } else { // Transaction was not valid: retry immediately ("ptr" trec) = ccall stmStartTransaction(MyCapability() "ptr", outer "ptr"); StgTSO_trec(CurrentTSO) = trec; Sp = frame; R1 = StgAtomicallyFrame_code(frame); jump stg_ap_v_fast [R1]; } } }}} I'm still investigating. I think this is related to #7571 and #7575. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #7575: LLVM backend does not properly widen certain literal types in call expressions
by GHC 23 Jan '13

23 Jan '13

#7575: LLVM backend does not properly widen certain literal types in call expressions -----------------------------+---------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #7571, #7574 -----------------------------+---------------------------------------------- Related to #7571 and #7574, while compiling stage2 with stage1 GHC HEAD on my ODROID, my build fails in ```libraries/base/GHC/Word.hs``` with: {{{ linaro@linaro-ubuntu-desktop ~/code/ghc % "inplace/bin/ghc-stage1" -static -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibrarie- Ilibraries/base/dist-install/build -Ilibraries/base/dist- install/build/autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCDl_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm -no -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/./files -tmpdir tmpdir when making flags consistent: Warning: No native code generator, so using LLVM You are using a new version of LLVM that hasn't been tested yet! We will try though... /home/linaro/bin/opt: tmpdir/ghc12774_0/ghc12774_0.ll:26765:62: error: argument is not of expected type 'i64' %lnhvj = call ccc i32 (i64,i64)* @hs_eqWord64( i64 %lnhvi, i32 0 ) nounwind }}} The declaration of ```hs_eqWord64` is: {{{ declare ccc i32 @hs_eqWord64(i64, i64) align 4 }}} And we get: {{{ %lnhvj = call ccc i32 (i64,i64)* @hs_eqWord64( i64 %lnhvi, i32 0 ) nounwind }}} inside of ```c8Aq_info```, which has a tail call from the symbol ```base_GHCziWord_zdfNumWord64zuzdcsignum_info``` or ```base_GHC.Word_$fNumWord64_$csignum_info``` - this would seem to be some specialized instance of the case: {{{ instance Num Word64 where ... signum 0 = 0 signum _ = 1 }}} ... I think. This seems like a fairly simple fix similar to the others, but I'm filing it for now. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7575> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7617: LLVM backend broken on 32bit OS X (when 64bit host)
by GHC 23 Jan '13

23 Jan '13

#7617: LLVM backend broken on 32bit OS X (when 64bit host) -------------------------------+-------------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- OSX 32bit GHC is broken when running on a 64bit host. This is as we aren't passing the correct flags through to clang (the assembler used) to indicate it should compile as 32bit instead of 64bit... -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7617> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7571: LLVM codegen does not handle integer literals in branch conditionals.
by GHC 23 Jan '13

23 Jan '13

#7571: LLVM codegen does not handle integer literals in branch conditionals. --------------------------------+------------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.6.1 | Keywords: llvm, codegen Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- When compiling GHC HEAD on my ODROID-U2 ARM machine, running Ubuntu 12.10, with LLVM 3.3svn, I get this error while building part of the RTS: {{{ linaro@linaro-ubuntu-desktop ~/code/ghc % "inplace/bin/ghc-stage1" -static -prof -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -optc-O2 -O2 -c rts/StgStdThunks.cmm -o rts/dist/build/StgStdThunks.p_o You are using a new version of LLVM that hasn't been tested yet! We will try though... ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20130111 for arm-unknown-linux): LlvmCodeGen.CodeGen.genCondBranch: Cond expr not bool! (i32 1) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug linaro@linaro-ubuntu-desktop ~/code/ghc % }}} The reason is that StgStdThunks.cmm does something like: {{{ #ifdef FOO #define THING(x) 1 #else #define THING(x) do_something((x)) #endif ... if (THING(x)) { ... } }}} Depending on if FOO is defined, the conditional could have an expression or a literal in the branch head. This is directly fed into the backend from the compiler. LlvmCodeGen.CodeGen.genLit does not properly narrow the type of the literal from i32 to i1 when generating the code, causing a compiler panic. We would have likely never seen this outside hand-written Cmm, since the code generator would otherwise trivially eliminate such branches in the optimizers. Coincidentally, I would imagine this failure would mean that the compiler has not been able to bootstrap with LLVM for quite some time. I haven't bisected this, but I'd speculate it was some time around the switch to the NCG. I believe I have a fix for this that I am testing on my machine. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

Re: [GHC] #1509: Make unboxed tuples more supported
by GHC 23 Jan '13

23 Jan '13

#1509: Make unboxed tuples more supported -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Let's call it fixed. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1509#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 23 Jan '13

23 Jan '13

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+-------------------------------------------- Reporter: cetinsert | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Keywords: R_X86_64_PC32 | Os: Windows Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by simonmar): #7357 is already closed as a dup of this one. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7134#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient
by GHC 22 Jan '13

22 Jan '13

#1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient -------------------------------------+-------------------------------------- Reporter: jcpetruzza@… | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------------+-------------------------------------- Comment(by morabbin): Any progress on adapting Doaitse's work for inclusion? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1544#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1532: Implicit parameters are not available in breakpoints
by GHC 22 Jan '13

22 Jan '13

#1532: Implicit parameters are not available in breakpoints ---------------------------------+------------------------------------------ Reporter: mnislaih | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: break015 Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by morabbin): Bump; still of interest? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1532#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1547: Arity can decrease with -prof
by GHC 22 Jan '13

22 Jan '13

#1547: Arity can decrease with -prof ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Profiling | Version: 6.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: stm package/tests/conc052 Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by morabbin): * failure: => None/Unknown Comment: Bump; close as fixed? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1547#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1530: debugging :steps inside TH spliced code need to be bypassed
by GHC 22 Jan '13

22 Jan '13

#1530: debugging :steps inside TH spliced code need to be bypassed ---------------------------------+------------------------------------------ Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: dynbrk005 Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by morabbin): * failure: => None/Unknown Comment: Seems like this is still happening (for dynbrk005 anyway) in 7.6.1. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1530#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0