- ghc-tickets - Haskell.org

Re: [GHC] #5863: Deriving Typeable for data families
by GHC 21 May '13

21 May '13

#5863: Deriving Typeable for data families ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by dreixel): * owner: => dreixel Comment: Alright, I'll take care of this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5863#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5863: Deriving Typeable for data families
by GHC 21 May '13

21 May '13

#5863: Deriving Typeable for data families ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): You've convinced me to be dubious about #7897 (see comment added). So yes, let's disable `deriving Typeable` for family instances, with a message saying that you need to derive it for the family itself. And some words for the user manual would be good. Thanks. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5863#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints
by GHC 21 May '13

21 May '13

#7897: MakeTypeRep fingerprints be proper, robust fingerprints ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ A `TypeRep` currently looks like this: {{{ data TypeRep = TypeRep Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} If two `TypeRep`s have the same fingerprint they should really describe identical types. But that's not really true today, becuase today the fingerprint for a `TyCon` is obtained by hashing the ''name'' of the type constructor (e.g. `base:Data.Maybe.Maybe`), but not its ''structure''. To see how this is non-robust, imagine that {{{ module M where data T = MkT S deriving( Typeable ) data S = S1 Int | S2 Bool deriving( Typeable ) }}} Now I do this: * Write a program that costructs a value `v::T`, and serialises into a file (a) the `TypeRep` for `v`, and (b) `v` itself. * Now I alter the data type declaration for `S` * Now I recompile and run the program again, which attempts to read the value back in from the file. It carefully compares `TypeRep`s to be sure that the types are the same... yes, still "M.T". * But alas the de-serialisation fails because `S` has been changed. What we really want is for the fingerprint in a `TypeRep` to really be a hash of the definition of `T` (not just its name), including transitively the fingerprints of all the types mentioned in that definition. In effect, a `TypeRep` is a dynamic type check, and it should jolly well be a robust dynamic type check. This might also matter in a Cloud Haskell application with different components upgraded at different times. As it happens, GHC already computes these fingerprints, to put in interface files. But they aren't used when making the `Typeable` instances for `T`. I think it should be. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7897> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5863: Deriving Typeable for data families
by GHC 21 May '13

21 May '13

#5863: Deriving Typeable for data families ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by dreixel): We do allow (standalone) `deriving Typeable` for `T`, so I guess the way to fix this is to simply disable `deriving Typeable` for family instances. Unless we want to wait for #7897, of course. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5863#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7921: DSO linking bug in unix package
by GHC 21 May '13

21 May '13

#7921: DSO linking bug in unix package -------------------------------+-------------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- {{{unix}}} depends on {{{libpthread}}}, but it's not listed under {{{extra-libraries}}} in the cabal file. For that reason some programs fail to build on Ubuntu 13.04. Steps to reproduce: {{{ -- Main.hs import System.Posix.Semaphore main :: IO () main = do semUnlink "foo" }}} {{{ $ ghc --make Main.hs }}} Expected result: Program is compiled and linked. Actual result: Liking fails with {{{ /usr/bin/ld: /home/foo/.install/haskell/ghc-7.6.2/lib/ghc-7.6.2/unix-2.6.0.1/libHSunix-2.6.0.1.a(Semaphore__5.o): undefined reference to symbol 'sem_unlink@@GLIBC_2.2.5' /usr/bin/ld: note: 'sem_unlink@@GLIBC_2.2.5' is defined in DSO /lib/x86_64 -linux-gnu/libpthread.so.0 so try adding it to the linker command line /lib/x86_64-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status }}} This is related to https://fedoraproject.org/wiki/UnderstandingDSOLinkChange. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #6135: Unboxed Booleans
by GHC 20 May '13

20 May '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by jstolarek): Performance: I think this patch shouldn't have any impact on performance of existing code. It will however allow to write branchless algorithms that can be faster than their branching counterparts. I'm not sure about the tests in the testsuite - do they allow to measure execution speed? I see only some memory stats. Integers: I'm afraid I don't understand how could I reproduce my problem using HEAD. Integer constant folding rules are built into the compiler and trigger based on function name, so not sure if writing fake primops and wrappers can be considered bug reproduction. I'm missing something, right? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7799: Assembly error while building GHC 7.7
by GHC 20 May '13

20 May '13

#7799: Assembly error while building GHC 7.7 --------------------------------+------------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: x86 Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- While building GHC 7.7 (after running `make') I got this error message: {{{ $ "inplace/bin/ghc-stage1" -keep-tmp-files -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base /dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist- install/build/autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist- install/build/autogen/cabal_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-user-package-db -rtsopts -odir libraries/base/dist- install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist- install/build/System/Posix/Internals.dyn_o <braries/base/dist-install/build/System/Posix/Internals.dyn_o ghc23405_0.c: Assembler messages: ghc23405_0.c:127:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:153:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:181:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:207:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:235:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:261:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:285:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:311:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:339:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:367:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:393:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:421:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:449:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:477:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:505:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:525:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:526:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:527:0: Error: Missing symbol name in directive ghc23405_0.c:527:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:528:0: Error: Missing symbol name in directive [1] baldur@baldur-lappi:~/ghc> "inplace/bin/ghc-stage1" -keep-tmp-files -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist- install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base /dist-install/build/autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist- install/build/autogen/cabal_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-user-package-db -rtsopts -odir libraries/base/dist- install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist- install/build/System/Posix/Internals.dyn_o <braries/base/dist-install/build/System/Posix/Internals.dyn_o ghc23405_0.c: Assembler messages: ghc23405_0.c:127:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:153:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:181:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:207:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:235:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:261:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:285:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:311:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:339:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:367:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:393:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:421:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:449:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:477:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:505:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:525:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:526:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:527:0: Error: Missing symbol name in directive ghc23405_0.c:527:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:528:0: Error: Missing symbol name in directive ghc23405_0.c:528:0: Error: junk at end of line, first unrecognized character is `.' ghc23405_0.c:529:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:528:0: Error: junk at end of line, first unrecognized character is `.' ghc23405_0.c:529:0: Error: junk at end of line, first unrecognized character is `1' }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #6135: Unboxed Booleans
by GHC 20 May '13

20 May '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by simonpj): Great. I suggest * One patch per repo, with a commit message summarising changes. No need to record all the intermediate patches on your path to completion! * The goal of all this is better performance. So including that evidence in the commit message would be good. Maybe the improved perf only shows on benchmarks that aren't in nofib? Then perhaps add tests to `perf/should_run` and point to them from the commit message. * I don't understand the cause of the `eqInteger#` constant folding problem. It should be easy to reproduce in HEAD, just by writing a new `Integer` type in test, and some suitable wrappers and a fake primop (with NOINLINE on that). Then you can open a ticket on that and we can solve it separately. Probably it'll be done before you are ready with all the rest. * User docs: I'm not sure that any change is needed. The important thing is that the wiki page is up to date, explains the motivation and the reasoning for the main design choices (eg why `Int#` rather than `Word#` as the return type). Thanks Jan Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 20 May '13

20 May '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by jstolarek): I have implemented the changes. Now I am left with cleaning up the code, writing more tests and verifying that there are no performance regressions. This will take some more time, but I would like to ask how should I prepare my patches (there will be a total of 7: ghc, testsuite and libraries: base, ghc-prim, integer-gmp, integer-simpl and primitive). Should I squash all the commits in my branches into one big commit or can I leave the commits as they are (or perhaps squash them selectively)? Which user documentation, if any, should I update (aside from the wiki page)? What information should be documented in the source code? There is one thing I wasn't able to implement the way I think it should be: constant folding for Integer. Each comparison function for Integer is now split into a primop, which returns an Int#, and a wrapper, which calls tagToEnum# and returns a Bool. The constant folding rules for Integer are working on the wrappers, so that whenever somebody writes ((1 :: Integer) == 1) it gets constant folded to True. This works properly and doesn't break any existing code, but is inconsistent with the rules for other comparisons, which are defined for primops, not for their wrappers. So the call to "`eqInteger 1 1`" (the wrapper) gets constant folded, while the call to "`eqInteger# 1 1`" (the primop) doesn't. I have run into problems with this (posted on ghc-devs on May 16th) and I don't know how to fix this. What is others' opinion on accepting the patches with this defect and opening a separate ticket for constant folding of Integer primops? I actually don't like that idea, but I'm afraid I might be stuck on this one for another 2 or 3 weeks - it would be a lot easier for me to push all the changes I have been making and then focus solely on Integer constant folding. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 20 May '13

20 May '13

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- LLVM provides a number of atomicity / memory ordering primitives. currently the CAS primops exposed at the CMM level are ffi'd inline assembly fun calls. this means that for certain concurrency primops, we've got fun calls within funcalls that could be easily inlined if we did it in a more llvm direct way. A notable example of this is the implementation of {{{ stg_atomicModifyMutVarzh }}} relevant basic llmv docs are the following [http://llvm.org/docs/LangRef.html#cmpxchg-instruction Atomic llvm ops] [http://llvm.org/docs/Atomics.html semantics of the various ordering levels] relevant locations in the ghc source [https://github.com/ghc/ghc/blob/master/includes/stg/SMP.h#L170 CAS inline assembly] [https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L282 defn of atomicModifyMutVar cmm code] Based upon my reading of the relevant GHC cmm code, and reading the semantics of the LLVM operations, the right level of atomic ordering in the generated bit code would be "SequentiallyConsistent". a first step would be to modify the CMM -> LLVM pass to substitute the cas funcall with the right llvm operation. This ''' SEEMS ''' like it'd be very very easy to do and low hanging fruit. Theres a few upsides that ''' might ''' come out of this. 1. would be easy to augment to also provide a doubleCAS primitive, which would be useful in writing various lock free data structures. 2. would increase the portability / ease of retargeting new platforms / hardware via LLVM. (not needing to worry about the target's memory consistency model / write new cases of inline assembly) 3. (this would need benchmarks) could potentially improve the performance of certain heavy concurrency operations by eliminating a funcall in an otherwise tight loop. 4. Theres probably other interesting possible upside, such as perhaps having more of the rts be nicely writeable in CMM? (esp since theres now native funcall support) 5. Also would make the CMM memory model a bit more explicit perhaps? This seems like a *relatively* managable patch to write. I'm up for spending time on this if, should it work, it'd be likely to be merged in. it'd also be a good warm up for a number of other things I want to do, including http://hackage.haskell.org/trac/ghc/ticket/5567#comment:10 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3