- ghc-tickets - Haskell.org

Re: [GHC] #6135: Unboxed Booleans
by GHC 24 Jan '13

24 Jan '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: 605 | ---------------------------------+------------------------------------------ Changes (by dterei): * related: => 605 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #605: Optimisation: strict enumerations
by GHC 24 Jan '13

24 Jan '13

#605: Optimisation: strict enumerations --------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Difficult (2-5 days) Testcase: N/A | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by dterei): * cc: dterei (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/605#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 24 Jan '13

24 Jan '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by dterei): * cc: dterei (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:7> 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 24 Jan '13

24 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: Other Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------------+-------------------------------------- Changes (by Doaitse): * failure: None/Unknown => Other Comment: When checking I noticed that the ChristmasTree package had problems compiling with the newer versions of GHC. I updated the package by adding some type annotations, and upgrading the cabal file. The fact that we did not get complaints thus far probably indicates that the problem is not perceived as a severe one by most users. I have no idea how many actually rely on this package or this technology. It would be nice if hackage would inform maintains about packages becoming obsolete due to upgrades of GHC or of packages it depends on, but that is another issue. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1544#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

23 Jan '13

#1547: Arity can decrease with -prof ----------------------------------------+----------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Profiling | Version: 6.6.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: stm package/tests/conc052 | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: We know there are several problems with the current way that arity is calculated too early, and we plan to refactor things so that arity is calculated after CorePrep instead, which would fix this bug. Hence I don't think there's much to be gained by keeping the ticket open. It's unlikely we'll want to fix this bug in isolation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1547#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

23 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 simonmar): Still a bug. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1532#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics
by GHC 23 Jan '13

23 Jan '13

#1171: GHC doesn't respect the imprecise exceptions semantics -------------------------------+-------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: cg059 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by simonmar): Replying to [comment:16 morabbin]: > This reads like a misunderstanding of the semantics described in the paper; close as wontfix? There really is a mismatch between the semantics in the paper and what GHC implements, so I think it's good to keep the ticket open. Simon knows the full details, but as I understand it we think that the semantics should take into account the reordering that the strictness analyser does (ie. GHC is right, the semantics is wrong). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1171#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7049: LLVM backend miscompiles GHC stage2
by GHC 23 Jan '13

23 Jan '13

#7049: LLVM backend miscompiles GHC stage2 ---------------------------------+------------------------------------------ Reporter: kgardas | Owner: dterei Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler (LLVM) | Version: 7.5 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by dterei): * status: new => infoneeded Comment: kgardas are you able to confirm if this bug still occurs? I've fixed a fair few bugs lately and suspect I may have solved this issue.... -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7049#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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