January 2018 - ghc-tickets

[GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix
by GHC 05 Feb '18

05 Feb '18

#8684: hWaitForInput cannot be interrupted by async exceptions on unix ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Timeout.html claims that {{{timeout}}} can interrupt {{{hWaitForInput}}}, but in fact that's false (e.g. mentioned in https://ghc.haskell.org/trac/ghc/ticket/7353#comment:4) {{{ -- import Control.Concurrent import System.IO import System.Timeout main = timeout (1 * 1000000) $ hWaitForInput stdin (5 * 1000) }}} will not be killed after 1 second, but instead wait for the full 5 seconds timeout passed to {{{hWaitForInput}}}. The implementation is {{{ready}}} at http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO- FD.html, where we have two foreign calls: {{{safe fdReady}}} and {{{unsafe unsafe_fdReady}}}. The actual C implementation is at https://github.com/haskell- suite/base/blob/master/cbits/inputReady.c#L16. It uses {{{select}}} on Unix, and does check for {{{EINTR}}}, so I believe that according to http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/ffi.html#ffi- interruptible both foreign calls can be replaced by a single {{{interruptible}}} one. Is that true? If not, it's a documentation bug in {{{timeout}}} at least. Also, does {{{interruptible}}}, apart from allowing the function to be interrupted, behave more like {{{safe}}} or {{{unsafe}}}? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

[GHC] #14738: Investigate performance of CoreTidy
by GHC 05 Feb '18

05 Feb '18

#14738: Investigate performance of CoreTidy -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #11735 #14683 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Considering the following profile output (compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs] {{{ Thu Jan 25 13:11 2018 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/home/tobias/well- typed/devel/ghc/inplace/lib Grammar.hs -ddump-stg -ddump-simpl -ddump-to- file -fforce-recomp total time = 20.99 secs (20989 ticks @ 1000 us, 1 processor) total alloc = 29,250,375,256 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc CoreTidy HscMain compiler/main/HscMain.hs:1253:27-67 24.2 28.5 Stg2Stg HscMain compiler/main/HscMain.hs:1489:12-44 20.3 24.2 simplCast Simplify compiler/simplCore/Simplify.hs:871:62-87 18.7 15.9 tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(494,4)-(556,7) 9.0 6.9 addCoerce-pushCoTyArg Simplify compiler/simplCore/Simplify.hs:(1236,12)-(1237,72) 7.4 6.4 subst_ty TyCoRep compiler/types/TyCoRep.hs:2237:28-32 4.3 5.1 zonkTopDecls TcRnDriver compiler/typecheck/TcRnDriver.hs:(445,16)-(446,43) 1.4 1.1 coercionKind Coercion compiler/types/Coercion.hs:1725:3-7 1.3 3.0 simplExprF1-Lam Simplify compiler/simplCore/Simplify.hs:896:5-39 1.0 1.1 }}} ...the amount of time spent in `CoreTidy` is striking, and should be investigated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14738> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8228: GHC built under Windows does not generate dyn_hi files
by GHC 04 Feb '18

04 Feb '18

#8228: GHC built under Windows does not generate dyn_hi files ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work at all Unknown/Multiple | Test Case: cabal01 Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I found cabal01 failing with: {{{ =====> cabal01(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory cabal01 VANILLA=--enable-library- vanilla PROF=--disable-l ibrary-profiling DYN=--enable-shared </dev/null >cabal01.run.stdout 2>cabal01.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: Creating library file: dist\build\libHStest-1.0-ghc7.7.20130904.dll.a setup.exe: Error: Could not find module: A with any suffix: ["dyn_hi"] in the search path: ["dist\\build"] make[2]: *** [cabal01] Error 1 }}} but I bet some of the other failures are due to this. Indeed, in dist/build, there are no dyn_hi files When I look more closely at the commands being run, I see: {{{ bash.exe-3.1$ c:/Users/ezyang/Dev/ghc-validate/inplace/bin/ghc-stage2.exe --make -fbuilding-ca bal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir dist/build -odi r dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -I dist/build/autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -package- name test-1.0 -hide-all- packages -no-user-package-db -package-db local.db -package-db dist/pac kage.conf.inplace -package-id base-4.7.0.0-inplace -XHaskell98 -XForeignFunctionInterface A B. A -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db [1 of 2] Compiling B.A ( B\A.hs, dist\build\B\A.o ) [2 of 2] Compiling A ( A.hs, dist\build\A.o ) }}} which should result in dyn_hi files but does not. I haven't traced it any further yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers
by GHC 04 Feb '18

04 Feb '18

#14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #12537 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The comments in `compiler/prelude/primops.txt.pp` for both operations say "... Implies a full memory barrier." The implementation does not issue any barriers as exemplified by the 32-bit variants as can be seen in the excerpts from `libraries/ghc- prim/cbits/atomic.c`. {{{#!c StgWord hs_atomicread32(StgWord x) { return *(volatile StgWord32 *) x; } }}} and {{{#!c void hs_atomicwrite32(StgWord x, StgWord val) { *(volatile StgWord32 *) x = (StgWord32) val; } }}} The native code generator for X86/amd64 and the LLVM backend do not generate calls to these functions but generate the necessary barrier (`mfence`) directly and thus are not affected by this issue. There are no gcc `__sync_*` intrinsics for the two operations. The new `__atomic_*` intrinisics have the required operations but require gcc 4.7 or later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum#
by GHC 04 Feb '18

04 Feb '18

#14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I originally observed this panic in [https://travis-ci.org/haskell-compat /deriving-compat/jobs/329948624#L804 this Travis build]. The panic can be reduced to this file: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeFamilies #-} module Bug where import GHC.Base (getTag) import GHC.Exts (Int(..), tagToEnum#) data family TyFamilyEnum data instance TyFamilyEnum = TyFamilyEnum1 | TyFamilyEnum2 | TyFamilyEnum3 suc :: TyFamilyEnum -> TyFamilyEnum suc a_aaf8 = case getTag a_aaf8 of a_aaf9 -> if 2 == I# a_aaf9 then error "succ{TyFamilyEnum}: tried to take `succ' of last tag in enumeration" else case I# a_aaf9 + 1 of I# i_aafa -> tagToEnum# i_aafa :: TyFamilyEnum }}} In GHC 8.2.2, compiling this with optimization works fine. But in GHC 8.4.1-alpha, it panics: {{{ $ /opt/ghc/8.4.1/bin/ghc -fforce-recomp -O1 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.0.20171222 for x86_64-unknown-linux): Prelude.!!: index too large }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11706: Increase precedence of statements (if-then-else, case-of, do)
by GHC 03 Feb '18

03 Feb '18

#11706: Increase precedence of statements (if-then-else, case-of, do) -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: ⊥ Component: Compiler | Version: (Parser) | 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: -------------------------------------+------------------------------------- Warning: Skip to the {{{TL; DR}}}, and maybe the {{{How it works}}} section; You don't want to read this. (I've warned you.) == The problem == We do it all the time: Writing that one dollar sign just before our expressions, just because Haskell can't parse it: {{{#!hs f x = g $ if x then {- ... -} else {- ... -} f x = g $ case x of {- ... -} f x = g $ do {- ... -} }}} However, we programmers are lazy and want to type as few characters as possible. Think about the precious characters we would save if we could write code this way: {{{#!hs f x = g if x then {- ... -} else {- ... -} f x = g case x of {- ... -} f x = g do {- ... -} }}} Wow, our productivity just shot up by a whopping 6%! However, this code looks ugly, noone would ever write this... Right? There has to be some way to catagorize this feature with others people would never use... == Pragmas to the rescue! == The {{{LANGUAGE}}} pragma! Of course! We can add a syntactic extension to enable above syntax! But how should we name it... {{{InlineStatements}}}? {{{InfixStatements}}}? {{{ParenthesizedStatements}}}? {{{IncreasedStatementPrecedence}}}? {{{StatementsWithoutParenthesis}}}? I don't know. I am [1] not the parents who might one day give birth to this feature. I am merely the one who conceptualized it. [1] (probably, unless this request remains unnoticed for another 20 years or so) == How it works == * Implicit parenthesis will be put around ''all'' statements, according to the following rules: 1. Parenthesis will be opened at the start of the statement. 2. Parenthesis will be closed at the end of the statement. The end of the statement is determined by 1. The curly brackets around the statement, or; 2. The indentation of the statement Basically, these are the rule Haskell already uses. Sorry if this is obvious, but some people seemed to get confused, so here's some examples: === (Correct) Examples === Examples are in the form: {{{#!hs implicitParenthesis -- New syntax explicitParenthesis -- Old syntax }}} Call {{{idM :: Monad m => m a -> m a}}} as {{{idM :: IO String -> IO String}}}. {{{#!hs idM do putStrLn "What's my name?" getLine idM (do { putStrLn "What's my name?"; getLine; }) }}} Create function {{{whatsMyName :: Maybe String -> String}}}. {{{#!hs whatsMyName x = id case x of Just name = "My name is " ++ name Nothing = "What's my name?" whatsMyName x = id (case x of { Just name = "My name is " ++ name; Nothing = "What's my name?"; }) }}} Another example using {{{let}}} and {{{if-then-else}}}. {{{#!hs main = putStrLn (++) "I've been tryna work it out... The square root of 69 is 8 something, right? " let eight_something = 8.306623862918075 in if sqrt 69 == eight_something then "Yeah" else "Oh na na" main = putStrLn ((++) "I've been tryna work it out... The square root of 69 is 8 something, right? " (let eight_something = 8.306623862918075 in (if sqrt 69 == eight_something then "Yeah" else "Oh na na")) }}} === Incorrect examples === {{{#!hs f do putStrLn "This won't work..." True f (do { putStrLn "This won't work..."; True; }) }}} {{{#!hs f do putStrLn "This won't work..." True -- Indented by extra space f (do { putStrLn "This won't work..."; True; }) }}} == TL; DR == What there is: {{{#!hs main = when $ do putStrLn "Parenthesis..." main = when True (do putStrLn "Parenthesis...") }}} What I want: {{{#!hs when (doBlocksNeedParenthesis) do putStrLn "This code is invalid." when (doBlocksNeedParenthesis) $ do putStrLn "This code is valid." when (doBlocksNeedParenthesis) (do putStrLn "This code is valid aswell.") when (thisIsImplemented) do putStrLn "These are all equal" when (thisIsImplemented) (do putStrLn "These are all equal") when (thisIsImplemented) $ do putStrLn "These are all equal" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14631: GHC 8.2.2 crashes when building the haskell-gi sample code
by GHC 02 Feb '18

02 Feb '18

#14631: GHC 8.2.2 crashes when building the haskell-gi sample code -------------------------------------+------------------------------------- Reporter: muscar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.2.2 crashes while building the haskell-gi sample code in a new project created with stack (see the attached project). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14736: unknown opcode in interpretBCO doesn't cause process termination in some circumstances
by GHC 02 Feb '18

02 Feb '18

#14736: unknown opcode in interpretBCO doesn't cause process termination in some circumstances ----------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- As part of my work on #14675, I ended up in a situation where `rts/Interpreter.c:interpretBCO` falls into its default case, which just does this: {{{#!c barf("interpretBCO: unknown or unimplemented opcode %d", (int)(bci & 0xFF)); }}} Which is fine. In the program from #14675, we are not processing the annotations with an external interpreter, the same runtime is compiling some module and running some code for the annotations, if my understanding is correct. And that process should therefore terminate. Except that it doesn't, not right away! And the example that uses the GHC API to load some simple module with an annotation just happily proceeds until it segfaults because `interpretBCO` didn't run to completion, probably therefore not pushing a suitable closure address or two somewhere or something along those lines. The expected behaviour here would be that the program crashes with the "unknown opcode" error message from above. So far the problem from #14675 has only been reproduced on ubuntu 16.04 with 8.4.1 alpha1, however I suspect that the bug I'm describing -- the program not terminating when we call `barf` while running code that we will splice in some module that we are compiling using the GHC API -- is independent of the particular distro or maybe even OS? Not sure, I haven't looked into that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures
by GHC 02 Feb '18

02 Feb '18

#14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures -------------------------------------+------------------------------------- Reporter: mitchty | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Noticed while trying to build ghc 8.2.1, and ghc 8.2.2 on alpine linux armhf as well as nixos. Opening this ticket as I previously thought this was just some quirk of the alpine linux port but managed to find out from dhess on irc that nixos hits the same issue for both as well on armv7l arches. What happens. 8.2.1 logs, 8.2.2 has similar or the same issues, I was just double checking that 8.2.1 has the same problems. {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packag es -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/vendor/attoparsec-0.13.1. 0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build /haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP- DIN_GHC_TREE -optP-include -optPutils/haddock/dis t/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -package- id filepath-1.4.1.2 -package-id directory-1. 3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.2 -package-id ghc-boot-8.2.1 -package-id ghc-8.2.1 -package-id bytestring-0.10.8.2 -package-i d transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsop ts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir uti ls/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-api/src/Haddock/Backends/Hyperlink er/Types.hs -o utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packag es -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/vendor/attoparsec-0.13.1. 0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build /haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP- DIN_GHC_TREE -optP-include -optPutils/haddock/dis t/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -package- id filepath-1.4.1.2 -package-id directory-1. 3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.0.2 -package-id ghc-boot-8.2.1 -package-id ghc-8.2.1 -package-id bytestring-0.10.8.2 -package-i d transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsop ts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir uti ls/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-library/src/Documentation/Haddock/ Types.hs -o utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Segmentation fault (core dumped) make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/ResponseFile.dyn_o] Segmentation fault (core dumped) make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Segmentation fault (core dumpe d) make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Segmentation fault (core dumped) $ gdb /home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc- stage2 src/ghc-8.2.1/core GNU gdb (GDB) 7.12.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "armv6-alpine-linux-musleabihf". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc- stage2...done. [New LWP 24905] [New LWP 24908] bt Core was generated by `/home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc-stage2 -B/ho'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0019d628 in stg_IND_STATIC_info () [Current thread is 1 (LWP 24905)] (gdb) bt #0 0x0019d628 in stg_IND_STATIC_info () #1 0xaffcfe1c in stg_newAlignedPinnedByteArrayzh$def () from /home/build/aports/community/ghc/src/ghc-8.2.1/rts/dist/build /libHSrts_thr-ghc8.2.1.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) }}} I've been poking around but i'm a bit out of my depth here in understanding the ghc rts here and debugging it as well. But its curious that only the stage2 compiler is having issues being built and not stage0 or stage1. If needed/desired I can provide access/login to this box for debugging but its sloooow, ~29 hours to do a build to this point. But I'm willing to help move things along, ghc on arm is one of the main reaons for the port to alpine linux and 8.0.2 works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13511: ApplicativeDo incorrectly requiring Monad
by GHC 02 Feb '18

02 Feb '18

#13511: ApplicativeDo incorrectly requiring Monad -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- We ran into this bug in production, this is a simplified reproduction. The following program will not type check, requiring an unnecessary Monad instance: {{{ {-# LANGUAGE ApplicativeDo, GeneralizedNewtypeDeriving #-} import Data.Functor.Identity import Data.Monoid newtype A x = A (Identity x) deriving (Functor, Applicative) shouldWork :: A () shouldWork = do a <- pure () b <- pure () let ab = a <> b return ab }}} {{{ pepe:~/code/snippets$ ghci ApplicativeDoBug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ApplicativeDoBug.hs, interpreted ) ApplicativeDoBug.hs:10:14: error: • No instance for (Monad A) arising from a do statement • In the expression: do { a <- pure (); b <- pure (); let ab = a <> b; return ab } In an equation for ‘shouldWork’: shouldWork = do { a <- pure (); b <- pure (); let ab = ...; return ab } Failed, modules loaded: none. }}} There is a simple workaround, which worked for us in production: {{{ workaround :: A () workaround = do a <- pure () b <- pure () return $ let ab = a <> b in ab }}} I asked in #ghc and it seems this is not yet fixed in HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10