May 2013 - ghc-tickets

[GHC] #7909: GHC doesn't respect -optl and -optc in a couple of places
by GHC 21 May '13

21 May '13

#7909: GHC doesn't respect -optl and -optc in a couple of places ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ A legitimate use of `-optl` and `-optc` is to pass options that should ''always'' be passed to gcc, such as `-B<something>` if we're invoking `gcc` against a particular set of libraries. For this to work, we have to ensure that `-optl` and `-optc` options are always passed. In `joinObjectFiles`, we don't add the options from `-optl`. I suspect that we don't want to just add them, because we also put the `-l` options in this list, so we should separate the two. In `mkExtraObj`, we don't add the options from `-optc`. Probably we should refactor things so that these options are automatically added by `SysTools.runCc` and friends, being careful about option ordering. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7907: patch to make comment about stgclosure struct more accurate
by GHC 21 May '13

21 May '13

#7907: patch to make comment about stgclosure struct more accurate ------------------------------+--------------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- I've been digging into the rts code to understand function application etc, and the current comment about where StgClosure is defined is wrong. theres a patch fix it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7907> 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: 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 20 May '13

20 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