- ghc-tickets - Haskell.org

[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 26 Oct '14

26 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

Re: [GHC] #5966: getAppUserDataDirectory does not respect XDG specification
by GHC 25 Oct '14

25 Oct '14

#5966: getAppUserDataDirectory does not respect XDG specification -------------------------------------+------------------------------------- Reporter: ordcoder | Owner: ekmett Type: bug | Status: upstream Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: 6077 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@… (added) * status: new => upstream Comment: Filed this upstream as https://github.com/haskell/directory/issues/6 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5966#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9721: RecordWildCards panic
by GHC 25 Oct '14

25 Oct '14

#9721: RecordWildCards panic -------------------------------------+------------------------------------- Reporter: jorgemendes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC 7.4.1 (Debian 7.7 and Ubuntu 12.04.5 LTS) panics with: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-linux): compiler/rename/RnPat.lhs:535:39-79: Irrefutable pattern failed for pattern gres@(gre : _) }}} I found a minimal test case to exemplify this issue: {{{#!hs module Foo where import Bar (Bar (Bar)) foo :: Bar -> () foo Bar {..} = () }}} {{{#!hs module Bar where data Bar = Bar { barA :: Int, barB :: Int } }}} A workaround is to import all data fields in module Foo: {{{#!hs import Bar (Bar (..)) }}} I also tried this with GHC 7.6.3 (Mac OS X), with no warnings nor errors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2132: Optimise nested comparisons
by GHC 24 Oct '14

24 Oct '14

#2132: Optimise nested comparisons -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by TomSchrijvers): * cc: tom.schrijvers@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2132#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0