May 2018 - ghc-tickets

[GHC] #14416: CI with CircleCI
by GHC 16 Jun '18

16 Jun '18

#14416: CI with CircleCI -------------------------------------+------------------------------------- Reporter: chak | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Build System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: | ContinuousIntegration -------------------------------------+------------------------------------- Merging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14123: Figure out invariants surrounding ticks in Core
by GHC 16 Jun '18

16 Jun '18

#14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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 the past we have had a number of issues stemming from ticks breaking various Core analyses in GHC, * #13233: a tick separates a levity-polymorphic tycon (e.g. an unboxed tuple tycon) from its levity arguments, resulting in a `typePrimRep` panic. * ticket:8472#comment:22: a tick wraps a primitive string literal, causing `CoreToStg` to fail to notice it is a string resulting in a panic * #14122: Another literal string issue which I have yet to debug but seems very likely to be tick-related. We have merged a stop-gap solution/hack (f5b275a239d2554c4da0b7621211642bf3b10650) to the `ghc-8.2` branch however need a more principled solution in the long-term (e.g. before 8.4). We will need to start by defining precisely where ticks are allowed and add appropriate logic to CoreLint to verify that this invariant is upheld. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal`
by GHC 16 Jun '18

16 Jun '18

#14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- When GHC 8.2.1 compiles this code with `-O`: {{{#!hs {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} module NatVal where import Data.Proxy import GHC.TypeLits foo = natVal $ Proxy @0 }}} it produces the following Core: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} NatVal.foo1 :: Integer NatVal.foo1 = 0 -- RHS size: {terms: 41, types: 18, coercions: 0, joins: 0/0} foo :: Integer foo = case NatVal.foo1 of wild_a1iV { integer-gmp-1.0.1.0:GHC.Integer.Type.S# i#_a2ke -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# i#_a2ke 0#) of { False -> case GHC.Natural.underflowError of wild2_00 { }; True -> integer-gmp-1.0.1.0:GHC.Integer.Type.wordToInteger (GHC.Prim.int2Word# i#_a2ke) }; integer-gmp-1.0.1.0:GHC.Integer.Type.Jp# dt_a2km -> case GHC.Prim.uncheckedIShiftRL# (GHC.Prim.sizeofByteArray# dt_a2km) 3# of { __DEFAULT -> case GHC.Prim.sizeofByteArray# dt_a2km of { __DEFAULT -> wild_a1iV; 0# -> case GHC.Natural.underflowError of wild4_00 { } }; 1# -> case GHC.Prim.indexWordArray# dt_a2km 0# of wild2_a2kq { __DEFAULT -> integer-gmp-1.0.1.0:GHC.Integer.Type.wordToInteger wild2_a2kq } }; integer-gmp-1.0.1.0:GHC.Integer.Type.Jn# ipv_a2kt -> case GHC.Natural.underflowError of wild1_00 { } } }}} while GHC-8.0.1 does the right thing: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0} foo :: Integer foo = 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances.
by GHC 15 Jun '18

15 Jun '18

#13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- Yes I know, `0` and `"B"` are not technically type constructors, but it's as close as you can get for the kinds Nat and Symbol. Test cases: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures #-} import GHC.TypeLits (Nat, Symbol) class A (n::Nat) instance A 0 class B (s::Symbol) instance B "B" }}} Result: {{{ A.hs:6:10: error: • Illegal instance declaration for ‘A 0’ (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) • In the instance declaration for ‘A 0’ A.hs:9:10: error: • Illegal instance declaration for ‘B "B"’ (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) • In the instance declaration for ‘B "B"’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13833> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14747: DisambiguateRecordFields fails for PatternSynonyms
by GHC 15 Jun '18

15 Jun '18

#14747: DisambiguateRecordFields fails for PatternSynonyms -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #11283 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module A where pattern S{x} = [x] }}} {{{#!hs {-# LANGUAGE PatternSynonyms, DisambiguateRecordFields #-} module B where import A pattern T{x} = [x] e = S { x = 42 } }}} Compiling module B fails with `Ambiguous occurrence ‘x’` in the definition of `e`. In principle, `DisambiguateRecordFields` should select the field belonging to the `S` "data constructor". However, the current implementation of this works by identifying the parent type constructor, which doesn't exist for a pattern synonym. This continues to fail if `T` is replaced by a data type with a field `x`. If `S` is replaced by a data type, however, it starts working. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14747> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD
by GHC 15 Jun '18

15 Jun '18

#15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Build System | Version: 8.4.1 Keywords: dtrace | Operating System: FreeBSD Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.4.1 enables DTrace probes on FreeBSD. This currently causes issues with the using such compilers as a bootstrap compiler for building GHC itself due to the way linking of the RTS is handled. I didn't encounter any issues regarding daily use on FreeBSD but suspect it might cause problems with user defined hooks. Current workaround is to build a version of GHC with DTrace disabled and use that as a bootstrap compiler. A patch has been merged into HEAD. I've already tested it in combination with 8.4.2-rc1 and it worked fine. https://phabricator.haskell.org/rGHC4b831c27926d643b0b6fad82c1e946d05cde8645 I have an idea on how to fix this but haven't had the time to put that plan into action. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15040> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13900: Core lint in BuildFlavour=perf-llvm
by GHC 15 Jun '18

15 Jun '18

#13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 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 found the following Core lint failure when compiling c9977385dca9536f18374242f713b1048a38dec5 with `BuildFlavour=perf-llvm`, {{{ "inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -fllvm -Wall -hide-all-packages -i -ighc/. -ighc/stage2/build -Ighc/stage2/build -ighc/stage2/build/ghc/autogen -Ighc/stage2/build/ghc/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/ghc/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id array-0.5.1.2 -package-id bytestring-0.10.8.2 -package-id directory-1.3.0.2 -package-id process-1.6.0.0 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.3 -package-id ghc-8.3 -package-id unix-2.7.2.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id ghci-8.3 -package-id haskeline-0.7.4.0 -package-id time-1.8.0.1 -package- id transformers-0.5.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O2 -dcore-lint -dcmm-lint -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -c ghc/./GHCi/UI/Tags.hs -o ghc/stage2/build/GHCi/UI/Tags.dyn_o *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of $wgo_XtpE :: [Name] -> Session -> State# RealWorld -> (# State# RealWorld, [[TagInfo]] #)] Rule "SC:$wgo0": lhs type: (# State# RealWorld, [[TagInfo]] #) rhs type: (# State# RealWorld, [Maybe TyThing] #) *** Offending Program *** (see attached) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15024: ghc: please switch to llvm-toolchain-6.0
by GHC 15 Jun '18

15 Jun '18

#15024: ghc: please switch to llvm-toolchain-6.0 -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- As said, is it possible to switch to llvm-toolchain-6.0 for the next 8.6.x release? I don't know if it is already ongoing, but I would like to track progresses to understand when to switch in Debian, or cherry-pick patches and rebase on top of 8.4.1 (currently in experimental, using 5.9) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15184: T4442 fails on i386
by GHC 15 Jun '18

15 Jun '18

#15184: T4442 fails on i386 --------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- {{{ omer@i386-chroot:~/ghc/testsuite/tests/primops/should_run$ ~/ghc/inplace/bin/ghc-stage2 T4442.hs [1 of 1] Compiling Main ( T4442.hs, T4442.o ) T4442.hs:135:14: error: Not in scope: data constructor `I64#' | 135 | (\arr i (I64# a) s -> write arr i a s) | ^^^^ }}} Looking at the code, it uses `Int` on 64-bit, but `Int64` on i386, probably to use 64-bit integers on both platforms. I think we can just use `Int64` on both platforms and get rid of the CPP to avoid further breakage in the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14600: Work out why Hadrian builds routinely fail
by GHC 15 Jun '18

15 Jun '18

#14600: Work out why Hadrian builds routinely fail -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 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: -------------------------------------+------------------------------------- Currently Hadrian builds inexplicably and non-deterministically fail on CircleCI. They fail with, {{{ | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_l.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_debug.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_debug.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_l.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_p.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffidebug_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_debug_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffil_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_l_-ghc8.5.20171218.so | Successfully built custom library 'libffi' Too long with no output (exceeded 10m0s) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2