- ghc-tickets - Haskell.org

Re: [GHC] #6135: Unboxed Booleans
by GHC 11 Apr '13

11 Apr '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch 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 | ---------------------------------+------------------------------------------ Comment(by simonpj): If we are going to change primpops, perhaps we should change `dataToTag#` and `tagToEnum#` to take/return `Word#` instead of `Int#`? Wouldn't that be more consistent? It's a breaking change (for primop users), but changing the type of the comparision primops is a much more substantial breakage. Please can we ensure that the wiki page is up to date, explaining the actual proposed story and why it's better. Maybe it is already. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 11 Apr '13

11 Apr '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch 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 | ---------------------------------+------------------------------------------ Comment(by jstolarek): there is really no reason to suggest that the result of a boolean comparison operator might be negative! There's a bit of inconsistency here anyway, because `dataToTag#` and `tagToEnum#` return an `Int#`, thus suggesting that we can have negative enumerations. I changed the primops to return `Word#`, which - as expected - breaks a lot of code in boot libraries. I'm adding wrappers to avoid putting `(tagToEnum# (word2Int# ...))` everywhere. Are there any preferences regarding the names of these wrappers? I decided to use the name of the primop with the word "Bool" before #. This looks nice for `gtCharBool#` or `neFloatBool#`, but not so good for `>=Bool#` and `<Bool##`. Does anyone have a better idea for wrapper names? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7522: segfault when ignoring invalid byte sequence when decoding UTF8//IGNORE
by GHC 10 Apr '13

10 Apr '13

#7522: segfault when ignoring invalid byte sequence when decoding UTF8//IGNORE -------------------------------+-------------------------------------------- Reporter: ganesh | Owner: batterseapower Type: bug | Status: closed Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by batterseapower): * status: new => closed * resolution: => fixed Comment: Fixed and tested in 1ac38ef6e9decc3f4763848f3d43c0cc68d1d390 of the base library. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7522#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7826: GHC internal error: `a' is not in scope during type checking, but it passed the renamer
by GHC 10 Apr '13

10 Apr '13

#7826: GHC internal error: `a' is not in scope during type checking, but it passed the renamer --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- In the attached code the following lines give an internal GHC error. At least this should not happen. I also think this is valid code. Removing either type annotation makes this code compile. {{{ bug :: WrappedR Int -> SomeFunction bug (Wrap node) = case node of (Memo' (emptyT :: t a b) memoize (Var m) :: R' a b Int) -> -- also breaks }}} {{{ /Users/alessandro/Documents/Uni/thesis/test/bug-tvar-passed- renamer.hs:14:104: GHC internal error: `a' is not in scope during type checking, but it passed the renamer tcl_env of environment: [(am4, Identifier[node::R' a b Int, <NotTopLevel>, 1]), (rgs, Identifier[bug::WrappedR Int -> SomeFunction, <NotTopLevel>, 1])] In the type `R' a b Int' In a pattern type signature: R' a b Int In the pattern: Memo' (emptyT :: t a b) (memoize :: MVar (t a b) -> (a -> b) -> a -> b) (Var m :: R' a b Int) :: R' a b Int }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7825: Class used as a type parameter typechecks
by GHC 09 Apr '13

09 Apr '13

#7825: Class used as a type parameter typechecks -----------------------------+---------------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ class SomeClass a someValue :: Maybe (SomeClass a) someValue = undefined }}} This code compiles without any errors. The issue originates from [http://stackoverflow.com/questions/15903490 /why-can-classes-be-used-as-type-parameters-and-what-for this stackoverflow question]. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7629: segmentation fault in compiled program, involves gtk, selinux
by GHC 09 Apr '13

09 Apr '13

#7629: segmentation fault in compiled program, involves gtk, selinux --------------------------+------------------------------------------------- Reporter: wgmitchener | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.4.2 | Keywords: segmentation fault, multithreading, selinux, gtk Os: Linux | Architecture: x86 Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I wrote a multithreaded GUI program for a research project using gtk2hs, and it works fine on fedora 17, which uses ghc 7.0.4. It crashes almost as soon as it starts when compiled and run on fedora 18 (ghc 7.4.1). There's a message on the console that it was killed because of a segmentation fault and that's about all it tells me. I tracked down the code that causes crash, and it seems to happen because I add an action to the gtk loop: timeoutAddFull action ... and the crash happens when the action runs the first time. I thought it was a bug in ghc 7.4.1, because I found a bug report that talks about a crash involving STM and multithreading, and supposedly was fixed in 7.4.2. So I set up a virtual machine and installed fedora 18 then upgraded it to rawhide to try my program under 7.4.2. But, the same crash happens on my rawhide machine. However, it happened that I had to disable selinux on my rawhide machine using the boot command line because something started going wrong, still not sure what (hey, it's rawhide). Now my program does not crash. I just tested this on my fedora 18 laptop (still ghc 7.4.1) using both the version compiled on fedora 18 and the files from where I compiled it on rawhide: when I disable selinux, my program runs fine, but when it's enabled (even if set to permissive rather than enforcing) my program seg faults. There's nothing useful in /var/log/messages, no indication of what selinux is unhappy about. I did find this: http://www.haskell.org/pipermail /haskell-cafe/2007-August/031120.html but at least in that problem, there was a definite error message about memory mapping, and I'm not getting one. So as best I can tell, ghc 7.4.1&2 must both be doing something strange, maybe marking some piece of memory as data instead of code, maybe when performing calls to gtk, maybe in building thunks for use by timeoutAddFull, and eventually triggering a security problem. My original program is huge. The problem must be some unexpected interaction between ghc's newer run time systems, gtk, and selinux. I'm attaching the smallest test case I could concoct and the build command. When you run the resulting program, it does nothing for about 2 seconds, then the action to print "tick" runs, and it crashes. I'm filing the bug here because it might be a problem in the ghc runtime. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

Re: [GHC] #6135: Unboxed Booleans
by GHC 08 Apr '13

08 Apr '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch 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 | ---------------------------------+------------------------------------------ Comment(by benl): I vote for changing the existing primops to use Word#, and don't bother supporting the existing Bool returning versions. I think we can get away with changing the existing types because it's trivial to update client code to use the new versions. You just need to add (tagToEnum# (word2Int# ...)). I vote for making the primops return Word# instead of Int#. I know that this requires an extra word2Int# conversion when using tagToEnum#, but there is really no reason to suggest that the result of a boolean comparison operator might be negative! I suspect the reason tagToEnum# currently takes an Int# is because literals like 5# are Int#. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7316: GHC segfaults on ARM
by GHC 08 Apr '13

08 Apr '13

#7316: GHC segfaults on ARM -------------------------+-------------------------------------------------- Reporter: laney | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.2 Keywords: | Os: Unknown/Multiple Architecture: arm | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 7623 Related: | -------------------------+-------------------------------------------------- Changes (by cjwatson): * cc: cjwatson@… (added) Comment: I'm far from certain, but it's possible that my patch in http://hackage.haskell.org/trac/ghc/ticket/7823 will help with this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7316#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7822: Undeclared errors from CMM files during GHC PPC cross compiler build
by GHC 08 Apr '13

08 Apr '13

#7822: Undeclared errors from CMM files during GHC PPC cross compiler build --------------------------------+------------------------------------------- Reporter: matts | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- I'm getting error: function undeclared errors when the Apply.cmm file is compiled and other CMM files if a parallel build is done. I'm trying to build an powerpc target GHC cross compiler with the enabled-unregisterised configuration set. "inplace/bin/ghc-stage1" -static -optc-DDEBUG -ticky -DTICKY_TICKY -H64m -O0 -fasm -Iincludes - Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -optc-DNOSMP -dcmm- lint -i -irts -irts/ dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0 -c rts/Apply.cmm -o rts/dist/build/Apply.debug_o when making flags consistent: Warning: Compiler unregisterised, so compiling via C /tmp/ghc22044_0/ghc22044_0.hc: In function 'stg_ap_0_fast': /tmp/ghc22044_0/ghc22044_0.hc:21:12: error: 'debugBelch' undeclared (first use in this function) /tmp/ghc22044_0/ghc22044_0.hc:21:12: note: each undeclared identifier is reported only once for each function it appears in /tmp/ghc22044_0/ghc22044_0.hc:24:12: error: 'printClosure' undeclared (first use in this function) /tmp/ghc22044_0/ghc22044_0.hc:31:12: error: 'checkStackFrame' undeclared (first use in this function) /tmp/ghc22044_0/ghc22044_0.hc: In function 'stg_PAP_entry': /tmp/ghc22044_0/ghc22044_0.hc:127:12: error: 'barf' undeclared (first use in this function) make[1]: *** [rts/dist/build/Apply.debug_o] Error 1 make: *** [all] Error 2 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7822> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7812: Ambiguity check too eager with unconstrained type variable
by GHC 08 Apr '13

08 Apr '13

#7812: Ambiguity check too eager with unconstrained type variable -----------------------------+---------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: AmbiguityCheck Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider the following code: {{{ {-# LANGUAGE TypeFamilies, DataKinds, GADTs #-} type family F (b :: Bool) a type instance F False a = a type instance F True a = Int data SBool :: Bool -> * where SFalse :: SBool False STrue :: SBool True foo :: SBool b -> [F b a] foo _ = [] }}} GHC 7.6.1 compiles this code without a problem, and both {{{foo STrue}}} and {{{foo SFalse}}} are well typed and evaluate to {{{[]}}}. HEAD (even after yesterday's ambiguity patch for #7804) does not compile this code, complaining about ambiguity. Here is the error: {{{ Couldn't match type ‛F b a0’ with ‛F b a’ NB: ‛F’ is a type function, and may not be injective The type variable ‛a0’ is ambiguous Expected type: SBool b -> [F b a] Actual type: SBool b -> [F b a0] In the ambiguity check for: forall (b :: Bool) a. SBool b -> [F b a] In the type signature for ‛foo’: foo :: SBool b -> [F b a] }}} This is admittedly a weird corner case, but it's one I've run into in real(ish) code. On first glance, the type variable {{{a}}} really is ambiguous in the type signature for {{{foo}}}. But, it turns out that this is a benign ambiguity, because the variable is either ignored or, after type family simplification, appears in an inferrable location within the type. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3