- ghc-tickets - Haskell.org

[GHC] #15945: Unable to compile GHC from source on OpenBSD (-CURRENT)
by GHC 29 Dec '18

29 Dec '18

#15945: Unable to compile GHC from source on OpenBSD (-CURRENT) -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (make) | Keywords: clang | Operating System: OpenBSD Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am running the following script to build GHC from sources (ghc-8.6.2-src.tar.xz) on OpenBSD (-CURRENT): {{{ #! /bin/sh set -e BUILD_DIR=/usr/local/tmp-build-ghc export AUTOCONF_VERSION=2.69 export AUTOMAKE_VERSION=1.16 if [ ! -n "$1" ]; then echo "ERROR: Provide path for ghc source." exit 1 fi echo "Extracting ghc source files from ${1} to ${BUILD_DIR} ..." mkdir -p $BUILD_DIR cd $BUILD_DIR xzcat $1 | tar xvf - GHC_DIR=`ls | grep ghc` cd $GHC_DIR echo "Cleaning up OpenBSD-incompatible commands..." find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' echo "Building GHC... " export CC=/usr/bin/clang ./boot ./configure --with-iconv-libraries=/usr/local/lib \ --with-iconv-includes=/usr/local/include \ --with-gmp-libraries=/usr/local/lib \ --with-gmp-includes=/usr/local/include \ --with-ffi-libraries=/usr/local/lib \ --with-ffi-includes=/usr/local/include \ --with-system-libffi gmake }}} I will file a separate bug report for the **ln** incompatibility with the unsupported **-v** flag. When compiling GHC, I get the following error: {{{ ... "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc- Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc- Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc- Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc- Iincludes/dist-derivedconstants/header -optc-Iincludes/dist- ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing -optc-fno-common -optc- Irts/dist/build/./autogen -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit- frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-ffunction-sections -optc-fdata-sections -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/RtsSymbols.c -o rts/dist/build/RtsSymbols.o rts/RtsSymbols.c:990:1: error: error: redefinition of '_DYNAMIC' as different kind of symbol | 990 | RTS_OPENBSD_ONLY_SYMBOLS | ^ RTS_OPENBSD_ONLY_SYMBOLS ^ rts/RtsSymbols.c:283:22: error: note: expanded from macro 'RTS_OPENBSD_ONLY_SYMBOLS' SymE_NeedsProto(_DYNAMIC) ^ | 283 | SymE_NeedsProto(_DYNAMIC) | ^ /usr/include/sys/exec_elf.h:765:17: error: note: previous definition is here | 765 | extern Elf_Dyn _DYNAMIC[]; | ^ extern Elf_Dyn _DYNAMIC[]; ^ 1 error generated. `clang' failed in phase `C Compiler'. (Exit code: 1) gmake[1]: *** [rts/ghc.mk:315: rts/dist/build/RtsSymbols.o] Error 1 gmake: *** [Makefile:127: all] Error 2 }}} Any suggestions appreciated. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15945> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16098: More efficient implementation plan for primops with continuation arguments
by GHC 28 Dec '18

28 Dec '18

#16098: More efficient implementation plan for primops with continuation arguments -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14375 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Original idea from #14375: in some of the primops that take continuation arguments we currently have to allocate the continuations but sometimes we immediately enter one of these continuations. One example is {{{ maskAsyncExceptions# :: (State# RealWorld -> (# State# RealWorld, a #)) -> (State# RealWorld -> (# State# RealWorld, a #)) }}} which is implemented as {{{ stg_maskAsyncExceptionszh /* explicit stack */ { /* Args: R1 :: IO a */ STK_CHK_P_LL (WDS(1)/* worst case */, stg_maskAsyncExceptionszh, R1); if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_BLOCKEX) == 0) { /* avoid growing the stack unnecessarily */ if (Sp(0) == stg_maskAsyncExceptionszh_ret_info) { Sp_adj(1); } else { Sp_adj(-1); Sp(0) = stg_unmaskAsyncExceptionszh_ret_info; } } else { if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_INTERRUPTIBLE) == 0) { Sp_adj(-1); Sp(0) = stg_maskUninterruptiblezh_ret_info; } } StgTSO_flags(CurrentTSO) = %lobits32( TO_W_(StgTSO_flags(CurrentTSO)) | TSO_BLOCKEX | TSO_INTERRUPTIBLE); TICK_UNKNOWN_CALL(); TICK_SLOW_CALL_fast_v(); jump stg_ap_v_fast [R1]; } }}} Here we want to have better compilation for `maskAsyncExceptions# c` where we don't allocate for `c`. There are some ideas in ticket:14375#comment:1, but the idea was later superseded by ticket:14375#comment:7, which suggests - Making continuation arguments explicit in STG so that an `maskAsyncExceptions#` would now look like this in STG: `maskAsyncExceptions# (\s. e)`. - Then in the code gen generating stack frame push (plus `StgTSO` updates) and then emitting code for `e` directly. (I don't understand if `bind s:=s2` part in the comment is necessary?) Some primops take more than one callback, e.g. {{{ catch# :: (State# RealWorld -> (# State# RealWorld, a #) ) -> (b -> State# RealWorld -> (# State# RealWorld, a #) ) -> State# RealWorld -> (# State# RealWorld, a #) }}} Which is implemented as {{{ stg_catchzh ( P_ io, /* :: IO a */ P_ handler /* :: Exception -> IO a */ ) { W_ exceptions_blocked; STK_CHK_GEN(); exceptions_blocked = TO_W_(StgTSO_flags(CurrentTSO)) & (TSO_BLOCKEX | TSO_INTERRUPTIBLE); TICK_CATCHF_PUSHED(); /* Apply R1 to the realworld token */ TICK_UNKNOWN_CALL(); TICK_SLOW_CALL_fast_v(); jump stg_ap_v_fast (CATCH_FRAME_FIELDS(,,stg_catch_frame_info, CCCS, 0, exceptions_blocked, handler)) (io); } }}} For this example ticket:14375#comment:7 suggest using join points for the `handler` argument (and using the non-allocating callback scheme for the `io` argument), but I suggest we focus on more efficient implementation of callbacks that are immediately entered, and worry about the join point stuff in another ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15921: Foldable.maximumBy uses counter-intuitive ordering
by GHC 28 Dec '18

28 Dec '18

#15921: Foldable.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: List | Operating System: Unknown/Multiple maximumBy minimumBy | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs Data.List.maximumBy (Data.Ord.comparing snd) [(0, 1), (3, 2), (2, 2), (1, 1)] }}} What do you expect the outcome to be? All Haskell-programmers I know that I asked this question, would answer, based on their intuition, `(3, 2)`. However, this is not the behaviour that `Data.List.maximumBy` currently has: Instead, `(2, 2)` (the ''last'' occurrence of a 'maximum' element) is kept. Furthermore, this behaviour is different from the one used by `Data.List.minimumBy`. I would therefore like to request: - If its behaviour is unintentionally different from `minimumBy`, alter the implementation to match it. - If its behaviour is intentionally the opposite, this should be specified in the documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16034: Quadratic GC slowdown using RTS debug
by GHC 28 Dec '18

28 Dec '18

#16034: Quadratic GC slowdown using RTS debug -------------------------------------+------------------------------------- Reporter: remyo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.3 System | 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: -------------------------------------+------------------------------------- Hello, Under some conditions of heavy heap usage, I seem to experience a quadratic slowdown due to GC using the debugging RTS only (for example, in the context of ticky profiling). I have been able to reproduce it using the following program (depending on the aeson library): {{{#!hs import Data.Aeson (eitherDecode, Value) import qualified Data.ByteString.Lazy as BL import Data.Maybe (catMaybes) import System.Directory (listDirectory) import System.FilePath ( (</>) ) main :: IO() main = do let dir = "data" files <- listDirectory dir values <- catMaybes <$> mapM (readF dir) files print $ length values readF :: FilePath -> FilePath -> IO (Maybe Value) readF dir fp = do print (dir </> fp) blob <- BL.readFile (dir </> fp) case eitherDecode blob of Left _ -> return Nothing Right v -> return $ Just $! v }}} Here data is a directory filled with (identical) JSON files. See the attached Python script for the proposed dataset. {{{ $ ghc -O -dynamic -o main Main.hs $ ./main +RTS -s ... 18,583,045,600 bytes allocated in the heap 6,334,338,280 bytes copied during GC 975,763,072 bytes maximum residency (14 sample(s)) 6,986,112 bytes maximum slop 930 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 17727 colls, 0 par 2.596s 2.597s 0.0001s 0.0006s Gen 1 14 colls, 0 par 2.422s 2.422s 0.1730s 0.7947s INIT time 0.000s ( 0.000s elapsed) MUT time 3.349s ( 3.351s elapsed) GC time 5.019s ( 5.020s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 8.368s ( 8.371s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 5,548,968,539 bytes per MUT second Productivity 40.0% of total user, 40.0% of total elapsed }}} {{{ $ ghc -O -dynamic -debug -o main.debug Main.hs $ ./main +RTS -s ... 18,583,045,600 bytes allocated in the heap 6,334,332,424 bytes copied during GC 975,763,072 bytes maximum residency (14 sample(s)) 6,986,112 bytes maximum slop 930 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 17727 colls, 0 par 172.941s 172.959s 0.0098s 0.0459s Gen 1 14 colls, 0 par 9.532s 9.532s 0.6808s 3.2061s INIT time 0.000s ( 0.000s elapsed) MUT time 5.020s ( 5.017s elapsed) GC time 182.473s (182.491s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 187.492s (187.508s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 3,701,999,827 bytes per MUT second Productivity 2.7% of total user, 2.7% of total elapsed }}} In debug mode, the runtime is almost quadratic: {{{ Nb of files Duration (non-debug) Duration (debug) 100 0.8s 2.8s 200 1.6s 8.8s 400 3.2s 27.6s 1000 8.2s 168.9s }}} The problem can be seen with either GHC 8.6.3 (here on Archlinux, with aeson 1.4.2.0) but was also observed using GHC 8.4.4, with static binaries, using "stack". I was able to reproduce with both threaded and non-threaded mode. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler.
by GHC 28 Dec '18

28 Dec '18

#14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- For simple code such as `if a > 10 then foo else bar` it can make a big difference if we jump on `a > 10` or `a <= 10`. We already tracked the likelyhood of such conditionals for stack/heap checks in Cmm. I recently updated the native codegen on X86 to take this information into account where available and in one edge case this improved execution time from 1.7s to 1.5s! Having this info available for other cases like bound checking (assume valid) or partial pattern matches (assume no match failure) should be a small win for most programs and hopefully a big one for a few of them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] Batch modify: #14617, #14610, #14604, #14602, #14579
by GHC 28 Dec '18

28 Dec '18

Batch modification to #14617, #14610, #14604, #14602, #14579 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=14617%2C14610%2C14604%2C14602%2C14…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #14765, #14729, #14727, #14684, #14673
by GHC 28 Dec '18

28 Dec '18

Batch modification to #14765, #14729, #14727, #14684, #14673 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=14765%2C14729%2C14727%2C14684%2C14…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #14765, #14729, #14727, #14684, #14673
by GHC 28 Dec '18

28 Dec '18

Batch modification to #14765, #14729, #14727, #14684, #14673 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=14765%2C14729%2C14727%2C14684%2C14…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #15028, #15020, #15011, #15010, #14911, #14909, ...
by GHC 28 Dec '18

28 Dec '18

Batch modification to #15028, #15020, #15011, #15010, #14911, #14909, #14870, #14839, #14838, #14823, #14816, #14806 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=15028%2C15020%2C15011%2C15010%2C14…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #14530, #14512, #14509, #14502, #14469, #14412, ...
by GHC 28 Dec '18

28 Dec '18

Batch modification to #14530, #14512, #14509, #14502, #14469, #14412, #14405, #14401, #14400, #14337, #14331, #14319, #14283, #14261, #14252, #14242, #14214, #14165, #14164, #14155, #14111, #14040, #14030, #14023, #14003 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=14530%2C14512%2C14509%2C14502%2C14…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0