- ghc-tickets - Haskell.org

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 05 Feb '18

05 Feb '18

#7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8684 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * related: => #8684 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7353#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #14754: -O1 changes result at runtime
by GHC 05 Feb '18

05 Feb '18

#14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found a program, which works as expected in GHC 8.4.1-alpha1 with `-O0`, but freezes with `-O1`. {{{ module Main where import Debug.Trace main :: IO () main = print (alg 3 1) alg :: Word -> Word -> Word alg a b | traceShow (a, b) False = undefined | c < b = alg b c | c > b = alg c b | otherwise = c where c = a - b }}} {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180118 $ ghc -O0 alg.hs [1 of 1] Compiling Main ( alg.hs, alg.o ) Linking alg ... $ ./alg (3,1) (2,1) 1 $ ghc -O1 alg.hs [1 of 1] Compiling Main ( alg.hs, alg.o ) [Optimisation flags changed] Linking alg ... $ ./alg 2>&1 | head (3,1) (1,2) (2,18446744073709551615) (18446744073709551615,3) ^C }}} For some reason an optimised program chooses a wrong case at the very first invocation of `alg`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14760: Error reporting on obsolete file
by GHC 05 Feb '18

05 Feb '18

#14760: Error reporting on obsolete file -------------------------------------+------------------------------------- Reporter: hsyl20 | 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: -------------------------------------+------------------------------------- I have just had this warning: {{{ Whatever.hs:41:1: warning: [-Wunused-imports] The import of ‘Data.Map’ is redundant except perhaps to import instances from ‘Data.Map’ To import instances alone, use: import Data.Map() | 41 | import Data.Foldable | ^^^^^^^^^^^^^^^^^^^^^ }}} This happens because the source file has been modified during the compilation: GHC shows an excerpt of the new file to report an error in the old file. Could we cache the old file somehow during the compilation to avoid this discrepancy? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #14755: Allow putting SCC annotations on class instance methods
by GHC 04 Feb '18

04 Feb '18

#14755: Allow putting SCC annotations on class instance methods -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Profiling | Version: 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: -------------------------------------+------------------------------------- Perhaps there's a way to do this that I don't know about. Here's a file: {{{ module Test where class C a where foo :: a -> String instance C Int where -- this would be a parse error: {-# SCC foo #-} foo a = show a }}} I want to put a cost center on `foo`. Like mentioned in the comment, doing that in the obvious way is a parse error. Interestingly `-fprof-auto-top` puts a cost center on `foo`. This came up when debugging #14637. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14755> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI
by GHC 04 Feb '18

04 Feb '18

#14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: capi capiffi | Operating System: Unknown/Multiple cpp | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the following simple module {{{#!hs {-# LANGUAGE CApiFFI #-} #include "Bar.hs.inc" module Foo where foreign import capi unsafe "cbits.h foo" c_foo :: Int -> IO () }}} The dependency information produced by `ghc -dep-suffix '' -M Foo.hs` is {{{ # DO NOT DELETE: Beginning of Haskell dependencies Foo.o : Foo.hs # DO NOT DELETE: End of Haskell dependencies }}} And neither mention the include header dependency `cbits.h` nor `Bar.hs.inc`. See also https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_co… #makefile-dependencies -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14757: ghc recompilation check doesn't take into account headers directly included by CApiFFI
by GHC 04 Feb '18

04 Feb '18

#14757: ghc recompilation check doesn't take into account headers directly included by CApiFFI -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: capi capiffi | Operating System: Unknown/Multiple cpp | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Continuing from #14756, given the following simple module {{{#!hs {-# LANGUAGE CPP, CApiFFI #-} #include "Bar.hs.inc" module Foo where foreign import capi unsafe "cbits.h foo" c_foo :: Int -> IO () }}} After having compiled `ghc -c Foo.hs` successfully, and second invocation of `ghc -c Foo.hs` - ...will properly recompile when `Bar.hs.inc` changes (or any of its recursive `#include`s!) (good!) - ...will fail to detect when `cbits.h` changes, and thus claim `compilation IS NOT required` (BAD!) Ideally, we should always run CPP for the CApiFFI-included, in order to detect when any recursive `#include`s inside `cbits.h` change, and use a recorded checksum to detect whether recompilation of the C wrapper (and thus re-linking of the haskell module; which currently forces resynthesizing the object files) is necessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14757> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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