- ghc-tickets - Haskell.org

[GHC] #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE
by GHC 27 Jan '18

27 Jan '18

#12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE --------------------------------------+---------------------------------- Reporter: pggiarrusso | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- I have here a ~600MB core dump on GHC 8.0.1 x86_64 linux triggered under low memory (1GB RAM total, no swap, trying to build aeson with optimizations), with a stacktrace blaming the GHC runtime system. Based on code review, it appears that when requesting memory from the OS fails, the error is ignored and GHC segfaults as soon as it writes to the newly "allocated" memory. == Diagnosis == My diagnosis is that osCommitMemory calls the potentially failing `my_mmap` but returns void (hence not propagating failures); it should instead probably use `my_mmap_or_barf` or handle the failure anyhow: https://github.com/ghc/ghc/blob/a6111b8cc14a5dc019e2613f6f634dec4eb57a8a/rt… However, while I'm very convinced that's a bug, I'm only mostly confident that's the culprit, since the segfault happens later; I've just looked for bugs on allocation failures in the code ran shortly before the crash. == Raw data == The core dump is on a VM from the reporter of https://github.com/commercialhaskell/stack/issues/2575, https://github.com/jiakai0419, which graciously gave me access to the VM and bothered reporting in the first place—I'd like to thank her. I'd like to avoid copying the dump here unless strictly needed. == Reproduction == The bug is deterministic on that machine, but it requires a failure in mmap without triggering an OOM, so I'm not 100% sure how easy it is to reproduce but it should be easy on a VM with 1GB RAM and 1 core. Here's the output of `free`: {{{ $ free total used free shared buff/cache available Mem: 1015352 95864 71396 51244 848092 733132 Swap: 0 0 0 }}} Instructions to produce a dump. First, as root: {{{ echo /tmp/core > /proc/sys/kernel/core_pattern }}} that's needed because otherwise the core file is produced in a temporary folder that stack removes. Then (as non-root, root has privileged access to memory), install stack, and run: {{{ ulimit -c unlimited git clone https://github.com/jiakai0419/snowflake.git stack build --verbose }}} Below is some raw data from the core dump. In short, an initializer for newly allocated data segfaults, and gdb tells that the address it's trying to write (bd->start) to can't be accessed, even though it's lower than mblock_high_watermark so it should have been committed (mmap'ed) by getFreshMBlocks (I don't get getReusableMBlocks in detail, but it also calls `osCommitMemory`, so I guess there's the same invariant). The existence of mblock_high_watermark (beyond other reasons) should confirm this is using USE_LARGE_ADDRESS_SPACE. If this diagnosis is correct, the bug exists since USE_LARGE_ADDRESS_SPACE was introduced in https://github.com/ghc/ghc/commit/0d1a8d09f452977aadef7897aa12a8d41c7a4af0, so it's a regression in 8.0.1. {{{ (gdb) bt #0 initMBlock (mblock=0x225c00000) at rts/sm/BlockAlloc.c:676 #1 alloc_mega_group (mblocks=mblocks@entry=1) at rts/sm/BlockAlloc.c:328 #2 0x00007fe650438d98 in allocGroup (n=1) at rts/sm/BlockAlloc.c:379 #3 allocGroup (n=1) at rts/sm/BlockAlloc.c:336 #4 0x00007fe65043ed55 in allocBlock_sync () at rts/sm/GCUtils.c:38 #5 0x00007fe65043ef7d in alloc_todo_block (ws=ws@entry=0x13196b0, size=size@entry=3) at rts/sm/GCUtils.c:330 #6 0x00007fe65043f13a in todo_block_full (size=size@entry=3, ws=0x13196b0) at rts/sm/GCUtils.c:292 #7 0x00007fe65041baed in alloc_for_copy (gen_no=<optimized out>, size=3) at rts/sm/Evac.c:81 #8 copy_tag (tag=2, gen_no=<optimized out>, size=3, src=0x21b353868, info=<optimized out>, p=0x225b13f10) at rts/sm/Evac.c:99 #9 evacuate1 (p=p@entry=0x225b13f10) at rts/sm/Evac.c:596 #10 0x00007fe65041d65c in scavenge_block1 (bd=0x225b004c0) at rts/sm/Scav.c:570 #11 0x00007fe6504415dc in scavenge_find_work () at rts/sm/Scav.c:2040 #12 scavenge_loop1 () at rts/sm/Scav.c:2103 #13 0x00007fe65043cee2 in scavenge_until_all_done () at rts/sm/GC.c:968 #14 0x00007fe65043d75a in GarbageCollect (collect_gen=collect_gen@entry=1, do_heap_census=do_heap_census@entry=rtsFalse, gc_type=gc_type@entry=2, cap=cap@entry=0x7fe650669a80 <MainCapability>) at rts/sm/GC.c:403 #15 0x00007fe65042ff81 in scheduleDoGC (force_major=rtsFalse, task=0x13228a0, pcap=<optimized out>) at rts/Schedule.c:1652 #16 scheduleDoGC (pcap=<optimized out>, task=0x13228a0, force_major=rtsFalse) at rts/Schedule.c:1433 #17 0x00007fe650430c1a in schedule (initialCapability=initialCapability@entry=0x7fe650669a80 <MainCapability>, task=task@entry=0x13228a0) at rts/Schedule.c:551 #18 0x00007fe650431cf8 in scheduleWaitThread (tso=0x20000b388, ret=ret@entry=0x0, pcap=pcap@entry=0x7ffc4ee22c08) at rts/Schedule.c:2361 #19 0x00007fe65042c528 in rts_evalLazyIO (cap=cap@entry=0x7ffc4ee22c08, p=p@entry=0x7895c0, ret=ret@entry=0x0) at rts/RtsAPI.c:500 #20 0x00007fe65042e3a7 in hs_main (argc=96, argv=0x7ffc4ee22dc8, main_closure=0x7895c0, rts_config=...) at rts/RtsMain.c:64 #21 0x0000000000428414 in main () (gdb) info locals bd = 0x225c00100 block = 0x225c04000 <Address 0x225c04000 out of bounds> (gdb) print/x mblock_high_watermark $11 = 0x225d00000 (gdb) print bd->start Cannot access memory at address 0x225c00100 (gdb) print *bd Cannot access memory at address 0x225c00100 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14606: ghc-exactprint not up to date
by GHC 27 Jan '18

27 Jan '18

#14606: ghc-exactprint not up to date -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have created this ticket to track that ghc-exactprint has not yet been updated, and this should happen before a final release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14719: Caret diagnostics for GADT constructor error message don't span the whole constructor
by GHC 27 Jan '18

27 Jan '18

#14719: Caret diagnostics for GADT constructor error message don't span the whole constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Inspecting the caret diagnostics in the error message for this program: {{{#!hs {-# LANGUAGE GADTs #-} module Bug where data Foo1 where MkFoo1 :: Bool newtype Foo2 where MkFoo2 :: Foo2 }}} {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:3: error: • Data constructor ‘MkFoo1’ returns type ‘Bool’ instead of an instance of its parent type ‘Foo1’ • In the definition of data constructor ‘MkFoo1’ In the data type declaration for ‘Foo1’ | 5 | MkFoo1 :: Bool | ^ Bug.hs:8:3: error: • The constructor of a newtype must have exactly one field but ‘MkFoo2’ has none • In the definition of data constructor ‘MkFoo2’ In the newtype declaration for ‘Foo2’ | 8 | MkFoo2 :: Foo2 | ^ }}} We notice something fishy: the carets don't span the entirey of the constructor! Contrast this with the carets for the error message in this program: {{{#!hs {-# LANGUAGE GADTs #-} module Bug where data Foo where MkFoo, MkFoo :: Foo }}} {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:3: error: Multiple declarations of ‘MkFoo’ Declared at: Bug.hs:5:3 Bug.hs:5:3 | 5 | MkFoo, MkFoo :: Foo | ^^^^^^^^^^^^^^^^^^^ }}} Where the carets span everything that is relevant. I know what is causing this: patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14669: Executable finishing via unhandled exception results in segmentation fault on 32 bit Windows
by GHC 27 Jan '18

27 Jan '18

#14669: Executable finishing via unhandled exception results in segmentation fault on 32 bit Windows --------------------------------------+---------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- It seems that 32 bit Windows GHC version 8.2.1 onwards (I can reproduce it with 8.2.1, 8.2.2 and 8.4.1-alpha, but not with 8.0.2) has some issues in Runtime System related to exception handling. The symptom is that executable exiting via unhandled exception ends with a segmentation fault and non-zero exit code. It would be okay-ish if not for the fact that this bug causes tools like `ghc-pkg` or `hsc2hs` to exit with non-zero exit code when asked for their `--version`. In turn, this breaks cabal-the- executable which interprets non-zero exit code of the `--version` call as a failure and refuses to `configure` further. Why do those executables segfault when invoked with `--version`? It's because they call `exitSuccess` after printing a version, which throws an `ExitSuccess` exception. Thus executables exit with unhandled exception and this bit seems to be faulty. Please see minimalistic example below: {{{ $ cat HW.hs import System.Exit main :: IO () main = do putStrLn "Situation normal" exitWith ExitSuccess $ ghc HW.hs [1 of 1] Compiling Main ( HW.hs, HW.o ) Linking HW.exe ... ./HW.exe Situation normal Segmentation fault $ echo $? 139 }}} If exception is caught then everything's ok. But then it's hard to signal non-zero exit code: {{{ $ cat HWCatch.hs {-# LANGUAGE ScopedTypeVariables #-} import Control.Exception import System.Exit main :: IO () main = do (res :: Either SomeException ()) <- try $ do putStrLn "Situation normal" exitWith ExitSuccess print res $ ghc HWCatch.hs [1 of 1] Compiling Main ( HWCatch.hs, HWCatch.o ) Linking HWCatch.exe ... $ ./HWCatch.exe Situation normal Left ExitSuccess $ echo $? 0 }}} System info: {{{ $ uname -a MINGW64_NT-6.1 box 2.9.0(0.318/5/3) 2017-09-13 23:16 x86_64 Msys $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.2 $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","$topdir/../mingw/bin/gcc.exe") ,("C compiler flags"," -U__i686 -march=i686 -fno-stack-protector") ,("C compiler link flags"," ") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","$topdir/../mingw/bin/gcc.exe") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","$topdir/../mingw/bin/ld.exe") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","$topdir/../mingw/bin/ar.exe") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","$topdir/bin/touchy.exe") ,("dllwrap command","$topdir/../mingw/bin/dllwrap.exe") ,("windres command","$topdir/../mingw/bin/windres.exe") ,("libtool command","") ,("perl command","$topdir/../perl/perl.exe") ,("cross compiling","NO") ,("target os","OSMinGW32") ,("target arch","ArchX86") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("target has RTS linker","YES") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","8.2.2") ,("Project Git commit id","0156a3d815b784510a980621fdcb9c5b23826f1e") ,("Booter version","8.2.1") ,("Stage","2") ,("Build platform","i386-unknown-mingw32") ,("Host platform","i386-unknown-mingw32") ,("Target platform","i386-unknown-mingw32") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p ") ,("RTS expects libdw","NO") ,("Support dynamic-too","NO") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("GHC Profiled","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","C:\\home\\ghc\\ghc-8.2.2-x32\\lib") ,("Global Package DB","C:\\home\\ghc\\ghc-8.2.2-x32\\lib\\package.conf.d") ] $ ghc-pkg --version # This is a sign of the problem GHC package manager version 8.2.2 Segmentation fault $ echo $? 139 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #14644: Improve cmm/assembly for pattern matches with two constants.
by GHC 27 Jan '18

27 Jan '18

#14644: Improve cmm/assembly for pattern matches with two constants. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (CodeGen) | Keywords: Codegen, CMM, | Operating System: Unknown/Multiple Patterns, Pattern Matching | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For a pattern like: {{{ f_test :: Int#->Int# f_test a = case a of 1# -> 33# 7# -> 34# _ -> -1# }}} GHC currently generates code that works best if the default branch is taken most often. Pseudo-Code {{{ if (a >= 8) return -1; else { if (a < 7) { if(a != 1) return -1; else return 33; } else return 34; } }}} CMM: {{{ c1cr: // global if (%MO_S_Ge_W64(R2, 8)) goto c1co; else goto u1cu; u1cu: // global if (%MO_S_Lt_W64(R2, 7)) goto u1cv; else goto c1cq; u1cv: // global if (R2 != 1) goto c1co; else goto c1cp; c1co: // global R1 = (-1); call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c1cp: // global R1 = 33; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c1cq: // global R1 = 34; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }}} Wouldn't the following be better? {{{ if(a == 1) return 33 else if(a == 7) return 34 else return -1 }}} I would expect that to * Improve the cases: * a = 1 * a < 7 * Be the same for: * a = 7 * Be worse for * a > 8 This would be especially nice for the cases where the default branch is raising a pattern match exception. Which is a code path I wouldn't expect to be taken often nor be very performance sensitive. Even if we keep the current logic there is room for improvement. GHC currently creates the following assembly: {{{ _c1cr: cmpq $8,%r14 jge _c1co _u1cu: cmpq $7,%r14 jl _u1cv _c1cq: movl $34,%ebx jmp *(%rbp) _u1cv: cmpq $1,%r14 jne _c1co _c1cp: movl $33,%ebx jmp *(%rbp) _c1co: movq $-1,%rbx jmp *(%rbp) }}} It would be nice if we could remove one comparison at least. {{{ _c1cr: cmpq $7,%r14 jg _c1co _u1cu: ;No longer neccesary cmpq $7,%r14 jl _u1cv _c1cq: movl $34,%ebx jmp *(%rbp) _u1cv: cmpq $1,%r14 jne _c1co _c1cp: movl $33,%ebx jmp *(%rbp) _c1co: movq $-1,%rbx jmp *(%rbp) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #14634: Add print stacktrace to exception handler in runtime system
by GHC 27 Jan '18

27 Jan '18

#14634: Add print stacktrace to exception handler in runtime system -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs main :: IO () main = do someIO putStrLn "hello world" someIO :: IO () someIO = ioError $ IOError Nothing IllegalOperation "a" "b" Nothing Nothing }}} This code prints the following {{{ exception: a: illegal operation (b) }}} I think there is something in the runtime system which takes this exception and prints this text to the terminal. I will call this the "runtime exception handler" (for i don't know any better). {{{#!hs main :: IO () main = do ex <- try someIO :: IO (Either IOException ()) case ex of Left e -> error (show e) Right _ -> putStrLn "hello world" someIO :: IO () someIO = ioError $ IOError Nothing IllegalOperation "a" "b" Nothing Nothing }}} output: {{{ exception: a: illegal operation (b) CallStack (from HasCallStack): error, called at src/Main.hs:10:15 in main:Main }}} Now i use an explicit handler in my code and show the stacktrace with `error`. Could this handler be moved into the RTS so that i can stacktraces with exceptions just like with error? I think this issue is related to, but not the same as https://ghc.haskell.org/trac/ghc/ticket/12096 Because "Attach stacktrace information to SomeException" -- whatever there is being attached right now (with lts-10.2 ghc 8.2.2) is good enough to provide the information, it's just the print option in the handler that seems to be missing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14694: Can't coerce given assumptions
by GHC 26 Jan '18

26 Jan '18

#14694: Can't coerce given assumptions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help Prelude> newtype WF f a = WF (f a) Prelude> import Data.Coerce Prelude Data.Coerce> :set -XFlexibleContexts Prelude Data.Coerce> :t coerce :: Coercible (cat a b) (a -> f b) => cat a b -> (a -> WF f b) <interactive>:1:1: error: • Couldn't match representation of type ‘cat1 a1 b1’ with that of ‘a1 -> WF f1 b1’ arising from a use of ‘coerce’ • In the expression: coerce :: Coercible (cat a b) (a -> f b) => cat a b -> (a -> WF f b) }}} I'm not sure if I've filed this before or if it's even a bug. But we know that `Coercible (a -> f b) (a -> WF f b)` so why doesn't this work? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 26 Jan '18

26 Jan '18

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Is there anything blocking this ticket or does someone just need to implement it? There's nothing particularly blocking. The plan that I wrote about may or may not be the right way to go about this. It's also quite unclear what the right way forward would be if it turned out that implementation hashes are expensive to compute. Regardless, osa1 may be looking into this for Well-Typed client at some point in the next few months. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14526: GHC fails to configure on MacOS if Cuda is installed
by GHC 26 Jan '18

26 Jan '18

#14526: GHC fails to configure on MacOS if Cuda is installed -------------------------------------+------------------------------------- Reporter: nehal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2 Keywords: Cuda | Operating System: MacOS X Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I had the following issue trying to build ghc (indirectly via stack) {{{ [error] Running /usr/bin/make install in directory /Users/nehal/.stack/programs/x86_64-osx/ghc-8.0.2.temp/ghc-8.0.2/ exited with ExitFailure 2 mk/config.mk:521: *** missing separator. Stop. @(Stack/Setup.hs:991:21) 2017-10-16 07:16:01.831719: [error] Error: Error encountered while installing GHC with make install run in /Users/nehal/.stack/programs/x86_64-osx/ghc-8.0.2.temp/ghc-8.0.2/ }}} Here is the line from `mk/config.mk:521`: {{{ 519 WhatGccIsCalled = /usr/bin/gcc 520 GccVersion = 9.0.0 521 8.0 522 ifeq "$(phase)" "0" ... }}} output from gcc: {{{ nehal$ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 9.0.0 (clang-900.0.37) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Found CUDA installation: /usr/local/cuda, version 8.0 }}} It looks like the version detection is getting confused by the cuda installation (and so is thinking the version is something like `"9.0.0\n8.0"`) This could be something for further upstream (e.g. autotools mainainters), but I'm just rebooting my "try to grok Haskell" efforts, so I am going to take the lazy approach and report it here.... Thanks for ghc! (downstream bug report is here: https://github.com/commercialhaskell/stack/issues/1582#issuecomment-3469174… -- two others have hit this in the past month or so) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14726: Add AnnTypeAt to distinguish between '@' for type application
by GHC 26 Jan '18

26 Jan '18

#14726: Add AnnTypeAt to distinguish between '@' for type application -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment all uses of '@' have the same annotation. It simplifies tools to provide a different one for the `@` in visible type application. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14726> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1