October 2014 - ghc-tickets

[GHC] #8890: segfault on Windows 7 i386
by GHC 27 Oct '14

27 Oct '14

#8890: segfault on Windows 7 i386 ----------------------------+--------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- This minimal example causes the GHC 7.8.1 i386 RC1 and RC2 binaries to segafult on two different Window 7 machines. It doesn't happen with the x86_64 binaries and it doesn't happen on the one Windows 8.1 machine I tried. {{{ {-# LANGUAGE GADTs #-} module Test1 where data T t where T :: T () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9006: GHC accepts import of private data constructor if it has the same name as the type
by GHC 27 Oct '14

27 Oct '14

#9006: GHC accepts import of private data constructor if it has the same name as the type --------------------------+------------------------------------------------ Reporter: | Owner: Lemming | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ {{{ $ cat A.hs B.hs module A (T) where data T = T module B where import A (T(T)) }}} `ghci-7.8.2` accepts module B, whereas `ghci-7.6.3` and `ghci-7.4.2` say: {{{ B.hs:3:11: Module `A' does not export `T(T)' }}} For this bug to happen it is important, that the data constructor has the same name as the type. I.e. if you rename the data constructor to, say, `Cons`, then `ghci-7.8.2` will emit the same error as earlier versions. The bug is not dramatic, since if you try to actually use the imported data constructor then ghc will say {{{ B.hs:20:5: Not in scope: data constructor ‘T’ }}} However this error message is very confusing, because it suggests that `T` is not in scope although you imported it correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9435: x86 sse4.2 popCnt16# needs to zero-extend its result
by GHC 27 Oct '14

27 Oct '14

#9435: x86 sse4.2 popCnt16# needs to zero-extend its result -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non- ghci non-llvm ways. For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8345: A more efficient atomicModifyIORef'
by GHC 27 Oct '14

27 Oct '14

#8345: A more efficient atomicModifyIORef' ------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `atomicModifyIORef'` is currently defined as: {{{ #!haskell atomicModifyIORef' ref f = do b <- atomicModifyIORef ref (\x -> let (a, b) = f x in (a, a `seq` b)) b `seq` return b }}} This doesn't seem to be the best we can do, though. The following implementation exhibits a speedup of 1.7x (vanilla RTS) / 1.4x (threaded RTS) over the current implementation: {{{ #!haskell atomicModifyIORef' ref f = do b <- atomicModifyIORef ref $ \a -> case f a of v@(a',_) -> a' `seq` v b `seq` return b }}} The differences between this version and the current version are: 1. the lambda is now strict in `f a`, and 2. a new result tuple is no longer being allocated. Is there a good reason why `atomicModifyIORef'` is not already defined this way? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9031: ghc panic: RegAlloc.Liveness.computeLivenss
by GHC 27 Oct '14

27 Oct '14

#9031: ghc panic: RegAlloc.Liveness.computeLivenss -----------------------------------+--------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I have some code where ghc consistently panics with {{{ RegAlloc.Liveness.computeLivenss SCCs aren't in reverse dependent order bad blockId c1kek }}} The only reference I can find to that block in the dumped output is here: {{{ REC c1kej: movq $block{v c1keo}_info,(%rbp) movsd 7(%rbx),%vSSE_s1ivM movsd 15(%rbx),%vSSE_s1ivN movq 96(%rbp),%rbx movsd %vSSE_s1ivN,88(%rbp) movsd %vSSE_s1ivM,96(%rbp) testq $7,%rbx jne _c1keo jmp _c1kep c1kpo: movq $block{v c1kej}_info,(%rbp) movq %vI_s1it5,%rbx movq $0,120(%rbp) testq $7,%rbx jne _c1kej jmp _c1kek, }}} There doesn't appear to be any reference to {{{c1kpo}}} either. Unfortunately I don't yet have a test case I can provide; I'll keep working on that. Building with -dcore-lint and -dcmm-lint don't show any extra errors. This is with ghc-7.8.2 using NCG. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9031> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4440: time004 fails depending on the date
by GHC 26 Oct '14

26 Oct '14

#4440: time004 fails depending on the date -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: new Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.1 Component: Test Suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * difficulty: => Unknown Comment: fyi, it's that time of the year again... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4440#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7320: GHC crashes when building on 32-bit Linux in a Linode
by GHC 25 Oct '14

25 Oct '14

#7320: GHC crashes when building on 32-bit Linux in a Linode ---------------------------------------------+---------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------------+---------------------------- Changes (by gintas): * cc: gintas, simonmar (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7320#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9720: libffi compilation does not use bundled g++ on Windows
by GHC 25 Oct '14

25 Oct '14

#9720: libffi compilation does not use bundled g++ on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Building GHC fails on Windows (at least on mingw32) if there is no host g++ compiler available. The cause seems to be that configure script looks for a C++ compiler and fails to find one. Here's the invocation of the libffi configure script from the main build: cd libffi && \ \ cd build && \ CC=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/inplace/mingw/bin/gcc.exe \ LD=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/inplace/mingw/bin/ld.exe \ AR=/usr/bin/ar \ NM=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/inplace/mingw/bin/nm.exe \ RANLIB=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/inplace/mingw/bin/ranlib.exe \ CFLAGS=" -U__i686 -march=i686 -fno-stack-protector -w" \ LDFLAGS=" -w" \ "/bin/sh" ./configure \ --prefix=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/libffi/build/inst \ --libdir=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/libffi/build/inst/lib \ --enable-static=yes \ --enable-shared=no \ --host=i386-unknown-mingw32 Note that CC is overridden, but CXX is not. The configure script then looks for a C++ compiler and finds KCC, which is not even a compiler but a kerberos tool: checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl.exe... no checking for FCC... no checking for KCC... KCC checking whether we are using the GNU C++ compiler... no checking whether KCC accepts -g... no checking dependency style of KCC... none This causes the configure script to fail later on. g++ is not actually used in the build (looks like it's only needed for one test case), passing in gcc for CXX seems to work fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9720> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform
by GHC 25 Oct '14

25 Oct '14

#9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform -------------------------------------+------------------------------------- Reporter: angerman | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: MacOS X Architecture: arm | Type of failure: Building Difficulty: Easy (less than 1 | GHC failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140906 for arm-apple-ios): globalRegMaybe not defined for this platform Patch is at https://phabricator.haskell.org/D208 already. A similar bug for non-registers builds was raised as #9055 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9549: deriveConstants fails on OpenBSD
by GHC 25 Oct '14

25 Oct '14

#9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: OpenBSD Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On OpenBSD 5.5 compilation of current HEAD fails with: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno- stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc- flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist- ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/nm" nm: unknown option -- P usage: nm [-aCegnoprsuw] [file ...] deriveConstants: readProcess: /usr/bin/nm "-P" "includes/dist- derivedconstants/header/tmp.o" (exit 1): failed includes/ghc.mk:167: recipe for target 'includes/dist- derivedconstants/header/DerivedConstants.h' failed gmake[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 Makefile:71: recipe for target 'all' failed gmake: *** [all] Error 2 }}} This is due to OpenBSD's nm not supporting the -P option. Perhaps it can be fixed by using 'objdump --syms' instead of 'nm -P' (see attached OpenBSD-only patch). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9549> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8