- ghc-tickets - Haskell.org

Re: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations
by GHC 21 Apr '18

21 Apr '18

#5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): Seems that the solution is to prevent ghc from getting stuck in a loop. Since this is a longstanding bug, i guess it's difficult to fix. Alternatively .. could there perhaps be some detection that it's stuck in a loop and a message what part of the code is causing it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5448#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15075: Sometimes '-optl-optl' used for linker options instead of just '-optl'
by GHC 21 Apr '18

21 Apr '18

#15075: Sometimes '-optl-optl' used for linker options instead of just '-optl' -------------------------------------+------------------------------------- Reporter: jwhite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13091 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The build system does not construct some linker options correctly. For some options it doubles the `-optl` switch, resulting in options like {{{ -optl-optl-Wl,-arch -optl-optl-Wl,x86_64 }}} being passed to GHC, instead of {{{ -optl-Wl,-arch -optl-Wl,x86_64 }}} Root cause: in `rules/distdir-way-opts.mk`, `$1_$2_$3_ALL_LD_OPTS` is constructed with {{{ # Options for passing to gcc for linking $1_$2_$3_ALL_LD_OPTS = \ ... \ $$(foreach o,$$(EXTRA_LD_LINKER_OPTS),-optl-Wl$$(comma)$$o) \ $$(foreach o,$$(CONF_LD_LINKER_OPTS_STAGE$4),-optl-Wl$$(comma)$$o) }}} Which is then used in {{{ # Options for passing to GHC when we use it for linking $1_$2_$3_GHC_LD_OPTS = \ $$(addprefix -optl, $$($1_$2_$3_ALL_LD_OPTS)) \ $$($1_$2_$3_MOST_HC_OPTS) }}} The `-optl` in the foreach invocations in `$1_$2_$3_ALL_LD_OPTS` is not necessary, it is handled already by the addprefix call in `$1_$2_$3_GHC_LD_OPTS`. Example link command line generated by the the build system, showing the problem: {{{ "${HOME}/.stack/programs/x86_64-osx/ghc-7.10.3/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0-cc43d8e06aa74e9c4c0132becc49ee25 -package-id containers-0.5.6.2-68e3ece8a4f91a31e327fe89f8052a53 -package-id directory-1.2.2.0-3b3e1a8d629ccaa6c4588a9bb46bb163 -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id process-1.2.3.0-a1a69425f3f6c11a82785be7baab3b68 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -optl-optl-Wl,-arch -optl-optl-Wl,x86_64 -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0-cc43d8e06aa74e9c4c0132becc49ee25 -package-id containers-0.5.6.2-68e3ece8a4f91a31e327fe89f8052a53 -package-id directory-1.2.2.0-3b3e1a8d629ccaa6c4588a9bb46bb163 -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id process-1.2.3.0-a1a69425f3f6c11a82785be7baab3b68 -XHaskell2010 -no-user-package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Paths_hsc2hs.o }}} It affects all operating systems as far as I can tell, but only seems to cause a build failure on Solaris, see #13091. Looks like this was introduced in commit [https://phabricator.haskell.org/rGHC87c3b1d4395c3d4fc7a5272717c48f3f525da959 87c3b1d], in release 8.2.1, backported to 8.0.2 in commit [https://phabricator.haskell.org/rGHCc5f375c53671130c79713800b13a1da53d070b84 c5f375c]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15041: rnIfaceBndr implementation in RnModIface looks incorrect
by GHC 20 Apr '18

20 Apr '18

#15041: rnIfaceBndr implementation in RnModIface looks incorrect -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ rnIfaceBndr :: Rename IfaceBndr rnIfaceBndr (IfaceIdBndr (fs, ty)) = IfaceIdBndr <$> ((,) fs <$> rnIfaceType ty) rnIfaceBndr (IfaceTvBndr tv_bndr) = IfaceIdBndr <$> rnIfaceTvBndr tv_bndr }}} This is the implementation currently. Notice in the second branch that an `IfaceTvBndr` is converted to an `IfaceIdBndr`. Should it instead be `IfaceTvBndr`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15045: Remove broken top-level shell.nix
by GHC 20 Apr '18

20 Apr '18

#15045: Remove broken top-level shell.nix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 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): Phab:D4599 | Wiki Page: -------------------------------------+------------------------------------- The shell.nix in the root directory is quite broken. The one at hadrian/shell.nix should be used. I'm not even sure how that shell.nix ended up there. I don't remember adding it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do
by GHC 20 Apr '18

20 Apr '18

#10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: | Owner: Artyom.Kazak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: unicode | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs > isMark '\768' True > isAlphaNum '\768' True > (isAlpha '\768', isNumber '\768') (False,False) }}} This behavior comes from this piece in WCsubst.c: {{{ unipred(u_iswalnum,(GENCAT_LT|GENCAT_LU|GENCAT_LL|GENCAT_LM|GENCAT_LO| GENCAT_MC|GENCAT_ME|GENCAT_MN| GENCAT_NO|GENCAT_ND|GENCAT_NL)) }}} I'm not sure what should be done here. Is it a bug with isAlpaNum? Or with isAlpha? How does it correspond to iswalnum's behavior in C++? (And if it's a feature and not a bug, then it should definitely be documented.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10412> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14823: Test profiling/should_run/scc001 fails on Circle CI
by GHC 20 Apr '18

20 Apr '18

#14823: Test profiling/should_run/scc001 fails on Circle CI -------------------------------------+------------------------------------- Reporter: mrkkrp | 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: -------------------------------------+------------------------------------- The test profiling/should_run/scc001 fails on CI: {{{#!hs module Main (main) where main :: IO () main = do print $ f True print $ g 3 print $ h 'a' f :: a -> a f x = x g :: Int -> Int g x = x h :: Char -> Char Just h = Just id }}} And it outputs: {{{ True 3 ghc-stage2: ghc-iserv terminated (-11) }}} instead of {{{ True 3 'a' }}} I guess I'll mark it as an expected failure for now in my PR. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14823> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14698: Cut STM release
by GHC 20 Apr '18

20 Apr '18

#14698: Cut STM release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14706: T11489 fails if run as root
by GHC 20 Apr '18

20 Apr '18

#14706: T11489 fails if run as root -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.5 Integration | 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: -------------------------------------+------------------------------------- The testcase `T11489` tests for #11489 by creating a `.prof` file, removing its write bit, and trying to run a program with profiling enabled. Usually the program would fail with an error message as the RTS can't open the `.prof` file for writing. However, when run as `root` the test succeeds. "What madman would compile GHC as `root`?" you ask? Well, CircleCI runs builds as `root` by default. It seems like running builds under Docker is one way around this, although this seems like a pretty large hammer just to eliminate a single test failure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14704: Spurious cost-centre test failures
by GHC 20 Apr '18

20 Apr '18

#14704: Spurious cost-centre test failures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | 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: -------------------------------------+------------------------------------- CircleCI seems to routinely turn up spurious differences in cost-center profiler tests, {{{patch --- ./profiling/should_run/scc003.run/scc003.prof.sample.normalised 2018-01-22 18:57:35.961616901 +0000 +++ ./profiling/should_run/scc003.run/scc003.prof.normalised 2018-01-22 18:57:35.961616901 +0000 @@ -1,6 +1,6 @@ MAIN MAIN <built-in> 0 f Main scc003.hs:5:1-41 1 -f.(...) Main scc003.hs:5:11-21 1 -fib Main scc003.hs:8:1-50 21891 f.\ Main scc003.hs:5:32-41 1 fib Main scc003.hs:8:1-50 2692537 +f.x' Main scc003.hs:5:11-21 1 +fib Main scc003.hs:8:1-50 21891 --- ./profiling/should_run/scc003.run/scc003.prof.sample.normalised 2018-01-22 18:57:37.321632723 +0000 +++ ./profiling/should_run/scc003.run/scc003.prof.normalised 2018-01-22 18:57:37.321632723 +0000 @@ -1,6 +1,6 @@ MAIN MAIN <built-in> 0 f Main scc003.hs:5:1-41 1 -f.(...) Main scc003.hs:5:11-21 1 -fib Main scc003.hs:8:1-50 21891 f.\ Main scc003.hs:5:32-41 1 fib Main scc003.hs:8:1-50 2692537 +f.x' Main scc003.hs:5:11-21 1 +fib Main scc003.hs:8:1-50 21891 --- ./profiling/should_run/T12962.run/T12962.prof.sample.normalised 2018-01-22 18:57:46.241736499 +0000 +++ ./profiling/should_run/T12962.run/T12962.prof.normalised 2018-01-22 18:57:46.241736499 +0000 @@ -1,4 +1,4 @@ MAIN MAIN <built-in> 0 -blah Main T12962.hs:15:1-22 1 -niz3 Main T12962.hs:12:1-27 1 -foo Main T12962.hs:8:1-21 100 +blah Main T12962.hs:19:1-22 1 +niz3 Main T12962.hs:16:1-27 1 +foo Main T12962.hs:12:1-21 100 --- ./profiling/should_run/T12962.run/T12962.prof.sample.normalised 2018-01-22 18:57:47.209747760 +0000 +++ ./profiling/should_run/T12962.run/T12962.prof.normalised 2018-01-22 18:57:47.209747760 +0000 @@ -1,4 +1,4 @@ MAIN MAIN <built-in> 0 -blah Main T12962.hs:15:1-22 1 -niz3 Main T12962.hs:12:1-27 1 -foo Main T12962.hs:8:1-21 100 +blah Main T12962.hs:19:1-22 1 +niz3 Main T12962.hs:16:1-27 1 +foo Main T12962.hs:12:1-21 100 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15070: postInlineUnconditionally is too eager
by GHC 20 Apr '18

20 Apr '18

#15070: postInlineUnconditionally is too eager -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- In `nofib/spectal/mate`, look at `Move.moveDetailsFor`. In this function we inline a local definition {{{ bd = Board.rmPieceAt c_a25I sq_a2np bd_a25J }}} into two branches of a case (to hopefully avoid allocating it). I think this is `postInlineUnconditionally`. But then it is floated out and has to be laboriously CSE'd again! Maybe `postInlineUnconditionally` should be less aggressive. To quote the comment: {{{ -- So the main target is things like -- let x = f y in -- case v of -- True -> case x of ... -- False -> case x of ... -- This is very important in practice; e.g. wheel-seive1 doubles -- in allocation if you miss this out }}} and {{{ -- Outside a lambda, we want to be reasonably aggressive -- about inlining into multiple branches of case -- e.g. let x = <non-value> -- in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... } -- Inlining can be a big win if C3 is the hot-spot, even if -- the uses in C1, C2 are not 'interesting' -- An example that gets worse if you add int_cxt here is 'clausify' }}} At least for the second of these cases, we could do the float-in/inlining very late in the compilation pipeline, not all the time. For the first, it's not so clear, but worth experimenting. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0