GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:13:36Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/1427GHC fails to compile with gcc 4.2.02019-07-07T19:13:36Zismail@pardus.org.trGHC fails to compile with gcc 4.2.0From Debian [bug \#428060](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428060), I can also reproduce this with Pardus Linux (gcc 4.2.0) :
`
Trying to build ghc6 with gcc-4.2 as gcc results in:
...
-------------------------------...From Debian [bug \#428060](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428060), I can also reproduce this with Pardus Linux (gcc 4.2.0) :
`
Trying to build ghc6 with gcc-4.2 as gcc results in:
...
------------------------------------------------------------------------
== /usr/bin/make all -wr -f Makefile;
in /var/tmp/build/stuff/ghc6-6.6.1/libraries/base
------------------------------------------------------------------------
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-"#include" HsBase.h -funbox-strict-fields -package-name base-2.1.1
-O -Rghc-timing -fgenerics -fgenerics -split-objs -c
Data/Typeable.hs-boot -o Data/Typeable.o-boot -ohi
Data/Typeable.hi-boot
<<ghc: 15624572 bytes, 5 GCs, 98272/98272 avg/max bytes residency (1
samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.11 MUT (1.09
elapsed), 0.02 GC (0.04 elapsed) :ghc>>
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-"#include" HsBase.h -funbox-strict-fields -package-name base-2.1.1
-O -Rghc-timing -fgenerics -fgenerics -split-objs -c
Data/Dynamic.hs-boot -o Data/Dynamic.o-boot -ohi Data/Dynamic.hi-boot
<<ghc: 11938524 bytes, 4 GCs, 98224/98224 avg/max bytes residency (1
samples), 18M in use, 0.01 INIT (0.00 elapsed), 0.06 MUT (0.36
elapsed), 0.03 GC (0.03 elapsed) :ghc>>
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-"#include" HsBase.h -funbox-strict-fields -package-name base-2.1.1
-O -Rghc-timing -fgenerics -fgenerics -split-objs -c
GHC/Err.lhs-boot -o GHC/Err.o-boot -ohi GHC/Err.hi-boot
<<ghc: 18035540 bytes, 5 GCs, 99228/99228 avg/max bytes residency (1
samples), 18M in use, 0.01 INIT (0.00 elapsed), 0.12 MUT (0.59
elapsed), 0.03 GC (0.03 elapsed) :ghc>>
../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-"#include" HsBase.h -funbox-strict-fields -package-name base-2.1.1
-O -Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/Base.lhs
-o GHC/Base.o -ohi GHC/Base.hi
GHC/Base_split/.o::Base(void):(.data+0x0): multiple definition of
`base_GHCziBase_zeze_closure'
GHC/Base_split/Base__1.o:(.data+0x0): first defined here
GHC/Base_split/.o::Base(void): In function `base_GHCziBase_zeze_info':
ghc14747_0.hc:(.text+0xc): multiple definition of `base_GHCziBase_zeze_info'
GHC/Base_split/Base__1.o:ghc14747_0.hc:(.text+0xc): first defined here
GHC/Base_split/Base__3.o:(.data+0x0): multiple definition of
`base_GHCziBase_zeze_closure'
GHC/Base_split/Base__1.o:(.data+0x0): first defined here
GHC/Base_split/Base__3.o: In function `base_GHCziBase_zeze_info':
ghc14747_0.hc:(.text+0xc): multiple definition of `base_GHCziBase_zeze_info'
GHC/Base_split/Base__1.o:ghc14747_0.hc:(.text+0xc): first defined here
[more of the same elided]
The reason is that the split markers (__STG_SPLIT_MARKER in
includes/Stg.h) that the ghc compiler inserts into
C code are emitted differently into assembler with gcc-4.1 and gcc-4.2.
The latter seems to kind of delay them, so part of actual assembler code
is now before the first emitted split marker, which then is erroneously
taken as prologue material and copied into every split assembler source
resulting in lots of duplicate definitions.
As a temporary workaround, a build with --with-gcc=gcc-4.1 succeeds.
`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC fails to compile with gcc 4.2.0","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"From Debian [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428060 bug #428060], I can also reproduce this with Pardus Linux (gcc 4.2.0) :\r\n\r\n {{{\r\n\r\nTrying to build ghc6 with gcc-4.2 as gcc results in:\r\n\r\n...\r\n------------------------------------------------------------------------\r\n== /usr/bin/make all -wr -f Makefile;\r\nin /var/tmp/build/stuff/ghc6-6.6.1/libraries/base\r\n------------------------------------------------------------------------\r\n../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude\r\n-\"#include\" HsBase.h -funbox-strict-fields -package-name base-2.1.1\r\n-O -Rghc-timing -fgenerics -fgenerics -split-objs -c\r\nData/Typeable.hs-boot -o Data/Typeable.o-boot -ohi\r\nData/Typeable.hi-boot\r\n<<ghc: 15624572 bytes, 5 GCs, 98272/98272 avg/max bytes residency (1\r\nsamples), 18M in use, 0.00 INIT (0.00 elapsed), 0.11 MUT (1.09\r\nelapsed), 0.02 GC (0.04 elapsed) :ghc>>\r\n../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude\r\n-\"#include\" HsBase.h -funbox-strict-fields -package-name base-2.1.1\r\n-O -Rghc-timing -fgenerics -fgenerics -split-objs -c\r\nData/Dynamic.hs-boot -o Data/Dynamic.o-boot -ohi Data/Dynamic.hi-boot\r\n<<ghc: 11938524 bytes, 4 GCs, 98224/98224 avg/max bytes residency (1\r\nsamples), 18M in use, 0.01 INIT (0.00 elapsed), 0.06 MUT (0.36\r\nelapsed), 0.03 GC (0.03 elapsed) :ghc>>\r\n../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude\r\n-\"#include\" HsBase.h -funbox-strict-fields -package-name base-2.1.1\r\n-O -Rghc-timing -fgenerics -fgenerics -split-objs -c\r\nGHC/Err.lhs-boot -o GHC/Err.o-boot -ohi GHC/Err.hi-boot\r\n<<ghc: 18035540 bytes, 5 GCs, 99228/99228 avg/max bytes residency (1\r\nsamples), 18M in use, 0.01 INIT (0.00 elapsed), 0.12 MUT (0.59\r\nelapsed), 0.03 GC (0.03 elapsed) :ghc>>\r\n../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude\r\n-\"#include\" HsBase.h -funbox-strict-fields -package-name base-2.1.1\r\n-O -Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/Base.lhs\r\n-o GHC/Base.o -ohi GHC/Base.hi\r\nGHC/Base_split/.o::Base(void):(.data+0x0): multiple definition of\r\n`base_GHCziBase_zeze_closure'\r\nGHC/Base_split/Base__1.o:(.data+0x0): first defined here\r\nGHC/Base_split/.o::Base(void): In function `base_GHCziBase_zeze_info':\r\nghc14747_0.hc:(.text+0xc): multiple definition of `base_GHCziBase_zeze_info'\r\nGHC/Base_split/Base__1.o:ghc14747_0.hc:(.text+0xc): first defined here\r\nGHC/Base_split/Base__3.o:(.data+0x0): multiple definition of\r\n`base_GHCziBase_zeze_closure'\r\nGHC/Base_split/Base__1.o:(.data+0x0): first defined here\r\nGHC/Base_split/Base__3.o: In function `base_GHCziBase_zeze_info':\r\nghc14747_0.hc:(.text+0xc): multiple definition of `base_GHCziBase_zeze_info'\r\nGHC/Base_split/Base__1.o:ghc14747_0.hc:(.text+0xc): first defined here\r\n[more of the same elided]\r\n\r\nThe reason is that the split markers (__STG_SPLIT_MARKER in\r\nincludes/Stg.h) that the ghc compiler inserts into\r\nC code are emitted differently into assembler with gcc-4.1 and gcc-4.2.\r\nThe latter seems to kind of delay them, so part of actual assembler code\r\nis now before the first emitted split marker, which then is erroneously\r\ntaken as prologue material and copied into every split assembler source\r\nresulting in lots of duplicate definitions.\r\n\r\nAs a temporary workaround, a build with --with-gcc=gcc-4.1 succeeds.\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1428Mutually recursive modules2019-07-07T19:13:36Ziampure@gmail.comMutually recursive modulesI would like to have mutually recursive modules, without creating special files. In my experience, some types(for example) are naturally mutually recursive. As someone said on the mailing lists:
You can \*program\* in Haskell and you ca...I would like to have mutually recursive modules, without creating special files. In my experience, some types(for example) are naturally mutually recursive. As someone said on the mailing lists:
You can \*program\* in Haskell and you can program \*in Haskell\*. In short, the user should concentrate on writing the program and not on artificial complexities imposed on by the implementation.
Mutually recursive modules are a solved problem, since there are other systems that can do this. They might have a cost associated with them, but I cannot imagine it to be significant in any interesting program.
Since mutually recursive modules are already in Haskell98, any user should be able to expect that the "most popular" compiler for Haskell fully supports them. It's 2007, not 1998.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Mutually recursive modules","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":["modules","mutually","recursive"],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"FeatureRequest","description":"I would like to have mutually recursive modules, without creating special files. In my experience, some types(for example) are naturally mutually recursive. As someone said on the mailing lists: \r\n\r\nYou can *program* in Haskell and you can program *in Haskell*. In short, the user should concentrate on writing the program and not on artificial complexities imposed on by the implementation. \r\n\r\nMutually recursive modules are a solved problem, since there are other systems that can do this. They might have a cost associated with them, but I cannot imagine it to be significant in any interesting program. \r\n\r\nSince mutually recursive modules are already in Haskell98, any user should be able to expect that the \"most popular\" compiler for Haskell fully supports them. It's 2007, not 1998.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1429:list gets confused by bang patterns in .lhs files2019-07-07T19:13:35Zmnislaih:list gets confused by bang patterns in .lhs filesA bang pattern in a .lhs file confuses :list by one lineA bang pattern in a .lhs file confuses :list by one line6.8.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1430getC: Type signature needed when existential types are used but not in the ty...2019-07-07T19:13:35ZIan Lynagh <igloo@earth.li>getC: Type signature needed when existential types are used but not in the type signatureThis module:
```
{-# OPTIONS -fglasgow-exts #-}
module Q where
import Data.Typeable
data ExTypeable = forall a. Typeable a => ExTypeable a
-- unExTypeable :: Typeable h => ExTypeable -> Maybe h
unExTypeable (ExTypeable a) = cast a
``...This module:
```
{-# OPTIONS -fglasgow-exts #-}
module Q where
import Data.Typeable
data ExTypeable = forall a. Typeable a => ExTypeable a
-- unExTypeable :: Typeable h => ExTypeable -> Maybe h
unExTypeable (ExTypeable a) = cast a
```
with the type signature commented out gives this in the HEAD:
```
q.hs:10:30:
Could not deduce (Typeable b) from the context (Typeable a)
arising from a use of `cast' at q.hs:10:30-35
Possible fix:
add (Typeable b) to the context of the constructor `ExTypeable'
In the expression: cast a
In the definition of `unExTypeable':
unExTypeable (ExTypeable a) = cast a
```
It works in 6.6.
It's part of the getC test.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | getC |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"getC: Type signature needed when existential types are used but not in the type signature","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"getC","architecture":"Unknown","cc":[""],"type":"Bug","description":"This module:\r\n{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\nmodule Q where\r\n\r\nimport Data.Typeable\r\n\r\ndata ExTypeable = forall a. Typeable a => ExTypeable a\r\n\r\n-- unExTypeable :: Typeable h => ExTypeable -> Maybe h\r\nunExTypeable (ExTypeable a) = cast a\r\n}}}\r\nwith the type signature commented out gives this in the HEAD:\r\n{{{\r\nq.hs:10:30:\r\n Could not deduce (Typeable b) from the context (Typeable a)\r\n arising from a use of `cast' at q.hs:10:30-35\r\n Possible fix:\r\n add (Typeable b) to the context of the constructor `ExTypeable'\r\n In the expression: cast a\r\n In the definition of `unExTypeable':\r\n unExTypeable (ExTypeable a) = cast a\r\n}}}\r\nIt works in 6.6.\r\n\r\nIt's part of the getC test.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1431libraries: configure argument containing whitespace not passed correctly to S...2019-07-07T19:13:35Zgreenrdlibraries: configure argument containing whitespace not passed correctly to SetupNote the incorrect quotation when passing through CFLAGS in the command executed by make below, and the resulting error. This is due to the use of addprefix in libraries/Makefile.
```
... snip ...
rm -f -f stamp/configure.library.*.base...Note the incorrect quotation when passing through CFLAGS in the command executed by make below, and the resulting error. This is due to the use of addprefix in libraries/Makefile.
```
... snip ...
rm -f -f stamp/configure.library.*.base base/unbuildable
( cd base && setup/Setup configure \
--enable-library-profiling --enable-split-objs \
--prefix='$topdir' \
--datadir='$prefix/share' \
--libsubdir='$compiler/lib/$pkgid' \
--with-compiler=../../compiler/ghc-inplace \
--with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \
--with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \
--with-ld=/usr/bin/ld \
--datasubdir=ghc \
--haddock-args="--use-contents=../index.html \
--use-index=../doc-index.html" \
--configure-option='--prefix=/usr' --configure-option='--host=x86_64-pc-linux-gnu' --configure-option='--mandir=/usr/share/man' --configure-option='--infodir=/usr/share/info' --configure-option='--datadir=/usr/share' --configure-option='--sysconfdir=/etc' --configure-option='--localstatedir=/var/lib' --configure-option='--libdir=/usr/lib64' --configure-option='--build=x86_64-pc-linux-gnu' --configure-option='build_alias=x86_64-pc-linux-gnu' --configure-option='host_alias=x86_64-pc-linux-gnu' --configure-option='CFLAGS=-O2 --configure-option=-pipe --configure-option=-ggdb --configure-option=-march=opteron' --configure-option='CPPFLAGS=' \
--configure-option=--with-cc=gcc ) \
&& touch stamp/configure.library.build-profiling-splitting.base || touch base/unbuildable
Setup: Warning: Unknown field 'nhc98-options'
checking for x86_64-pc-linux-gnu-gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
... snip ...
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"libraries: configure argument containing whitespace not passed correctly to Setup","status":"New","operating_system":"Multiple","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Note the incorrect quotation when passing through CFLAGS in the command executed by make below, and the resulting error. This is due to the use of addprefix in libraries/Makefile.\r\n\r\n{{{\r\n... snip ...\r\nrm -f -f stamp/configure.library.*.base base/unbuildable\r\n( cd base && setup/Setup configure \\\r\n --enable-library-profiling --enable-split-objs \\\r\n --prefix='$topdir' \\\r\n --datadir='$prefix/share' \\\r\n --libsubdir='$compiler/lib/$pkgid' \\\r\n --with-compiler=../../compiler/ghc-inplace \\\r\n --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \\\r\n --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \\\r\n --with-ld=/usr/bin/ld \\\r\n --datasubdir=ghc \\\r\n --haddock-args=\"--use-contents=../index.html \\\r\n --use-index=../doc-index.html\" \\\r\n --configure-option='--prefix=/usr' --configure-option='--host=x86_64-pc-linux-gnu' --configure-option='--mandir=/usr/share/man' --configure-option='--infodir=/usr/share/info' --configure-option='--datadir=/usr/share' --configure-option='--sysconfdir=/etc' --configure-option='--localstatedir=/var/lib' --configure-option='--libdir=/usr/lib64' --configure-option='--build=x86_64-pc-linux-gnu' --configure-option='build_alias=x86_64-pc-linux-gnu' --configure-option='host_alias=x86_64-pc-linux-gnu' --configure-option='CFLAGS=-O2 --configure-option=-pipe --configure-option=-ggdb --configure-option=-march=opteron' --configure-option='CPPFLAGS=' \\\r\n --configure-option=--with-cc=gcc ) \\\r\n && touch stamp/configure.library.build-profiling-splitting.base || touch base/unbuildable\r\nSetup: Warning: Unknown field 'nhc98-options'\r\nchecking for x86_64-pc-linux-gnu-gcc... gcc\r\nchecking for C compiler default output file name...\r\nconfigure: error: C compiler cannot create executables\r\n... snip ...\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1432Poor type error messages (refer to generated code rather than the higher leve...2019-07-07T19:13:35ZIan Lynagh <igloo@earth.li>Poor type error messages (refer to generated code rather than the higher level problem)With this module:
```
module Foo where
data Foo a = Foo
data Bar a = Bar (Foo a)
deriving Eq
```
the HEAD says:
```
q.hs:5:0:
Non type-variable argument in the constraint: Eq (Foo a)
(Use -fglasgow-exts to permit this)
...With this module:
```
module Foo where
data Foo a = Foo
data Bar a = Bar (Foo a)
deriving Eq
```
the HEAD says:
```
q.hs:5:0:
Non type-variable argument in the constraint: Eq (Foo a)
(Use -fglasgow-exts to permit this)
In the context: (Eq (Foo a))
While checking the context of an instance declaration
In the derived instance: (Eq (Foo a)) => Eq (Bar a)
```
which isn't really the error message that we want, as it's refering to the
generated instance.
1. 6 gives the much better:
```
q.hs:5:5:
No instance for (Eq (Foo a))
arising from the 'deriving' clause of a data type declaration
at q.hs:5:5
Possible fix: add an instance declaration for (Eq (Foo a))
When deriving the instance for `Eq (Bar a)'
```
This example is from tcfail046; tcfail169 is similar and tcfail118 is also a related issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Poor type error messages (refer to generated code rather than the higher level problem)","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"With this module:\r\n{{{\r\nmodule Foo where\r\n\r\ndata Foo a = Foo\r\ndata Bar a = Bar (Foo a)\r\n deriving Eq\r\n}}}\r\nthe HEAD says:\r\n{{{\r\nq.hs:5:0:\r\n Non type-variable argument in the constraint: Eq (Foo a)\r\n (Use -fglasgow-exts to permit this)\r\n In the context: (Eq (Foo a))\r\n While checking the context of an instance declaration\r\n In the derived instance: (Eq (Foo a)) => Eq (Bar a)\r\n}}}\r\nwhich isn't really the error message that we want, as it's refering to the\r\ngenerated instance.\r\n\r\n6.6 gives the much better:\r\n{{{\r\nq.hs:5:5:\r\n No instance for (Eq (Foo a))\r\n arising from the 'deriving' clause of a data type declaration\r\n at q.hs:5:5\r\n Possible fix: add an instance declaration for (Eq (Foo a))\r\n When deriving the instance for `Eq (Bar a)'\r\n}}}\r\n\r\nThis example is from tcfail046; tcfail169 is similar and tcfail118 is also a related issue.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1433Difference in strictness/unpackability between Word64 and Word32 (on a 32 bit...2019-07-07T19:13:34ZStefan O'Rear <stefanor@cox.net>Difference in strictness/unpackability between Word64 and Word32 (on a 32 bit machine)In the attached file, mix1 and mix2 both worker/wrapper, but mix2 incompletely so. Changing between Word64 and Word32 is the only difference. GHC 6.7.20070612 on a 32-bit x86 with -O2. This is a stripped-down version of the underperformi...In the attached file, mix1 and mix2 both worker/wrapper, but mix2 incompletely so. Changing between Word64 and Word32 is the only difference. GHC 6.7.20070612 on a 32-bit x86 with -O2. This is a stripped-down version of the underperforming(?) code in \<http://haskell.org/pipermail/haskell-cafe/2007-June/026985.html\>.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | drtomc@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Difference in strictness/unpackability between Word64 and Word32 (on a 32 bit machine)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["drtomc@gmail.com"],"type":"Bug","description":"In the attached file, mix1 and mix2 both worker/wrapper, but mix2 incompletely so. Changing between Word64 and Word32 is the only difference. GHC 6.7.20070612 on a 32-bit x86 with -O2. This is a stripped-down version of the underperforming(?) code in <http://haskell.org/pipermail/haskell-cafe/2007-June/026985.html>.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1434Missing RULEs for truncate2019-07-07T19:13:33Zghc@orangesquash.org.ukMissing RULEs for truncateI found that the rounding functions from RealFrac class are considerably
slower than the low level functions from GHC.Float. This is really a
problem for me when doing signal processing, since for writing to a common
audio file format or...I found that the rounding functions from RealFrac class are considerably
slower than the low level functions from GHC.Float. This is really a
problem for me when doing signal processing, since for writing to a common
audio file format or listening to a signal data has to be converted from
`Double` to `Int16`.
```
$ ghci +RTS -M256m -c30 -RTS
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> :set +s
Prelude> sum $ map round [0.1,0.32..100000] :: Int
1252489463
(6.50 secs, 241894764 bytes)
Prelude> sum $ map floor [0.1,0.32..100000] :: Int
1252262188
(6.07 secs, 240099200 bytes)
Prelude> sum $ map ceiling [0.1,0.32..100000] :: Int
1252716734
(6.13 secs, 243795404 bytes)
Prelude> sum $ map truncate [0.1,0.32..100000] :: Int
1252262188
(6.76 secs, 234572324 bytes)
Prelude> sum $ map GHC.Float.double2Int [0.1,0.32..100000] :: Int
1252262188
(1.38 secs, 66137016 bytes)
```
As far as I can judge, `double2Int` does the same like `truncate`. Instead
of using the methods from RealFrac I could simply use `double2Int` but I
consider this a work-around.
In GHC-6.6.1 these examples end with a stack overflow, but if I shorten
the list, the time relations remain the same.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ghc-bug@henning-thielemann.de |
| Operating system | Linux |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Slow conversion from Double to Int","status":"New","operating_system":"Linux","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["ghc-bug@henning-thielemann.de"],"type":"Bug","description":"I found that the rounding functions from RealFrac class are considerably\r\nslower than the low level functions from GHC.Float. This is really a\r\nproblem for me when doing signal processing, since for writing to a common\r\naudio file format or listening to a signal data has to be converted from\r\n{{{Double}}} to {{{Int16}}}.\r\n\r\n\r\n{{{\r\n$ ghci +RTS -M256m -c30 -RTS\r\n\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base-1.0 ... linking ... done.\r\nPrelude> :set +s\r\nPrelude> sum $ map round [0.1,0.32..100000] :: Int\r\n1252489463\r\n(6.50 secs, 241894764 bytes)\r\nPrelude> sum $ map floor [0.1,0.32..100000] :: Int\r\n1252262188\r\n(6.07 secs, 240099200 bytes)\r\nPrelude> sum $ map ceiling [0.1,0.32..100000] :: Int\r\n1252716734\r\n(6.13 secs, 243795404 bytes)\r\nPrelude> sum $ map truncate [0.1,0.32..100000] :: Int\r\n1252262188\r\n(6.76 secs, 234572324 bytes)\r\nPrelude> sum $ map GHC.Float.double2Int [0.1,0.32..100000] :: Int\r\n1252262188\r\n(1.38 secs, 66137016 bytes)\r\n}}}\r\n\r\nAs far as I can judge, {{{double2Int}}} does the same like {{{truncate}}}. Instead\r\nof using the methods from RealFrac I could simply use {{{double2Int}}} but I\r\nconsider this a work-around.\r\n\r\nIn GHC-6.6.1 these examples end with a stack overflow, but if I shorten\r\nthe list, the time relations remain the same.","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1435"Naughty" register error in Cmm2019-07-07T19:13:33ZMichael D. Adams"Naughty" register error in CmmWhen experimenting with Cmm code, I found the following bug/trap.
This Cmm code,
```
foo {
bits8 x;
x = 5;
bits8[12] = x;
R1 = x;
jump bar;
}
```
causes the following error
```
/tmp/ghc6613_0/ghc6613_0.s: Assemble...When experimenting with Cmm code, I found the following bug/trap.
This Cmm code,
```
foo {
bits8 x;
x = 5;
bits8[12] = x;
R1 = x;
jump bar;
}
```
causes the following error
```
/tmp/ghc6613_0/ghc6613_0.s: Assembler messages:
/tmp/ghc6613_0/ghc6613_0.s:7:0:
Error: junk `naughty I386 byte register' after expression
```
The assembly that is produced is:
```
.text
.align 4,0x90
.globl foo
foo:
movl $5,%eax
movb %al,12
movb %al,very naughty I386 byte register
jmp bar
.section .note.GNU-stack,"",@progbits
.ident "GHC 6.7.20070612"
```
Note the "very naughty I386 byte register" in there.
I am not sure whether this kind of Cmm can be generated from Haskell code.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"Naughty\" register error in Cmm","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When experimenting with Cmm code, I found the following bug/trap.\r\n\r\nThis Cmm code,\r\n{{{\r\nfoo {\r\n bits8 x;\r\n x = 5;\r\n bits8[12] = x;\r\n R1 = x;\r\n jump bar;\r\n}\r\n}}}\r\ncauses the following error\r\n{{{\r\n/tmp/ghc6613_0/ghc6613_0.s: Assembler messages:\r\n\r\n/tmp/ghc6613_0/ghc6613_0.s:7:0:\r\n Error: junk `naughty I386 byte register' after expression\r\n}}}\r\n\r\nThe assembly that is produced is:\r\n{{{\r\n.text\r\n .align 4,0x90\r\n.globl foo\r\nfoo:\r\n movl $5,%eax\r\n movb %al,12\r\n movb %al,very naughty I386 byte register\r\n jmp bar\r\n\r\n.section .note.GNU-stack,\"\",@progbits\r\n.ident \"GHC 6.7.20070612\"\r\n}}}\r\n\r\nNote the \"very naughty I386 byte register\" in there.\r\n\r\nI am not sure whether this kind of Cmm can be generated from Haskell code.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1439ghci silently changes for the worse when already-compiled object code is found2019-07-07T19:13:32ZIsaac Dupreeghci silently changes for the worse when already-compiled object code is found`ghci MyModule`
If it's been compiled (i.e., up-to-date MyModule.{hi,o} files exist), then I can't get to the non-exported symbols in MyModule, in ghci. Removing the .{hi,o} works around it. (I haven't tried it in any 6.7, sorry, I have...`ghci MyModule`
If it's been compiled (i.e., up-to-date MyModule.{hi,o} files exist), then I can't get to the non-exported symbols in MyModule, in ghci. Removing the .{hi,o} works around it. (I haven't tried it in any 6.7, sorry, I have the feeling it might be different there, but I don't have a 6.7 stage2)
If it's not easy/desirable to change the behavior, at least say something like "Warning: loading object code, you won't be able to see non-exported symbols in this module. To avoid this, (do x)"
`-fforce-recomp` recompiles imported modules for ghci too (an inefficient workaround). Not sure about the new `-fbyte-code`, maybe it could be relevant here?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ghci silently changes for the worse when already-compiled object code is found","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{ghci MyModule}}}\r\n\r\nIf it's been compiled (i.e., up-to-date MyModule.{hi,o} files exist), then I can't get to the non-exported symbols in MyModule, in ghci. Removing the .{hi,o} works around it. (I haven't tried it in any 6.7, sorry, I have the feeling it might be different there, but I don't have a 6.7 stage2)\r\n\r\nIf it's not easy/desirable to change the behavior, at least say something like \"Warning: loading object code, you won't be able to see non-exported symbols in this module. To avoid this, (do x)\"\r\n\r\n`-fforce-recomp` recompiles imported modules for ghci too (an inefficient workaround). Not sure about the new `-fbyte-code`, maybe it could be relevant here?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1440Make clean doesn't2019-07-07T19:13:32ZguestMake clean doesn'tTyping 'make clean' at the top level only does this:
```
rm -f -rf autom4te.cache
rm -f *.CKP *.ln *.BAK *.bak .*.bak *.o core a.out errs ,* *.a .emacs_* tags TAGS *.ind *.ilg *.idx *.idx-prev *.aux *.aux-prev *.dvi *.log *.toc *.lo...Typing 'make clean' at the top level only does this:
```
rm -f -rf autom4te.cache
rm -f *.CKP *.ln *.BAK *.bak .*.bak *.o core a.out errs ,* *.a .emacs_* tags TAGS *.ind *.ilg *.idx *.idx-prev *.aux *.aux-prev *.dvi *.log *.toc *.lot *.lof *.blg *.cb *_stub.c *_stub.h *.raw_s *.a.list a.out ./*.hi hc-files-to-go *-hc.tar.gz
```
It used to actually clean.
> -- Lennart
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart.augustsson@credit-suisse.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make clean doesn't","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart.augustsson@credit-suisse.com"],"type":"Bug","description":"Typing 'make clean' at the top level only does this:\r\n{{{\r\nrm -f -rf autom4te.cache\r\nrm -f *.CKP *.ln *.BAK *.bak .*.bak *.o core a.out errs ,* *.a .emacs_* tags TAGS *.ind *.ilg *.idx *.idx-prev *.aux *.aux-prev *.dvi *.log *.toc *.lot *.lof *.blg *.cb *_stub.c *_stub.h *.raw_s *.a.list a.out ./*.hi hc-files-to-go *-hc.tar.gz\r\n}}}\r\n\r\nIt used to actually clean.\r\n\r\n -- Lennart","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1441Evaluating undefined should return line number and module of location of unde...2019-07-07T19:13:32Ziampure@gmail.comEvaluating undefined should return line number and module of location of undefinedEvaluating undefined should return line number and module of location of undefined when no optimizations are enabled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----...Evaluating undefined should return line number and module of location of undefined when no optimizations are enabled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Evaluating undefined should return line number and module of location of undefined","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"Evaluating undefined should return line number and module of location of undefined when no optimizations are enabled.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1442ghc and ghci differs in deailing with "undefined" with I/O2019-07-07T19:13:32Zguestghc and ghci differs in deailing with "undefined" with I/OThis program:
```
main = putStrLn ("x == " ++ undefined)
```
produces the following expected output with ghci:
```
x == *** Exception: Prelude.undefined
```
but when compiled with ghc and run, it gives:
```
$./a.out
a.out: Prelude....This program:
```
main = putStrLn ("x == " ++ undefined)
```
produces the following expected output with ghci:
```
x == *** Exception: Prelude.undefined
```
but when compiled with ghc and run, it gives:
```
$./a.out
a.out: Prelude.undefined
```
we observed this in all the way back to ghc6.2.1; possibly earlier.
The semantics of error reporting in combination with I/O is murky; admittedly laziness is observable at the top-level when errors are reported. But at least ghc and ghci should do the same thing. And the behavior of ghci seems to be more appropriate.
Thanks!
Jeff Lewis and Levent Erkok
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------------------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | jeff@galois.com, levent.erkok@galois.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ghc and ghci differs in deailing with \"undefined\" with I/O","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["jeff@galois.com","levent.erkok@galois.com"],"type":"Bug","description":"This program:\r\n{{{\r\nmain = putStrLn (\"x == \" ++ undefined)\r\n}}}\r\n\r\nproduces the following expected output with ghci:\r\n{{{\r\nx == *** Exception: Prelude.undefined\r\n}}}\r\n\r\nbut when compiled with ghc and run, it gives:\r\n{{{\r\n$./a.out \r\na.out: Prelude.undefined\r\n}}}\r\n\r\nwe observed this in all the way back to ghc6.2.1; possibly earlier.\r\n\r\nThe semantics of error reporting in combination with I/O is murky; admittedly laziness is observable at the top-level when errors are reported. But at least ghc and ghci should do the same thing. And the behavior of ghci seems to be more appropriate.\r\n\r\nThanks!\r\n\r\nJeff Lewis and Levent Erkok","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1443No instance for (Functor Language.Haskell.TH.Syntax.Q)2019-07-07T19:13:32ZSamuel BronsonNo instance for (Functor Language.Haskell.TH.Syntax.Q)There really ought to be one ;-). Now I have to import Control.Monad...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | ...There really ought to be one ;-). Now I have to import Control.Monad...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"No instance for (Functor Language.Haskell.TH.Syntax.Q)","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"6.6.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"There really ought to be one ;-). Now I have to import Control.Monad...","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1445implicit parameter not hoisted2019-07-07T19:13:31ZAshley Yakeley <ashley@semantic.org>implicit parameter not hoistedTry compiling this:
```
{-# OPTIONS -fglasgow-exts #-}
module Bug where
f :: () -> (?p :: ()) => () -> ()
f _ _ = ();
g :: (?p :: ()) => ()
g = f () ()
```
Results:
```
Bug.hs:7:10:
Couldn't match expected type `{?p::()}' aga...Try compiling this:
```
{-# OPTIONS -fglasgow-exts #-}
module Bug where
f :: () -> (?p :: ()) => () -> ()
f _ _ = ();
g :: (?p :: ()) => ()
g = f () ()
```
Results:
```
Bug.hs:7:10:
Couldn't match expected type `{?p::()}' against inferred type `()'
In the second argument of `f', namely `()'
In the expression: f () ()
In the definition of `g': g = f () ()
```
Expected: to compile.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"implicit parameter not hoisted","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Try compiling this:\r\n{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\nmodule Bug where\r\n\tf :: () -> (?p :: ()) => () -> ()\r\n\tf _ _ = ();\r\n\r\n\tg :: (?p :: ()) => ()\r\n\tg = f () ()\r\n}}}\r\nResults:\r\n{{{\r\nBug.hs:7:10:\r\n Couldn't match expected type `{?p::()}' against inferred type `()'\r\n In the second argument of `f', namely `()'\r\n In the expression: f () ()\r\n In the definition of `g': g = f () ()\r\n}}}\r\nExpected: to compile.","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/1446-fallow-incoherent-instances suggested when already used2019-07-07T19:13:31Ziampure@gmail.com-fallow-incoherent-instances suggested when already usedThis is essentially the same issue as with the monomorphism restriction, but then for another flag.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version...This is essentially the same issue as with the monomorphism restriction, but then for another flag.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"-fallow-incoherent-instances suggested when already used","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"This is essentially the same issue as with the monomorphism restriction, but then for another flag.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/1447Improve code generation for dense switches2019-07-07T19:13:30ZSimon Peyton JonesImprove code generation for dense switches(Adding this for Thomas Conway.)
I'm writing some variable byte codec routines, which are used in
inner!\^N loops, and which I want to make really efficient. There are
several spots where the code uses lookup tables.
The best example i...(Adding this for Thomas Conway.)
I'm writing some variable byte codec routines, which are used in
inner!\^N loops, and which I want to make really efficient. There are
several spots where the code uses lookup tables.
The best example is the table, which given the first byte, returns the
number of additional bytes. It is a precomputed version of the
following function:
```
> codeLength :: Word8 -> Int
> codeLength w
> | w .&. 0x80 == 0 = 0
> | otherwise = 1 + (codeLength $ w `shiftL` 1)
```
from which we construct a 256 entry table:
```
codeLen 0 = 0
codeLen 1 = 0
codeLen 2 = 0
...
codeLen 127 = 0
codeLen 128 = 1
...
codeLen 255 = 8
```
Now, compiling with ghc 6.6.1 and -O3, I see that it generates a long
chain of conditional branches. Now, even taking laziness into account,
this seems like terribly inefficient code. I wrote this thinking it
would be more efficient than constructing a CAF array:
```
codeLens = listArray (0,255) (map codeLength [0..255])
```
but I'm guessing the CAF version would probably work out much more
efficient in the long run.
However, I think ghc (and any other compiler), should detect the
following properties:
1. all the clauses are mutually exclusive, so the sequencing is
irrelevant to the semantics
1. Given an explicit type declaration Word8 -\> ...., the 256 cases
cover all the possible constructors of the type, so there are no
missing clauses.
Even if you leave out property 2 and include bounds checks, this seems
like an important kind of function to optimize well. So what have I
missed, or is it time to learn how to hack on ghc?⊥https://gitlab.haskell.org/ghc/ghc/-/issues/1448Segmentation fault with readline Module2019-07-07T19:13:30Zdanielehlers@mindeye.netSegmentation fault with readline ModuleHi,
I have an reproducible "Segmentation fault" with the System.Console.Readline
Module in an Project. I could strip down the problem to an little example
and reproduce it on any platform I tried.
```
import System.IO
import System.Con...Hi,
I have an reproducible "Segmentation fault" with the System.Console.Readline
Module in an Project. I could strip down the problem to an little example
and reproduce it on any platform I tried.
```
import System.IO
import System.Console.Readline
main :: IO ()
main = readKey >>= print >> main
```
I use ghc 6.6 and gcc 4.2.0.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Segmentation fault with readline Module","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":["Fault","Segmentation"],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Hi,\r\n\r\nI have an reproducible \"Segmentation fault\" with the System.Console.Readline\r\nModule in an Project. I could strip down the problem to an little example\r\nand reproduce it on any platform I tried.\r\n\r\n{{{\r\nimport System.IO\r\nimport System.Console.Readline\r\n\r\nmain :: IO ()\r\nmain = readKey >>= print >> main\r\n}}}\r\n\r\nI use ghc 6.6 and gcc 4.2.0.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1449Bug in instance MonadFix []2019-07-07T19:13:30Zoerjan@nvg.ntnu.noBug in instance MonadFix [](Thanks to Simon Marlow for pointing me to trac)
I was recently playing around with mfix on \#haskell, after seeing the "fix
show" trick. I tried "mfix show" which ought to have done something similar
using Char instead of String. This ...(Thanks to Simon Marlow for pointing me to trac)
I was recently playing around with mfix on \#haskell, after seeing the "fix
show" trick. I tried "mfix show" which ought to have done something similar
using Char instead of String. This turned up a bug for the list instance of
MonadFix and a half-bug for the Char instance for Show. (The latter is
slightly too strict for Char, not even producing the initial '. However I
guess this is unlikely to matter for anything other than this kind of
trick.)
The definition of mfix for lists is
```
instance MonadFix [] where
mfix f = case fix (f . head) of
[] -> []
(x:_) -> x : mfix (tail . f)
```
This assumes that mfix (tail . f) = tail (mfix f), which simply is not true
(for one thing, it would drop the head of anything produced by f.)
My attempts to use it failed with a stack error:
```
00:50 oerjan> > mfix (([1,2]++).(:[]))
00:50 lambdabot> Exception: stack overflow
```
The following replacement should give the result I expected:
```
instance MonadFix [] where
mfix f = l where
l = case fix (f . head) of
[] -> []
x@(_:_) -> x ++ concatMap f (tail l)
00:51 oerjan> > mfix' (([1,2]++).(:[]))
00:51 lambdabot>
[1,2,1,1,2,2,1,2,1,1,2,1,1,2,2,1,2,2,1,2,1,1,2,2,1,2,1,1,2,1,1,2,2,1,2,1,1,2 ...
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Bug in instance MonadFix []","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"(Thanks to Simon Marlow for pointing me to trac)\r\n\r\nI was recently playing around with mfix on #haskell, after seeing the \"fix\r\nshow\" trick. I tried \"mfix show\" which ought to have done something similar\r\nusing Char instead of String. This turned up a bug for the list instance of\r\nMonadFix and a half-bug for the Char instance for Show. (The latter is\r\nslightly too strict for Char, not even producing the initial '. However I\r\nguess this is unlikely to matter for anything other than this kind of\r\ntrick.)\r\n\r\nThe definition of mfix for lists is\r\n\r\n{{{\r\ninstance MonadFix [] where\r\n mfix f = case fix (f . head) of\r\n [] -> []\r\n (x:_) -> x : mfix (tail . f)\r\n}}}\r\n\r\nThis assumes that mfix (tail . f) = tail (mfix f), which simply is not true\r\n(for one thing, it would drop the head of anything produced by f.)\r\nMy attempts to use it failed with a stack error:\r\n\r\n{{{\r\n00:50 oerjan> > mfix (([1,2]++).(:[]))\r\n00:50 lambdabot> Exception: stack overflow\r\n}}}\r\n\r\nThe following replacement should give the result I expected:\r\n\r\n{{{\r\ninstance MonadFix [] where\r\n mfix f = l where\r\n l = case fix (f . head) of\r\n [] -> []\r\n x@(_:_) -> x ++ concatMap f (tail l)\r\n\r\n00:51 oerjan> > mfix' (([1,2]++).(:[]))\r\n00:51 lambdabot>\r\n[1,2,1,1,2,2,1,2,1,1,2,1,1,2,2,1,2,2,1,2,1,1,2,2,1,2,1,1,2,1,1,2,2,1,2,1,1,2 ...\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1450^C doesn't result in the cost center stack being printed when running with +R...2019-07-07T19:13:30ZSamuel Bronson^C doesn't result in the cost center stack being printed when running with +RTS -xcAll I see is:
```
Foo: interrupted
```
when I terminate a program with `^C` (because it appears to be in an infinite, or maybe just really long, loop).
at least it seems to be writing the profile now...All I see is:
```
Foo: interrupted
```
when I terminate a program with `^C` (because it appears to be in an infinite, or maybe just really long, loop).
at least it seems to be writing the profile now...6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>