- ghc-tickets - Haskell.org

Re: [GHC] #5841: seg fault in ghci but not ghc when using chart-gtk code
by GHC 27 May '13

27 May '13

#5841: seg fault in ghci but not ghc when using chart-gtk code -------------------------------+-------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: 5816 | -------------------------------+-------------------------------------------- Comment(by carter): has anyone tested this or one of the many other ghci problematical codes against ghci in ghc head yet? My understanding is that the switch to dylibs for ghci should resolve many of the "funny problems with ghci" bugs people have had over the years. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5841#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7904: GHC calls the cc1 of a gcc thats not the first in PATH
by GHC 27 May '13

27 May '13

#7904: GHC calls the cc1 of a gcc thats not the first in PATH -------------------------+-------------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- I was earlier today trying to build some haskell code that ffi's out to some c code that uses SSE4 / AVX intrinsics, and was getting odd errors about not understanding -mavx or -msse4.2 , which was quite surprising since I was able to build those same c source files with clang or the gcc 4.8 i have at the top of my path. After some digging (and running dtrace while trying to bulld my code), I found that some point in the build process, ghc/cabal was running the cc1 of the apple gcc-llvm v4.2 (ie the gcc version i had used to build the ghc and comes with apple dev tools current version, and which lacks support for avx or sse4.2 ). I only hit this problem because i was deliberately writing code that would only compile assuming avx / sse4.2 support on the c compiler side, though this does have the implication that when ghc users are doing a simple cabalized build of some c code that has SIMD intrinsics, it'll only use simd <= ssse3, no higher. This could result in certain haskell codes on os x that lean on vectorized ffi's being 2x slower or worse than on other architectures perhaps. I'll be working around this problem in my own software development by rebuilding ghc on my mac using gcc 4.8 and see if that resolves that problem. That ends my overview of the bug whereby ghc uses the cc1 of the gcc that built it even when others are earlier in the path (which creates unexpected problems when naively using ghc as the c compilation driver). Now for the feature request: assuming theres a good reason for having the cc1 choice hard coded in, it'd probably be helpful for ghc to issue a warning when the hardwired cc1 refers to a gcc that isn't the first one visible when looking up gcc in the $path. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #7929: -pgma and -pgmc flags dont work as expected on mac
by GHC 27 May '13

27 May '13

#7929: -pgma and -pgmc flags dont work as expected on mac -------------------------+-------------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: 7678 Blocking: | Related: 7922,7678 -------------------------+-------------------------------------------------- This is a bug report version of a related ticket. As I discuss in [http://hackage.haskell.org/trac/ghc/ticket/7922#comment:23 this ticket], the Assembler available on the Mac OS X platform does not support AVX instructions, though the operating system/ platform does. Clang, because it uses LLVM as a backend, supports AVX, and can generate AVX simd ops in the object code directly, or AVX assembly, or assemble assembly that uses AVX. Clang will select AVX instructions on SandyBridge or newer macs when given the -march=native flag. There is another subtlety: the Apple Developer tools version of gcc 4.2 is old enough that it doesn't understand -march=native / doesn't support avx, and while newer versions of gcc (eg gcc 4.8), understand -march=native, and can choose -march=corei7-avx as appropriate (which corresponds to most new macs of the past 2 years), and while these newer gcc's can generate assembly that uses AVX instructions, these newer gcc's still seem to try to use the system assembler. Now, one would think/hope that passing {{{ -pgma clang -pgmc clang }}} to ghc would resolve this build problem, however, this does not seem to work, though as documented in the related ticket, calling clang directly with the flags that ghc would generate DOES work correctly, (but calling clang by hand is no substitute for a compilation driver) {{{ clang -march=native -mavx $flags -S foo.c clang -march=native -mavx $flags -c foo.s }}} what *does* work is change the settings file that gets installed with ghc (for me this file is at /user/local/lib/ghc-7.6.2/settings) to have '''clang''' as the default ghc compiler rather than '''gcc'''. This makes the build work on the toy test case, but because of the [http://hackage.haskell.org/trac/ghc/ticket/7678 clang cpp problem ticket], clang is not a viable default compiler setting for ghc as yet. The fact that changing the settings file compiler from gcc -> clang worked, but doing {{{-pgma clang -pgmc clang }}} does not, suggest either those flags are incorrectly implemented for OS X ghcs, or there is some switch that isn't toggled by the currently exposed compiler passes. I can work around these corner cases, at the cost of some complexity in my build tooling, but the fact that the -pgma clang -pgmc clang bits didn't work, but changing the settings file did work (something that really isn't a good idea given how clang and ghc interact wrt c pre processor), suggests that some part of the build process for the c -> object code path in the ghc driver isn't being configured properly by the standard program flags, but is changed by the settings file. So this suggests that semantically there is some bug in the driver, or a part of the build process that doesn't have a flag exposed yet, but which behaves different subject to change the compiler choice in the ghc settings file. This seems like a misfeature. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7929> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #7937: Misleading "Precedence parsing error" when using an undefined operator
by GHC 27 May '13

27 May '13

#7937: Misleading "Precedence parsing error" when using an undefined operator -----------------------------+---------------------------------------------- Reporter: ktvoelker | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #2993 -----------------------------+---------------------------------------------- I was using QuickCheck and wrote something like this: a > 0 ==> a == b But I hadn't imported (==>), and I got an error about mixing two operators with the same fixity (the two comparisons). This error was misleading, since once I imported ==>, which has a lower fixity, there was no problem. I have a complete example file to attach. This might be identical to #2993, but the situation there was not quite the same, so I am filing a new bug rather than reopening it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7937> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7878: Panic when using DerivingGeneric with hs-boot
by GHC 26 May '13

26 May '13

#7878: Panic when using DerivingGeneric with hs-boot -------------------------------+-------------------------------------------- Reporter: ryant5000 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- When a module that uses DerivingGeneric has an hs-boot file, a panic like the following results: ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: main:A.D1Test{tc apn} [(roo,ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: The attached files demonstrate the issue. To reproduce, run 'ghc --make C'. Note that running the same command a second time will not cause the error, unless *.hi* files are deleted. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7878> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7936: newStdGen leaks memory when result is not used
by GHC 26 May '13

26 May '13

#7936: newStdGen leaks memory when result is not used -----------------------------+---------------------------------------------- Reporter: ryantrinkle | Owner: Type: bug | Status: new Priority: normal | Component: libraries/random Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When newStdGen is invoked repeatedly without making any use of the resulting StdGen values, it leaks memory, as in the following: {{{ -- Leaks memory main = forever newStdGen }}} When a random number produced by the result is evaluated, no leak occurs: {{{ -- Does not leak memory main = forever $ do r <- newStdGen evaluate $ fst $ next r }}} However, evaluating the result itself is not sufficient to eliminate the leak: {{{ -- Leaks memory main = forever $ do r <- newStdGen evaluate r }}} After sufficient iterations of newStdGen, subsequent use will cause a stack overflow: {{{ -- Causes stack overflow main = do replicateM 1000000 newStdGen r <- newStdGen evaluate $ fst $ next r }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7936> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7729: GHC panics. Invalid core
by GHC 26 May '13

26 May '13

#7729: GHC panics. Invalid core -----------------------------+---------------------------------------------- Reporter: Khudyakov | 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: -----------------------------+---------------------------------------------- Following code snippet triggers panic: {{{ {-# LANGUAGE FlexibleContexts, TypeFamilies #-} module Monad where class Monad m => PrimMonad m where type PrimState m class MonadTrans t where lift :: Monad m => m a -> t m a class (PrimMonad (BasePrimMonad m), Monad m) => MonadPrim m where type BasePrimMonad m :: * -> * liftPrim :: BasePrimMonad m a -> m a newtype Rand m a = Rand { runRand :: Maybe (m ()) -> m a } instance (Monad m) => Monad (Rand m) where return = Rand . const . return (Rand rnd) >>= f = Rand $ \g -> (\x -> runRand (f x) g) =<< rnd g instance MonadTrans Rand where lift = Rand . const instance MonadPrim m => MonadPrim (Rand m) where type BasePrimMonad (Rand m) = BasePrimMonad m liftPrim = liftPrim . lift }}} GHC 7.6.2 panics {{{ $ ghc-7.6.2 -c Monad.hs ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): cgLookupPanic (probably invalid Core; try -dcore-lint) $dMonadTrans{v ahe} [lid] static binds for: local binds for: main:Monad.lift{v ra} [gid[ClassOp]] main:Monad.liftPrim{v rc} [gid[ClassOp]] main:Monad.$p1PrimMonad{v rgv} [gid[ClassOp]] main:Monad.$p1MonadPrim{v rgA} [gid[ClassOp]] main:Monad.$p2MonadPrim{v rgB} [gid[ClassOp]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} whereas 7.4.2 reports type error {{{ $ ghc-7.4.2 -c Monad.hs Monad.hs:28:14: Occurs check: cannot construct the infinite type: m0 = t0 m0 Expected type: BasePrimMonad (Rand m) a -> Rand m a Actual type: m0 a -> Rand m a In the expression: liftPrim . lift In an equation for `liftPrim': liftPrim = liftPrim . lift }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #7935: Syntactic sugar for comonads
by GHC 26 May '13

26 May '13

#7935: Syntactic sugar for comonads -----------------------------+---------------------------------------------- Reporter: wvv | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- It could be useful to have this as extension. More details: http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html chapter "Syntactic sugar for comonads" {{{ method wa> expr1 wb> expr2 wc> expr3 = -- this desugars to: \wa -> let wb = extend (\this -> expr1) wa wc = extend (\this -> expr2) wb in extract $ extend (\this -> expr3) wc }}} and {{{ method expr1 expr2 expr3 = \_wa -> let _wb = extend (\this -> expr1) _wa _wc = extend (\this -> expr2) _wb in extract $ extend (\this -> expr3) _wc }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7934: usleep hangs, no threads
by GHC 25 May '13

25 May '13

#7934: usleep hangs, no threads ----------------------------------------+----------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.4.2 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: 1156 ----------------------------------------+----------------------------------- import System.Posix.Unistd main = flip mapM_ [0..] $ \i -> do usleep 100000 print i === The above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to print). The documentation for usleep warns about bad interactions with threads, but the above program doesn't use any. The problem also occurs with nanosleep, but not with threadDelay. #1156 sounds related, but this time the problem also occurs without -threaded. === workaround: use threadDelay. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7934> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver
by GHC 25 May '13

25 May '13

#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver -----------------------------+---------------------------------------------- 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: #7904 -----------------------------+---------------------------------------------- currently when GHC is used as the compilation driver for C code, it will always compile the C code (*.c) to assembly (*.s) and then in a subsequent phase map the assembly to the various object formats. Thusly: the feature request I have is adding support to ghc (perhaps via indication through a new flag) for running the C compiler as something like {{{ gcc source.c -c }}} rather than {{{ gcc source.c -s -c }}} (these are not necessarily the right flags, but rather a strawman representation of the difference). on certain operating systems, notable OS X, the system provided Assembler (to which there is no, more up to date, alternative) does not support / understand all of the instructions that gcc or clang will emit. Notably, as a general rule, compiling c code with -march=native flag *should not* break. However, on OS X on recent hardware, -march=native will use AVX SIMD instructions / registers if available, which the mac os x assembler doesn't understand. and thus an end user trying to build some haskell and c-code locally will have a very odd error that will take a bit of effort to understand. this took a bit of ef Likewise, when doing -fllvm compilation, the *.c-> *.s phase just slows down the compilation process period. I'm still learning the ghc compilation driver architecture, but it seems like this would be a relatively minimal change, and it'd be valuable along a number of atrributes This is not -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7922> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24