GHC issueshttps://gitlab.haskell.org/ghc/ghc//issues20201123T18:41:46Zhttps://gitlab.haskell.org/ghc/ghc//issues/18979Fixing 64bit comparisons on 32bit x8620201123T18:41:46ZAndreas KlebingerFixing 64bit comparisons on 32bit x86We used to do 64bit comparisons like this:
```haskell
ChildCode64 code1 r1_lo < iselExpr64 e1
ChildCode64 code2 r2_lo < iselExpr64 e2
let r1_hi = getHiVRegFromLo r1_lo
r2_hi = getHiVRegFromLo r2_lo
cond = machOpToCond mop
Just cond' = maybeFlipCond cond
TODO: Update CFG for x86
let code = code1 `appOL` code2 `appOL` toOL [
CMP II32 (OpReg r2_hi) (OpReg r1_hi),
JXX cond true,
JXX cond' false,
CMP II32 (OpReg r2_lo) (OpReg r1_lo),
JXX cond true] `appOL` genBranch false
return code
```
This is subtly wrong.
If we have `>=` as comparison and the high bits are equal we immediately jump to true.
But in fact the low bits might still go either way! We actually have to look at them to
make a final decision but we (currently) don't.
!4362 fixes the logic and also rewrites it to make do with a single conditional jump.
Thankfully this codepath as far as I can tell was impossible to hit via codegen for haskell. But compiling custom Cmm could have hit it.We used to do 64bit comparisons like this:
```haskell
ChildCode64 code1 r1_lo < iselExpr64 e1
ChildCode64 code2 r2_lo < iselExpr64 e2
let r1_hi = getHiVRegFromLo r1_lo
r2_hi = getHiVRegFromLo r2_lo
cond = machOpToCond mop
Just cond' = maybeFlipCond cond
TODO: Update CFG for x86
let code = code1 `appOL` code2 `appOL` toOL [
CMP II32 (OpReg r2_hi) (OpReg r1_hi),
JXX cond true,
JXX cond' false,
CMP II32 (OpReg r2_lo) (OpReg r1_lo),
JXX cond true] `appOL` genBranch false
return code
```
This is subtly wrong.
If we have `>=` as comparison and the high bits are equal we immediately jump to true.
But in fact the low bits might still go either way! We actually have to look at them to
make a final decision but we (currently) don't.
!4362 fixes the logic and also rewrites it to make do with a single conditional jump.
Thankfully this codepath as far as I can tell was impossible to hit via codegen for haskell. But compiling custom Cmm could have hit it.9.0.1https://gitlab.haskell.org/ghc/ghc//issues/18960Wrong and redudant `incompletepatterns` warnings20201124T10:03:39ZhekkaidekapusWrong and redudant `incompletepatterns` warnings## Summary
Recent GHC versions emit a wrong `incompletepatterns` warning. Furthermore, for a similar program that deserves to be warned about, those versions are repetitive when emitting the warning. Earlier GHC versions fail to compile programs of this sort.
## Steps to reproduce
### A.hs
```haskell
{# language PatternSynonyms #}
{# options_ghc fforcerecomp Wall #}
module A ( pattern P, foo ) where
pattern P :: a > a
pattern P x = x
{# complete P #}
 {# complete P :: (,) #}  Needed for ghc8.10.2 and prior.
foo :: ()
foo = case () of
P _ > ()
```
### B.hs
```haskell
{# language PatternSynonyms #}
{# options_ghc fforcerecomp Wall #}
module B ( bar ) where
import A ( pattern P )
bar :: ()
bar = case ((), "") of
P ((), "hello") > ()
```
### C.hs
```haskell
{# language LambdaCase, PatternSynonyms #}
{# options_ghc fforcerecomp Wall #}
module C ( woe ) where
import A ( pattern P )
woe :: () > ()
woe = \case
P _ > ()
```
## Expected behavior
### Do not warn
`ghc8.10.2` and `ghc9.1.0.20201115` emit the same incomplete patterns warning when compiling `A.hs`, the missing pattern being `()`. The warning might be unwarranted. On another venue, @sgraf812 said this about that:
> The […] example with a `COMPLETE P :: ()` on the other hand has a different quality!
### Do not repeat the missing pattern
`ghc8.10.2` and `ghc9.1.0.20201115` correctly warn on `B.hs` about incomplete patterns but the warning carries redundant elements as shown below:
```text
warning: [Wincompletepatterns]
Pattern match(es) are nonexhaustive
In a case alternative:
Patterns not matched:
((), [])
((), [])
((), [])
((), [])
...

 bar = case ((), "") of
 ^^^^^^^^^^^^^^^^...
```
Sebastian said:
> [There are] duplicates the origin of which are unclear to me. I have seen that when view patterns were used, but not with just pattern synonyms. But nothing too serious.
>
> I think it’s related to the fact that we record information about the scrutinee (e.g. that it’s `()`) and then don’t store the fact that we matched on `P` to conclude that the match is complete. If you match on a parameter `x :: ()` instead, you don't get any warning.
I added `C.hs` to illustrate that last sentence.
### Check if there is a regression test
While `ghc8.10.2` wrongly warns on `C.hs`, saying that the `()` pattern is not matched, `ghc9.1.0.20201115` does not. `C.hs` would then serve as a regression test, were there nothing else similar.
### Explain why earlier versions can not compile these programs
`ghc8.6.5` and `ghc8.8.4` panic on any of `A.hs`, `B.hs` and `C.hs`.
## Environment
* GHC versions used: `[8.6.5, 8.8.4, 8.10.2, head (9.1.0.20201115)]`
Optional:
* Operating System: GNU/Linux
* System Architecture: x86_64
Cc @inte @exipipiplus1 @expipiplus1## Summary
Recent GHC versions emit a wrong `incompletepatterns` warning. Furthermore, for a similar program that deserves to be warned about, those versions are repetitive when emitting the warning. Earlier GHC versions fail to compile programs of this sort.
## Steps to reproduce
### A.hs
```haskell
{# language PatternSynonyms #}
{# options_ghc fforcerecomp Wall #}
module A ( pattern P, foo ) where
pattern P :: a > a
pattern P x = x
{# complete P #}
 {# complete P :: (,) #}  Needed for ghc8.10.2 and prior.
foo :: ()
foo = case () of
P _ > ()
```
### B.hs
```haskell
{# language PatternSynonyms #}
{# options_ghc fforcerecomp Wall #}
module B ( bar ) where
import A ( pattern P )
bar :: ()
bar = case ((), "") of
P ((), "hello") > ()
```
### C.hs
```haskell
{# language LambdaCase, PatternSynonyms #}
{# options_ghc fforcerecomp Wall #}
module C ( woe ) where
import A ( pattern P )
woe :: () > ()
woe = \case
P _ > ()
```
## Expected behavior
### Do not warn
`ghc8.10.2` and `ghc9.1.0.20201115` emit the same incomplete patterns warning when compiling `A.hs`, the missing pattern being `()`. The warning might be unwarranted. On another venue, @sgraf812 said this about that:
> The […] example with a `COMPLETE P :: ()` on the other hand has a different quality!
### Do not repeat the missing pattern
`ghc8.10.2` and `ghc9.1.0.20201115` correctly warn on `B.hs` about incomplete patterns but the warning carries redundant elements as shown below:
```text
warning: [Wincompletepatterns]
Pattern match(es) are nonexhaustive
In a case alternative:
Patterns not matched:
((), [])
((), [])
((), [])
((), [])
...

 bar = case ((), "") of
 ^^^^^^^^^^^^^^^^...
```
Sebastian said:
> [There are] duplicates the origin of which are unclear to me. I have seen that when view patterns were used, but not with just pattern synonyms. But nothing too serious.
>
> I think it’s related to the fact that we record information about the scrutinee (e.g. that it’s `()`) and then don’t store the fact that we matched on `P` to conclude that the match is complete. If you match on a parameter `x :: ()` instead, you don't get any warning.
I added `C.hs` to illustrate that last sentence.
### Check if there is a regression test
While `ghc8.10.2` wrongly warns on `C.hs`, saying that the `()` pattern is not matched, `ghc9.1.0.20201115` does not. `C.hs` would then serve as a regression test, were there nothing else similar.
### Explain why earlier versions can not compile these programs
`ghc8.6.5` and `ghc8.8.4` panic on any of `A.hs`, `B.hs` and `C.hs`.
## Environment
* GHC versions used: `[8.6.5, 8.8.4, 8.10.2, head (9.1.0.20201115)]`
Optional:
* Operating System: GNU/Linux
* System Architecture: x86_64
Cc @inte @exipipiplus1 @expipiplus19.0.2Sebastian GrafSebastian Grafhttps://gitlab.haskell.org/ghc/ghc//issues/18955GHCi ignores :set fbytecode command20201201T20:26:46ZRoland SennGHCi ignores :set fbytecode command## Summary
When GHCi is started with `fobjectcode`, it ignores a `:set fbytecode` command.
## Steps to reproduce
Take any Haskell module eg Foo.hs:
~~~~
main :: IO ()
main = putStrLn "Hello World"
~~~~
Then set to `bytecode`and load the module:
~~~~
$ ghc interactive fobjectcode
GHCi, version 8.10.1: https://www.haskell.org/ghc/ :? for help
Prelude> :set fbytecode
Prelude> :l Foo.hs
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
Ok, one module loaded.
~~~~
The module is compiled to object code (`Foo.o`)
## Expected behavior
The module should be compiled to interpreted bytecode as in GHC 8.8.4:
~~~~
$ ghc interactive fobjectcode
GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help
Prelude> :set fbytecode
Prelude> :l Foo.hs
[1 of 1] Compiling Main ( Foo.hs, interpreted )
Ok, one module loaded.
~~~~
## Environment
* GHC versions 8.10.1, 8.10.2 and HEAD contain the bug
* GHC versions below eg 8.8.4, 8.8.3 etc work as expected
Optional:
* Operating System: Debian 10
* System Architecture: x86_64## Summary
When GHCi is started with `fobjectcode`, it ignores a `:set fbytecode` command.
## Steps to reproduce
Take any Haskell module eg Foo.hs:
~~~~
main :: IO ()
main = putStrLn "Hello World"
~~~~
Then set to `bytecode`and load the module:
~~~~
$ ghc interactive fobjectcode
GHCi, version 8.10.1: https://www.haskell.org/ghc/ :? for help
Prelude> :set fbytecode
Prelude> :l Foo.hs
[1 of 1] Compiling Main ( Foo.hs, Foo.o )
Ok, one module loaded.
~~~~
The module is compiled to object code (`Foo.o`)
## Expected behavior
The module should be compiled to interpreted bytecode as in GHC 8.8.4:
~~~~
$ ghc interactive fobjectcode
GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help
Prelude> :set fbytecode
Prelude> :l Foo.hs
[1 of 1] Compiling Main ( Foo.hs, interpreted )
Ok, one module loaded.
~~~~
## Environment
* GHC versions 8.10.1, 8.10.2 and HEAD contain the bug
* GHC versions below eg 8.8.4, 8.8.3 etc work as expected
Optional:
* Operating System: Debian 10
* System Architecture: x86_649.0.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc//issues/18912hadrian help doesn't tell which ghcbignum backend is the default.20201103T01:42:14ZOleg Grenrushadrian help doesn't tell which ghcbignum backend is the default.```
bignum[=BIGNUM] Select GHC BigNum backend: native, gmp, ffi.
```
If it's `gmp`, that is somewhat confusing. I'd expect `native`.```
bignum[=BIGNUM] Select GHC BigNum backend: native, gmp, ffi.
```
If it's `gmp`, that is somewhat confusing. I'd expect `native`.9.0.1https://gitlab.haskell.org/ghc/ghc//issues/18855GHC 9.0+ regression in checking program with higherrank kinds20201130T16:42:57ZRyan ScottGHC 9.0+ regression in checking program with higherrank kindsGHC 8.10.2 typechecks the following program:
```hs
{# LANGUAGE AllowAmbiguousTypes #}
{# LANGUAGE DataKinds #}
{# LANGUAGE GADTs #}
{# LANGUAGE PolyKinds #}
{# LANGUAGE RankNTypes #}
{# LANGUAGE StandaloneKindSignatures #}
{# LANGUAGE TypeFamilies #}
{# LANGUAGE TypeApplications #}
{# LANGUAGE TypeOperators #}
{# LANGUAGE UndecidableInstances #}
module Bug where
import Data.Kind
type TyFun :: Type > Type > Type
data TyFun a b
type (~>) :: Type > Type > Type
type a ~> b = TyFun a b > Type
infixr 0 ~>
type Apply :: (a ~> b) > a > b
type family Apply f x
type Nat :: Type
data Nat = Z  S Nat
type Vec :: Type > Nat > Type
data Vec :: Type > Nat > Type where
VNil :: Vec a Z
VCons :: a > Vec a n > Vec a (S n)
type ElimVec :: forall a.
forall (p :: forall (k :: Nat). Vec a k ~> Type)
> forall (n :: Nat).
forall (v :: Vec a n)
> Apply p VNil
> (forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs))
> Apply p v
type family ElimVec p v pVNil pVCons where
forall a (p :: forall (k :: Nat). Vec a k ~> Type)
(pVNil :: Apply p VNil)
(pVCons :: forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs)).
ElimVec p VNil pVNil pVCons = pVNil
forall a (p :: forall (k :: Nat). Vec a k ~> Type)
(pVNil :: Apply p VNil)
(pVCons :: forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs)) l x xs.
ElimVec p (VCons x (xs :: Vec a l)) pVNil pVCons =
Apply (pVCons x xs) (ElimVec @a p @l xs pVNil pVCons)
```
However, GHC 9.0.1alpha1 and HEAD reject it:
```
$ ~/Software/ghc9.0.1alpha1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:40:26: error:
• Couldn't match kind ‘k1’ with ‘m’
Expected kind ‘Vec a k1’, but ‘xs’ has kind ‘Vec a m’
because kind variable ‘m’ would escape its scope
This (rigid, skolem) kind variable is bound by
‘forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs)’
at Bug.hs:(38,18)(40,51)
• In the second argument of ‘Apply’, namely ‘xs’
In the first argument of ‘(~>)’, namely ‘Apply p xs’
In a standalone kind signature for ‘ElimVec’:
forall a.
forall (p :: forall (k :: Nat). Vec a k ~> Type) >
forall (n :: Nat).
forall (v :: Vec a n) >
Apply p VNil
> (forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs))
> Apply p v

40  Apply p xs ~> Apply p (VCons x xs))
 ^^
Bug.hs:41:25: error:
• Couldn't match kind ‘k0’ with ‘n’
Expected kind ‘Vec a k0’, but ‘v’ has kind ‘Vec a n’
because kind variable ‘n’ would escape its scope
This (rigid, skolem) kind variable is bound by
‘forall (n :: Nat).
forall (v :: Vec a n) >
Apply p VNil
> (forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs))
> Apply p v’
at Bug.hs:(35,17)(41,25)
• In the second argument of ‘Apply’, namely ‘v’
In a standalone kind signature for ‘ElimVec’:
forall a.
forall (p :: forall (k :: Nat). Vec a k ~> Type) >
forall (n :: Nat).
forall (v :: Vec a n) >
Apply p VNil
> (forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs))
> Apply p v

41  > Apply p v
 ^
```GHC 8.10.2 typechecks the following program:
```hs
{# LANGUAGE AllowAmbiguousTypes #}
{# LANGUAGE DataKinds #}
{# LANGUAGE GADTs #}
{# LANGUAGE PolyKinds #}
{# LANGUAGE RankNTypes #}
{# LANGUAGE StandaloneKindSignatures #}
{# LANGUAGE TypeFamilies #}
{# LANGUAGE TypeApplications #}
{# LANGUAGE TypeOperators #}
{# LANGUAGE UndecidableInstances #}
module Bug where
import Data.Kind
type TyFun :: Type > Type > Type
data TyFun a b
type (~>) :: Type > Type > Type
type a ~> b = TyFun a b > Type
infixr 0 ~>
type Apply :: (a ~> b) > a > b
type family Apply f x
type Nat :: Type
data Nat = Z  S Nat
type Vec :: Type > Nat > Type
data Vec :: Type > Nat > Type where
VNil :: Vec a Z
VCons :: a > Vec a n > Vec a (S n)
type ElimVec :: forall a.
forall (p :: forall (k :: Nat). Vec a k ~> Type)
> forall (n :: Nat).
forall (v :: Vec a n)
> Apply p VNil
> (forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs))
> Apply p v
type family ElimVec p v pVNil pVCons where
forall a (p :: forall (k :: Nat). Vec a k ~> Type)
(pVNil :: Apply p VNil)
(pVCons :: forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs)).
ElimVec p VNil pVNil pVCons = pVNil
forall a (p :: forall (k :: Nat). Vec a k ~> Type)
(pVNil :: Apply p VNil)
(pVCons :: forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs)) l x xs.
ElimVec p (VCons x (xs :: Vec a l)) pVNil pVCons =
Apply (pVCons x xs) (ElimVec @a p @l xs pVNil pVCons)
```
However, GHC 9.0.1alpha1 and HEAD reject it:
```
$ ~/Software/ghc9.0.1alpha1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:40:26: error:
• Couldn't match kind ‘k1’ with ‘m’
Expected kind ‘Vec a k1’, but ‘xs’ has kind ‘Vec a m’
because kind variable ‘m’ would escape its scope
This (rigid, skolem) kind variable is bound by
‘forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs)’
at Bug.hs:(38,18)(40,51)
• In the second argument of ‘Apply’, namely ‘xs’
In the first argument of ‘(~>)’, namely ‘Apply p xs’
In a standalone kind signature for ‘ElimVec’:
forall a.
forall (p :: forall (k :: Nat). Vec a k ~> Type) >
forall (n :: Nat).
forall (v :: Vec a n) >
Apply p VNil
> (forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs))
> Apply p v

40  Apply p xs ~> Apply p (VCons x xs))
 ^^
Bug.hs:41:25: error:
• Couldn't match kind ‘k0’ with ‘n’
Expected kind ‘Vec a k0’, but ‘v’ has kind ‘Vec a n’
because kind variable ‘n’ would escape its scope
This (rigid, skolem) kind variable is bound by
‘forall (n :: Nat).
forall (v :: Vec a n) >
Apply p VNil
> (forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs))
> Apply p v’
at Bug.hs:(35,17)(41,25)
• In the second argument of ‘Apply’, namely ‘v’
In a standalone kind signature for ‘ElimVec’:
forall a.
forall (p :: forall (k :: Nat). Vec a k ~> Type) >
forall (n :: Nat).
forall (v :: Vec a n) >
Apply p VNil
> (forall (m :: Nat).
forall (x :: a) (xs :: Vec a m) >
Apply p xs ~> Apply p (VCons x xs))
> Apply p v

41  > Apply p v
 ^
```9.0.1https://gitlab.haskell.org/ghc/ghc//issues/18702Remove imported module name list from ghci default prompt20200928T12:02:23ZhdgarroodRemove imported module name list from ghci default prompt## Motivation
The ghci default prompt lists every imported module name. For any mediumtolarge sized project, this is likely to fill the entire terminal window, making the repl almost unusable.
For this reason, I expect most Haskellers have a ~/.ghci file which overrides the prompt so that it doesn’t include the list of module names. I would suggest that it should not be necessary to do this to make the repl usable in mediumtolarge sized projects.
## Proposal
Change the ghci default prompt from “%s> ” to “> “.## Motivation
The ghci default prompt lists every imported module name. For any mediumtolarge sized project, this is likely to fill the entire terminal window, making the repl almost unusable.
For this reason, I expect most Haskellers have a ~/.ghci file which overrides the prompt so that it doesn’t include the list of module names. I would suggest that it should not be necessary to do this to make the repl usable in mediumtolarge sized projects.
## Proposal
Change the ghci default prompt from “%s> ” to “> “.