April 2018 - ghc-tickets

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

22 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: #3872 #5400 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #3872 #5400 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5448#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

22 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 sgraf): Actually, this doesn't reproduce anymore, at least not in the way described. For GHC 8.2.1, the original ghcloop.hs elicits the following panic: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying RuleFired Class op funcEq To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 15160 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\simplCore\SimplMonad.hs:199:31 in ghc:SimplMonad }}} That's better than looping forever, although I don't know why it's a panic rather than a warning. Note that it also includes which function was the culprit. I read somewhere that the Simplifier adopted its fuel-based approach in the meantime, which may be the reason this is 'fixed'. The contravariant example doesn't reproduce at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5448#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5400: GHC loops on compiling with optimizations
by GHC 22 Apr '18

22 Apr '18

#5400: GHC loops on compiling with optimizations -------------------------------------+------------------------------------- Reporter: noschinl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Note that the reproduction lacks a `{-# LANGUAGE ConstrainedClassMethods #-}` to compile with GHC 8.2.1 and then compiles flawlessly with -O2. The typical Russel's paradox example from the user's guide just crashes with a panic (similar to #5448): {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone russel To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6361 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\simplCore\SimplMonad.hs:199:31 in ghc:SimplMonad }}} I'd advocate this to be a warning rather than a panic, but otherwise consider the whole issue fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5400#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15074: Possible uninitialised values in ffi64.c
by GHC 21 Apr '18

21 Apr '18

#15074: Possible uninitialised values in ffi64.c --------------------------------------+--------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- Running the clang static analyser when building ghc HEAD throws up 3 possible errors in x86/ffi64.c initialisation / out-of-bounds errors, shown in the attached annotated files showing how they could occur. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

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