GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:46:07Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8190mention --show-options in --help2019-07-07T18:46:07ZCarter Schonwaldmention --show-options in --helpGHC head now has a --show-options flag, that lists all of the supported ghc options.
maybe --help should mention this flag, and that every option is specified in the ghc manual?
<details><summary>Trac metadata</summary>
| Trac field ...GHC head now has a --show-options flag, that lists all of the supported ghc options.
maybe --help should mention this flag, and that every option is specified in the ghc manual?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"mention --show-options in --help","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC head now has a --show-options flag, that lists all of the supported ghc options.\r\n\r\nmaybe --help should mention this flag, and that every option is specified in the ghc manual?","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/8189Default to infinite stack size?2019-07-07T18:46:07ZNiklas Hambüchenmail@nh2.meDefault to infinite stack size?http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html
It looks like any code of the form
```
... = do
x1 <- m1
x2 <- m2
[do something with x1 and m2]
```
will stack overflow when used with a strict monad (like IO...http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html
It looks like any code of the form
```
... = do
x1 <- m1
x2 <- m2
[do something with x1 and m2]
```
will stack overflow when used with a strict monad (like IO) and sufficiently large data to deal with (a 1m element list is enough to exceed the default 8MB stack size limit).
Other examples include:
```
sequence (m:ms) = do x <- m
xs <- sequence ms
return (x:xs)
```
and
```
liftM2, liftM3, ...
```
By slightly modifying your program to do the same thing via heap allocation (e.g. using a difference list in sequence), a stack-overflow rejected program turns into a valid program.
This means that valid and idiomatic code like
```
xs <- replicateM n someIOAction
xs <- mapM someIOAction [1..n]
```
will eventually crash, which has an impact on practically all Haskell software and libraries out there.
For examples, see
https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database.hs\#L394
https://github.com/haskell-suite/haskell-src-exts/issues/27
as well as the mapM usages in cabal, haddock, any database binding that allows querying a lists of results, etc.
While some argue that ''"you shouldn't use lists of that size"*, *"allocating a 150 MB list is wrong"* or that they *"carefully avoid any use of sequence/mapM due to the problem"'' pointed out above, I think that collecting a million results of a strict monadic action into a linked list using standard functions like mapM is a common pattern and valid use case. The stack based evaluation that GHC performs is an optimization and should be transparent to the user; it should not re-define some data to live in a fixed-size memory region, and it should work just as well as it does in GHCi.
It seems that a default infinite stack size would mitigate this.
A drawback might be that the stack space overflows we get so far to quickly spot a "wrong" program would not indicate certain errors any more. I currently doubt the usefulness of this debugging method, since it does not work reliably in the presence of optimization, doing the same thing via heap allocation makes the programs "correct", and it rejects valid programs if the input data is large enough.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mail@nh2.me |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Default to infinite stack size?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mail@nh2.me"],"type":"Bug","description":"http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html\r\n\r\nIt looks like any code of the form\r\n\r\n{{{\r\n... = do\r\n x1 <- m1\r\n x2 <- m2\r\n [do something with x1 and m2]\r\n}}}\r\n\r\nwill stack overflow when used with a strict monad (like IO) and sufficiently large data to deal with (a 1m element list is enough to exceed the default 8MB stack size limit).\r\n\r\nOther examples include:\r\n\r\n{{{\r\n sequence (m:ms) = do x <- m\r\n xs <- sequence ms\r\n return (x:xs)\r\n}}}\r\n\r\nand\r\n\r\n{{{\r\nliftM2, liftM3, ...\r\n}}}\r\n\r\nBy slightly modifying your program to do the same thing via heap allocation (e.g. using a difference list in sequence), a stack-overflow rejected program turns into a valid program.\r\n\r\nThis means that valid and idiomatic code like\r\n\r\n{{{\r\nxs <- replicateM n someIOAction\r\nxs <- mapM someIOAction [1..n]\r\n}}}\r\n\r\nwill eventually crash, which has an impact on practically all Haskell software and libraries out there.\r\n\r\nFor examples, see\r\nhttps://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database.hs#L394\r\nhttps://github.com/haskell-suite/haskell-src-exts/issues/27\r\nas well as the mapM usages in cabal, haddock, any database binding that allows querying a lists of results, etc.\r\n\r\nWhile some argue that ''\"you shouldn't use lists of that size\"'', ''\"allocating a 150 MB list is wrong\"'' or that they ''\"carefully avoid any use of sequence/mapM due to the problem\"'' pointed out above, I think that collecting a million results of a strict monadic action into a linked list using standard functions like mapM is a common pattern and valid use case. The stack based evaluation that GHC performs is an optimization and should be transparent to the user; it should not re-define some data to live in a fixed-size memory region, and it should work just as well as it does in GHCi.\r\n\r\nIt seems that a default infinite stack size would mitigate this.\r\n\r\n\r\nA drawback might be that the stack space overflows we get so far to quickly spot a \"wrong\" program would not indicate certain errors any more. I currently doubt the usefulness of this debugging method, since it does not work reliably in the presence of optimization, doing the same thing via heap allocation makes the programs \"correct\", and it rejects valid programs if the input data is large enough.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/8185Change role annotation syntax2019-07-07T18:46:08ZRichard Eisenbergrae@richarde.devChange role annotation syntaxCurrently, role annotations look like this:
```
data Foo a@N = ...
```
I've received several criticisms of this syntax:
- It is not backward compatible. If a library wishes to use role annotations and remain compilable with earlier ve...Currently, role annotations look like this:
```
data Foo a@N = ...
```
I've received several criticisms of this syntax:
- It is not backward compatible. If a library wishes to use role annotations and remain compilable with earlier versions of GHC, preprocessor commands are necessary.
- It is inscrutable for someone not well-versed in roles.
- It reminds people of as-patterns, which it is unrelated to.
- It is conceivable that it would conflict with type-level as-patterns.
For these reasons, I propose the following:
```
data Foo a {-# ROLE Nominal #-} = ...
```
This syntax, while verbose, eliminates these concerns, considering that the new syntax is easily searchable for someone who doesn't know it. I have proposed something similar on ghc-devs, with no response, so I will implement it shortly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Change role annotation syntax","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, role annotations look like this:\r\n\r\n{{{\r\ndata Foo a@N = ...\r\n}}}\r\n\r\nI've received several criticisms of this syntax:\r\n\r\n* It is not backward compatible. If a library wishes to use role annotations and remain compilable with earlier versions of GHC, preprocessor commands are necessary.\r\n* It is inscrutable for someone not well-versed in roles.\r\n* It reminds people of as-patterns, which it is unrelated to.\r\n* It is conceivable that it would conflict with type-level as-patterns.\r\n\r\nFor these reasons, I propose the following:\r\n\r\n{{{\r\ndata Foo a {-# ROLE Nominal #-} = ...\r\n}}}\r\n\r\nThis syntax, while verbose, eliminates these concerns, considering that the new syntax is easily searchable for someone who doesn't know it. I have proposed something similar on ghc-devs, with no response, so I will implement it shortly.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/8182Parser.y.pp needs special treatment with -fcmm-sink2019-07-07T18:46:09ZthoughtpoliceParser.y.pp needs special treatment with -fcmm-sinkThis bug is really more of a reminder, but it's critical for the 7.8.1 release.
Right now, `Parser.y.pp` uses a very weird hack to pass `-fcmm-sink` to the compiler. Here's the relevant comment:
```
-- CPP tricks because we want the di...This bug is really more of a reminder, but it's critical for the 7.8.1 release.
Right now, `Parser.y.pp` uses a very weird hack to pass `-fcmm-sink` to the compiler. Here's the relevant comment:
```
-- CPP tricks because we want the directives in the output of the
-- first CPP pass.
--
-- Clang note, 6/17/2013 by aseipp: It is *extremely* important (for
-- some reason) that there be a line of whitespace between the two
-- definitions here, and the subsequent use of __IF_GHC_77__ - this
-- seems to be a bug in clang or something, where having the line of
-- whitespace will make the preprocessor correctly format the rendered
-- lines in the 'two step' CPP pass. No, this is not a joke.
#define __IF_GHC_77__ #if __GLASGOW_HASKELL__ >= 707
#define __ENDIF__ #endif
__IF_GHC_77__
-- Required on x86 to avoid the register allocator running out of
-- stack slots when compiling this module with -fPIC -dynamic.
{-# OPTIONS_GHC -fcmm-sink #-}
__ENDIF__
```
This is because the parser is first preprocessed before being run with GHC (which again preprocesses,) so we want the resulting `#ifdef` in the final `.hs` file.
Things to note:
- We really shouldn't be doing this, it's amazingly fragile. I think the correct thing to do is to ensure the build system correctly passes `-fcmm-sink` during the stage\[2,3\] build.
- `./configure.ac` needs to check to see if the bootstrapping compiler is `ghc >= 7.7` (or `7.8`) and if it is, *also* pass `-fcmm-sink` during the stage1 build.
- This hack needs to be removed once we can rely on \>= 7.8 for bootstrap. Probably something like the hypothetical 7.12-7.14 timeframe.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parser.y.pp needs special treatment with -fcmm-sink","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"thoughtpolice"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This bug is really more of a reminder, but it's critical for the 7.8.1 release.\r\n\r\nRight now, `Parser.y.pp` uses a very weird hack to pass `-fcmm-sink` to the compiler. Here's the relevant comment:\r\n\r\n{{{\r\n-- CPP tricks because we want the directives in the output of the\r\n-- first CPP pass.\r\n--\r\n-- Clang note, 6/17/2013 by aseipp: It is *extremely* important (for\r\n-- some reason) that there be a line of whitespace between the two\r\n-- definitions here, and the subsequent use of __IF_GHC_77__ - this\r\n-- seems to be a bug in clang or something, where having the line of\r\n-- whitespace will make the preprocessor correctly format the rendered\r\n-- lines in the 'two step' CPP pass. No, this is not a joke.\r\n#define __IF_GHC_77__ #if __GLASGOW_HASKELL__ >= 707\r\n#define __ENDIF__ #endif\r\n\r\n__IF_GHC_77__\r\n-- Required on x86 to avoid the register allocator running out of\r\n-- stack slots when compiling this module with -fPIC -dynamic.\r\n{-# OPTIONS_GHC -fcmm-sink #-}\r\n__ENDIF__\r\n}}}\r\n\r\nThis is because the parser is first preprocessed before being run with GHC (which again preprocesses,) so we want the resulting `#ifdef` in the final `.hs` file.\r\n\r\nThings to note:\r\n\r\n * We really shouldn't be doing this, it's amazingly fragile. I think the correct thing to do is to ensure the build system correctly passes `-fcmm-sink` during the stage[2,3] build.\r\n * `./configure.ac` needs to check to see if the bootstrapping compiler is `ghc >= 7.7` (or `7.8`) and if it is, ''also'' pass `-fcmm-sink` during the stage1 build.\r\n * This hack needs to be removed once we can rely on >= 7.8 for bootstrap. Probably something like the hypothetical 7.12-7.14 timeframe.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/8181-dyno and -dynamic-too undocumented2019-07-07T18:46:10ZRichard Eisenbergrae@richarde.dev-dyno and -dynamic-too undocumentedI can't seem to find `-dyno` and `-dynamic-too` documented in the User's Guide for HEAD. There may be other missing undocumented options in this area, too.
<details><summary>Trac metadata</summary>
| Trac field | Value ...I can't seem to find `-dyno` and `-dynamic-too` documented in the User's Guide for HEAD. There may be other missing undocumented options in this area, too.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-dyno and -dynamic-too undocumented","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I can't seem to find `-dyno` and `-dynamic-too` documented in the User's Guide for HEAD. There may be other missing undocumented options in this area, too.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/8180Template Haskell now requires -dynamic or -dynamic-too2019-07-07T18:46:10ZRichard Eisenbergrae@richarde.devTemplate Haskell now requires -dynamic or -dynamic-tooI have the following files:
```
{-# LANGUAGE TemplateHaskell #-}
module THSplice where
number3 = [| 3 |]
```
```
{-# LANGUAGE TemplateHaskell #-}
module Main where
import THSplice
main = putStrLn (show $number3)
```
When I say `g...I have the following files:
```
{-# LANGUAGE TemplateHaskell #-}
module THSplice where
number3 = [| 3 |]
```
```
{-# LANGUAGE TemplateHaskell #-}
module Main where
import THSplice
main = putStrLn (show $number3)
```
When I say `ghc Main.hs`, I get this:
```
[1 of 2] Compiling THSplice ( THSplice.hs, THSplice.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Main.hs:7:23:
cannot find normal object file ‛./THSplice.dyn_o’
while linking an interpreted expression
```
It's possible a different collection of flags could get this to work, but I think this behavior goes against the intended "it just works" flavor of `--make`.
This is a regression bug -- ghc 7.6.3 does the right thing.
I'm on MacOS 10.7.5, Xcode 4.3.3.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"ghc --make uses wrong way with Template Haskell","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"I have the following files:\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nmodule THSplice where\r\n\r\nnumber3 = [| 3 |]\r\n}}}\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nmodule Main where\r\n\r\nimport THSplice\r\n\r\nmain = putStrLn (show $number3)\r\n}}}\r\n\r\nWhen I say `ghc Main.hs`, I get this:\r\n\r\n{{{\r\n[1 of 2] Compiling THSplice ( THSplice.hs, THSplice.o )\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nMain.hs:7:23:\r\n cannot find normal object file ‛./THSplice.dyn_o’\r\n while linking an interpreted expression\r\n}}}\r\n\r\nIt's possible a different collection of flags could get this to work, but I think this behavior goes against the intended \"it just works\" flavor of `--make`.\r\n\r\nThis is a regression bug -- ghc 7.6.3 does the right thing.\r\n\r\nI'm on MacOS 10.7.5, Xcode 4.3.3.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/8172Expose CWD and import search paths in GHCi via new `:show paths` command2019-07-07T18:46:12ZHerbert Valerio Riedelhvr@gnu.orgExpose CWD and import search paths in GHCi via new `:show paths` command- Currently, GHCi provides a `:cd` command but no respective builtin command to query the currently set path.
- Moreover, there's no obvious way to query the currently active `importPaths` dynamic flags field, to find out which `-i` opt...- Currently, GHCi provides a `:cd` command but no respective builtin command to query the currently set path.
- Moreover, there's no obvious way to query the currently active `importPaths` dynamic flags field, to find out which `-i` options are currently in effect.
The attached patch extends `:show` with a `:show paths` subcommand, printing the CWD and the current value of `importPaths`:
```
Ok, modules loaded: Main, InteractiveUI, Paths_ghci_ng, GhciMonad, GhciTags.
λ> :show paths
current working directory:
/home/hvr/Haskell/My/ghci-ng
module import search paths:
dist/build/ghci-ng/ghci-ng-tmp
ghc
dist/build/autogen
λ> :set -i
λ> :show paths
current working directory:
/home/hvr/Haskell/My/ghci-ng
module import search paths: none
> :cd /tmp
Warning: changing directory causes all loaded modules to be unloaded,
because the search path has changed.
> :show paths
current working directory:
/tmp
module import search paths: none
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Expose CWD and import search paths in GHCi via new `:show paths` command","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"hvr"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":" - Currently, GHCi provides a `:cd` command but no respective builtin command to query the currently set path.\r\n - Moreover, there's no obvious way to query the currently active `importPaths` dynamic flags field, to find out which `-i` options are currently in effect.\r\n\r\nThe attached patch extends `:show` with a `:show paths` subcommand, printing the CWD and the current value of `importPaths`:\r\n\r\n{{{\r\nOk, modules loaded: Main, InteractiveUI, Paths_ghci_ng, GhciMonad, GhciTags.\r\nλ> :show paths \r\ncurrent working directory: \r\n /home/hvr/Haskell/My/ghci-ng\r\nmodule import search paths:\r\n dist/build/ghci-ng/ghci-ng-tmp\r\n ghc\r\n dist/build/autogen\r\n\r\nλ> :set -i\r\n\r\nλ> :show paths \r\ncurrent working directory: \r\n /home/hvr/Haskell/My/ghci-ng\r\nmodule import search paths: none\r\n\r\n> :cd /tmp\r\nWarning: changing directory causes all loaded modules to be unloaded,\r\nbecause the search path has changed.\r\n\r\n> :show paths \r\ncurrent working directory: \r\n /tmp\r\nmodule import search paths: none\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/8166Undefined references in HEAD object files2019-07-07T18:46:13ZjoelteonUndefined references in HEAD object files```
$ uname -a
Linux default-centos-64.vagrantup.com 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
```
When I try to bootstrap cabal-install using GHC HEAD:
```
Checking installed packages for...```
$ uname -a
Linux default-centos-64.vagrantup.com 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
```
When I try to bootstrap cabal-install using GHC HEAD:
```
Checking installed packages for ghc-7.7.20130823...
Cabal is already installed and the version is ok.
transformers is already installed and the version is ok.
mtl-2.1.2 will be downloaded and installed.
deepseq is already installed and the version is ok.
text-0.11.2.3 will be downloaded and installed.
parsec-3.1.3 will be downloaded and installed.
network-2.4.1.0 will be downloaded and installed.
time is already installed and the version is ok.
HTTP-4000.2.5 will be downloaded and installed.
zlib-0.5.4.0 will be downloaded and installed.
random-1.0.1.1 will be downloaded and installed.
stm-2.4.2 will be downloaded and installed.
Downloading mtl-2.1.2...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0
100 13723 100 13723 0 0 2432 0 0:00:05 0:00:05 --:--:-- 40964
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbw5_info':
(.text+0x83f): undefined reference to `r9F5_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `sapv_info':
(.text+0x1623): undefined reference to `r9F5_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbD6_info':
(.text+0x17a9): undefined reference to `r9F5_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbHC_info':
(.text+0x24ff): undefined reference to `r9F5_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbN4_info':
(.text+0x3257): undefined reference to `r9F5_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o):(.text+0x3faf): more undefined references to `r9F5_info' follow
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `ccEX_info':
(.text+0xb63c): undefined reference to `r9F3_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `ScJo_srt':
(.data+0x38): undefined reference to `r9F5_closure'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `ScJo_srt':
(.data+0x180): undefined reference to `r9F3_closure'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3WN_info':
(.text+0x8a): undefined reference to `r3Eg_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `c5NF_info':
(.text+0x118): undefined reference to `r3Eh_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3XR_info':
(.text+0xc35): undefined reference to `r3Ei_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3YA_info':
(.text+0xefe): undefined reference to `r3E8_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3Z6_info':
(.text+0x100e): undefined reference to `r3E8_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3Zb_info':
(.text+0x1095): undefined reference to `r3Ei_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `c5X3_info':
(.text+0x16d6): undefined reference to `r3E8_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `c5Xj_info':
(.text+0x19d3): undefined reference to `r3E8_info'
/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `S60p_srt':
(.data+0x18): undefined reference to `r3E8_closure'
(repeats ad nauseam)
collect2: ld returned 1 exit status
Error during cabal-install bootstrap:
Compiling the Setup script failed
```
The full output can be found at https://gist.github.com/anonymous/e30cda2ca16f1e90e13e/raw/eb9b2d10db44d0288ce79fd2c5955455c02926d9/cabal.txt
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Undefined references in HEAD object files","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ uname -a\r\nLinux default-centos-64.vagrantup.com 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux\r\n}}}\r\n\r\nWhen I try to bootstrap cabal-install using GHC HEAD:\r\n\r\n{{{\r\nChecking installed packages for ghc-7.7.20130823...\r\nCabal is already installed and the version is ok.\r\ntransformers is already installed and the version is ok.\r\nmtl-2.1.2 will be downloaded and installed.\r\ndeepseq is already installed and the version is ok.\r\ntext-0.11.2.3 will be downloaded and installed.\r\nparsec-3.1.3 will be downloaded and installed.\r\nnetwork-2.4.1.0 will be downloaded and installed.\r\ntime is already installed and the version is ok.\r\nHTTP-4000.2.5 will be downloaded and installed.\r\nzlib-0.5.4.0 will be downloaded and installed.\r\nrandom-1.0.1.1 will be downloaded and installed.\r\nstm-2.4.2 will be downloaded and installed.\r\n\r\nDownloading mtl-2.1.2...\r\n % Total % Received % Xferd Average Speed Time Time Time Current\r\n Dload Upload Total Spent Left Speed\r\n\r\n 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0\r\n100 13723 100 13723 0 0 2432 0 0:00:05 0:00:05 --:--:-- 40964\r\n[1 of 1] Compiling Main ( Setup.hs, Setup.o )\r\nLinking Setup ...\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbw5_info':\r\n(.text+0x83f): undefined reference to `r9F5_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `sapv_info':\r\n(.text+0x1623): undefined reference to `r9F5_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbD6_info':\r\n(.text+0x17a9): undefined reference to `r9F5_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbHC_info':\r\n(.text+0x24ff): undefined reference to `r9F5_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbN4_info':\r\n(.text+0x3257): undefined reference to `r9F5_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o):(.text+0x3faf): more undefined references to `r9F5_info' follow\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `ccEX_info':\r\n(.text+0xb63c): undefined reference to `r9F3_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `ScJo_srt':\r\n(.data+0x38): undefined reference to `r9F5_closure'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `ScJo_srt':\r\n(.data+0x180): undefined reference to `r9F3_closure'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3WN_info':\r\n(.text+0x8a): undefined reference to `r3Eg_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `c5NF_info':\r\n(.text+0x118): undefined reference to `r3Eh_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3XR_info':\r\n(.text+0xc35): undefined reference to `r3Ei_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3YA_info':\r\n(.text+0xefe): undefined reference to `r3E8_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3Z6_info':\r\n(.text+0x100e): undefined reference to `r3E8_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3Zb_info':\r\n(.text+0x1095): undefined reference to `r3Ei_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `c5X3_info':\r\n(.text+0x16d6): undefined reference to `r3E8_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `c5Xj_info':\r\n(.text+0x19d3): undefined reference to `r3E8_info'\r\n/usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `S60p_srt':\r\n(.data+0x18): undefined reference to `r3E8_closure'\r\n\r\n(repeats ad nauseam)\r\n\r\ncollect2: ld returned 1 exit status\r\n\r\nError during cabal-install bootstrap:\r\nCompiling the Setup script failed\r\n}}}\r\n\r\nThe full output can be found at https://gist.github.com/anonymous/e30cda2ca16f1e90e13e/raw/eb9b2d10db44d0288ce79fd2c5955455c02926d9/cabal.txt","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Jan Stolarekjan.stolarek@ed.ac.ukJan Stolarekjan.stolarek@ed.ac.ukhttps://gitlab.haskell.org/ghc/ghc/-/issues/8160sync-all failing to detect Windows2019-07-07T18:46:14ZSimon Peyton Jonessync-all failing to detect WindowsSee [http://www.haskell.org/pipermail/ghc-devs/2013-August/002102.html](http://www.haskell.org/pipermail/ghc-devs/2013-August/002102.html). The sync-all script tries to detect Windows but is failing.
Also when the subsequent build fails...See [http://www.haskell.org/pipermail/ghc-devs/2013-August/002102.html](http://www.haskell.org/pipermail/ghc-devs/2013-August/002102.html). The sync-all script tries to detect Windows but is failing.
Also when the subsequent build fails to unpack `ghc-tarballs`, it somehow recovers and proceeds, leading to obscure subsequent fallout.
Can't be hard to fix; but the fallout from failure is bad.
Simon
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"sync-all failing to detect Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"See [http://www.haskell.org/pipermail/ghc-devs/2013-August/002102.html]. The sync-all script tries to detect Windows but is failing.\r\n\r\nAlso when the subsequent build fails to unpack `ghc-tarballs`, it somehow recovers and proceeds, leading to obscure subsequent fallout.\r\n\r\nCan't be hard to fix; but the fallout from failure is bad.\r\n\r\nSimon","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/8158Replace IO manager's IntMap with a mutable hash table2019-07-07T18:46:15ZbosReplace IO manager's IntMap with a mutable hash tableI've written a patch that replaces the immutable !IntMap used by GHC.Event with a mutable hashtable, !IntTable.
There's a standalone version of the new data structure, complete with !QuickCheck tests and benchmarks, [available on github...I've written a patch that replaces the immutable !IntMap used by GHC.Event with a mutable hashtable, !IntTable.
There's a standalone version of the new data structure, complete with !QuickCheck tests and benchmarks, [available on github](https://github.com/bos/inttable). It's about 15x faster than !IntMap, and substantially simpler.
In practice, this translates to a small but measurable improvement in throughput (and presumably latency). I see a 3% to 10% bump in requests handled per second by the tiny [acme-http http server](http://hackage.haskell.org/package/acme-http) when benchmarked using the [weighttp load tester](https://github.com/lighttpd/weighttp).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------------------------- |
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | AndreasVoellmy, kazu-yamamoto, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Replace IO manager's IntMap with a mutable hash table","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["AndreasVoellmy","kazu-yamamoto","simonmar"],"type":"FeatureRequest","description":"I've written a patch that replaces the immutable !IntMap used by GHC.Event with a mutable hashtable, !IntTable.\r\n\r\nThere's a standalone version of the new data structure, complete with !QuickCheck tests and benchmarks, [[https://github.com/bos/inttable|available on github]]. It's about 15x faster than !IntMap, and substantially simpler.\r\n\r\nIn practice, this translates to a small but measurable improvement in throughput (and presumably latency). I see a 3% to 10% bump in requests handled per second by the tiny [[http://hackage.haskell.org/package/acme-http|acme-http http server]] when benchmarked using the [[https://github.com/lighttpd/weighttp|weighttp load tester]].\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1AndreasVoellmyAndreasVoellmyhttps://gitlab.haskell.org/ghc/ghc/-/issues/8154Possible bug in open type familes: Conflicting (a->a) and (a->a->a) instances2019-07-07T18:46:16ZNiklas Hambüchenmail@nh2.mePossible bug in open type familes: Conflicting (a->a) and (a->a->a) instances```
{-# LANGUAGE TypeFamilies #-}
module Test where
type family BoundsOf x
type instance BoundsOf (a->a) = Int
type instance BoundsOf (a->a->a) = (Int,Int)
```
This worked with GHC 7.6, but not with 7.8 HEAD (currently at 6cc7d3f).
...```
{-# LANGUAGE TypeFamilies #-}
module Test where
type family BoundsOf x
type instance BoundsOf (a->a) = Int
type instance BoundsOf (a->a->a) = (Int,Int)
```
This worked with GHC 7.6, but not with 7.8 HEAD (currently at 6cc7d3f).
To check:
```
wget https://gist.github.com/nh2/6302087/raw/8167e7a1c8613aa384c2e8ca2f4ea9ade8745dc1/ghc-7.7-type-a-a-a-families.hs
ghci ghc-7.7-type-a-a-a-families.hs # 7.6, all fine
ghci ghc-7.7-type-a-a-a-families.hs # 7.7, breaks
```
On \#ghc, we don't really understand whether this is the right thing to happen or not.
```
<rwbarton> see http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/23734
<carter> c_wraith: im not sure why thats NOT working for open type familes too though
<carter> a->a and a->a->a don't overlap...
<rwbarton> ah it's in that thread. "Open (normal, old-fashioned) type families are essentially unchanged. In particular, coincident overlap and non-linear patterns *are* allowed. The overlap check between open type family instances now does a unification without an "occurs check" to mark (x, x) and ([y], y) as overlapping, as necessary for type soundness."
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Possible bug in open type familes: Conflicting (a->a) and (a->a->a) instances","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":["families","type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Test where\r\n \r\ntype family BoundsOf x\r\n \r\ntype instance BoundsOf (a->a) = Int\r\ntype instance BoundsOf (a->a->a) = (Int,Int)\r\n}}}\r\n\r\nThis worked with GHC 7.6, but not with 7.8 HEAD (currently at 6cc7d3f).\r\n\r\nTo check:\r\n{{{\r\nwget https://gist.github.com/nh2/6302087/raw/8167e7a1c8613aa384c2e8ca2f4ea9ade8745dc1/ghc-7.7-type-a-a-a-families.hs\r\nghci ghc-7.7-type-a-a-a-families.hs # 7.6, all fine\r\nghci ghc-7.7-type-a-a-a-families.hs # 7.7, breaks\r\n}}}\r\n\r\nOn #ghc, we don't really understand whether this is the right thing to happen or not.\r\n\r\n{{{\r\n<rwbarton> see http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/23734\r\n<carter> c_wraith: im not sure why thats NOT working for open type familes too though\r\n<carter> a->a and a->a->a don't overlap...\r\n<rwbarton> ah it's in that thread. \"Open (normal, old-fashioned) type families are essentially unchanged. In particular, coincident overlap and non-linear patterns *are* allowed. The overlap check between open type family instances now does a unification without an \"occurs check\" to mark (x, x) and ([y], y) as overlapping, as necessary for type soundness.\"\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8148./configure IGNORES --with-gcc=gcc-4.8, can't build head on os x 10.8 with x...2019-07-07T18:46:17ZCarter Schonwald./configure IGNORES --with-gcc=gcc-4.8, can't build head on os x 10.8 with xcode 5 installedIm seeing the build scripts using gcc instead of gcc-4.8
this is problematic! with xcode 5, gcc IS an old version of clang!
attaching a copy of the build log.
i'm using 7.6.3 to build this, and the ghc 7.6.3 settings file is pointing ...Im seeing the build scripts using gcc instead of gcc-4.8
this is problematic! with xcode 5, gcc IS an old version of clang!
attaching a copy of the build log.
i'm using 7.6.3 to build this, and the ghc 7.6.3 settings file is pointing to gcc-4.8, so it can only be the build system. I think
```
[("GCC extra via C opts", " -fwrapv"),
("C compiler command", "gcc-4.8"),
("C compiler flags", " -m64 -fno-stack-protector -m64"),
("ar command", "/usr/bin/ar"),
("ar flags", "clqs"),
("ar supports at file", "@ArSupportsAtFile@"),
("touch command", "touch"),
("dllwrap command", "/bin/false"),
("windres command", "/bin/false"),
("perl command", "/usr/bin/perl"),
("target os", "OSDarwin"),
("target arch", "ArchX86_64"),
("target word size", "8"),
("target has GNU nonexec stack", "False"),
("target has .ident directive", "True"),
("target has subsections via symbols", "True"),
("LLVM llc command", "llc"),
("LLVM opt command", "opt")
]
```
is host 7.6.3 ghc setup
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"./configure IGNORES --with-gcc=gcc-4.8","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Im seeing the build scripts using gcc instead of gcc-4.8\r\n\r\nthis is problematic! with xcode 5, gcc IS an old version of clang! \r\n\r\nattaching a copy of the build log.\r\n\r\ni'm using 7.6.3 to build this, and the ghc 7.6.3 settings file is pointing to gcc-4.8, so it can only be the build system. I think\r\n\r\n{{{\r\n[(\"GCC extra via C opts\", \" -fwrapv\"),\r\n (\"C compiler command\", \"gcc-4.8\"),\r\n (\"C compiler flags\", \" -m64 -fno-stack-protector -m64\"),\r\n (\"ar command\", \"/usr/bin/ar\"),\r\n (\"ar flags\", \"clqs\"),\r\n (\"ar supports at file\", \"@ArSupportsAtFile@\"),\r\n (\"touch command\", \"touch\"),\r\n (\"dllwrap command\", \"/bin/false\"),\r\n (\"windres command\", \"/bin/false\"),\r\n (\"perl command\", \"/usr/bin/perl\"),\r\n (\"target os\", \"OSDarwin\"),\r\n (\"target arch\", \"ArchX86_64\"),\r\n (\"target word size\", \"8\"),\r\n (\"target has GNU nonexec stack\", \"False\"),\r\n (\"target has .ident directive\", \"True\"),\r\n (\"target has subsections via symbols\", \"True\"),\r\n (\"LLVM llc command\", \"llc\"),\r\n (\"LLVM opt command\", \"opt\")\r\n ]\r\n\r\n\r\n}}} is host 7.6.3 ghc setup\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8139ghc 7.6.3 and ghc HEAD fails to build on OS X 10.92019-07-07T18:46:19Zdarinmorrisonghc 7.6.3 and ghc HEAD fails to build on OS X 10.9ghc 7.6.3 does not compile on OS X 10.9 (as of DP5).
There are a few issues that seem to be causing this:
1) gcc is no longer available and the clang compatibility patches of #7678 are not included in 7.6.3.
2) There is some sort of b...ghc 7.6.3 does not compile on OS X 10.9 (as of DP5).
There are a few issues that seem to be causing this:
1) gcc is no longer available and the clang compatibility patches of #7678 are not included in 7.6.3.
2) There is some sort of bug that causes mkdirhier.sh to fail in some cases.
3) There is another bug when compiling RtsProbes.d with DTrace. The problem seems to be triggered by the inclusion of stdint.h. \#undef-ing HAVE_STDINT_H only for the compilation of RtsProbes.d (which then includes inttypes.h instead) seems to work for some reason. A better solution may be possible from someone who understands the DTrace machinery better.
The issue has has been discussed here:
https://github.com/mxcl/homebrew/issues/20546
I have come up with a tentative patch that fixes problems (2) and (3) here (and also pasted below):
https://github.com/darinmorrison/homebrew/commit/611c76f6d6701c482559a64fe262f85b4dfda96f
```
diff --git a/includes/HsFFI.h b/includes/HsFFI.h
index dceabab..bc5e423 100644
--- a/includes/HsFFI.h
+++ b/includes/HsFFI.h
@@ -21,7 +21,7 @@ extern "C" {
#include "stg/Types.h"
/* get limits for integral types */
-#ifdef HAVE_STDINT_H
+#if defined HAVE_STDINT_H && !defined RTS_PROBES_D
/* ISO C 99 says:
* "C++ implementations should define these macros only when
* __STDC_LIMIT_MACROS is defined before <stdint.h> is included."
diff --git a/rts/RtsProbes.d b/rts/RtsProbes.d
index 40665ac..8963ca7 100644
--- a/rts/RtsProbes.d
+++ b/rts/RtsProbes.d
@@ -6,6 +6,8 @@
*
* ---------------------------------------------------------------------------*/
+#define RTS_PROBES_D
+
#include "HsFFI.h"
#include "rts/EventLogFormat.h"
diff --git a/utils/mkdirhier/mkdirhier.sh b/utils/mkdirhier/mkdirhier.sh
index 4c5d5f7..80762f4 100644
--- a/utils/mkdirhier/mkdirhier.sh
+++ b/utils/mkdirhier/mkdirhier.sh
@@ -1,4 +1,4 @@
#!/bin/sh
-mkdir -p ${1+"$@"}
+mkdir -p ${1+"./$@"}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc 7.6.3 fails to build on OS X 10.9","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc 7.6.3 does not compile on OS X 10.9 (as of DP5).\r\n\r\nThere are a few issues that seem to be causing this:\r\n\r\n1) gcc is no longer available and the clang compatibility patches of http://ghc.haskell.org/trac/ghc/ticket/7678 are not included in 7.6.3.\r\n\r\n2) There is some sort of bug that causes mkdirhier.sh to fail in some cases.\r\n\r\n3) There is another bug when compiling RtsProbes.d with DTrace. The problem seems to be triggered by the inclusion of stdint.h. #undef-ing HAVE_STDINT_H only for the compilation of RtsProbes.d (which then includes inttypes.h instead) seems to work for some reason. A better solution may be possible from someone who understands the DTrace machinery better.\r\n\r\nThe issue has has been discussed here:\r\n\r\nhttps://github.com/mxcl/homebrew/issues/20546\r\n\r\nI have come up with a tentative patch that fixes problems (2) and (3) here (and also pasted below):\r\n\r\nhttps://github.com/darinmorrison/homebrew/commit/611c76f6d6701c482559a64fe262f85b4dfda96f\r\n\r\n{{{\r\ndiff --git a/includes/HsFFI.h b/includes/HsFFI.h\r\nindex dceabab..bc5e423 100644\r\n--- a/includes/HsFFI.h\r\n+++ b/includes/HsFFI.h\r\n@@ -21,7 +21,7 @@ extern \"C\" {\r\n #include \"stg/Types.h\"\r\n \r\n /* get limits for integral types */\r\n-#ifdef HAVE_STDINT_H\r\n+#if defined HAVE_STDINT_H && !defined RTS_PROBES_D\r\n /* ISO C 99 says:\r\n * \"C++ implementations should define these macros only when\r\n * __STDC_LIMIT_MACROS is defined before <stdint.h> is included.\"\r\ndiff --git a/rts/RtsProbes.d b/rts/RtsProbes.d\r\nindex 40665ac..8963ca7 100644\r\n--- a/rts/RtsProbes.d\r\n+++ b/rts/RtsProbes.d\r\n@@ -6,6 +6,8 @@\r\n *\r\n * ---------------------------------------------------------------------------*/\r\n \r\n+#define RTS_PROBES_D\r\n+\r\n #include \"HsFFI.h\"\r\n #include \"rts/EventLogFormat.h\"\r\n \r\ndiff --git a/utils/mkdirhier/mkdirhier.sh b/utils/mkdirhier/mkdirhier.sh\r\nindex 4c5d5f7..80762f4 100644\r\n--- a/utils/mkdirhier/mkdirhier.sh\r\n+++ b/utils/mkdirhier/mkdirhier.sh\r\n@@ -1,4 +1,4 @@\r\n #!/bin/sh\r\n \r\n-mkdir -p ${1+\"$@\"}\r\n+mkdir -p ${1+\"./$@\"}\r\n \r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1darinmorrisondarinmorrisonhttps://gitlab.haskell.org/ghc/ghc/-/issues/8132Warning for Typeable instances misplaced2019-07-07T18:46:21ZscottgwWarning for Typeable instances misplacedThere is currently a warning for hand-rolled instances of Typeable. However, this leads to some pretty surprising error messages: because the instance is ignored any code that relies on that instance in the same module just fails, which ...There is currently a warning for hand-rolled instances of Typeable. However, this leads to some pretty surprising error messages: because the instance is ignored any code that relies on that instance in the same module just fails, which appears pretty weird to the user.
```haskell
import Data.Typeable
data K = K
instance Typeable K where
typeRep _ = undefined
ex :: TypeRep
ex = typeRep (undefined :: Proxy K)
```
Gives as an error:
```
No instance for (Typeable * K) arising from a use of ‛typeRep’
In the expression: typeRep (undefined :: Proxy K)
In an equation for ‛ex’: ex = typeRep (undefined :: Proxy K)
```
Which is of course surprising because the user just defined the instance.
After commenting out the code that uses the instance, one gets:
```
TypEx.hs:1:1: Warning:
Typeable instances can only be derived; ignoring the following instance:
instance Typeable * K -- Defined at TypEx.hs:5:10
```
This information should clearly be somehow presented before or with the previous error if the user is to have any way to figure out what is going on.
I suppose this could be fixed by:
1. Turning the Typeable instance warning into an error
1. Checking the missing instance in the existing error for Typeable and suggest that the user should look for hand written instances as a source of the problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Warning for Typeable instances misplaced","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is currently a warning for hand-rolled instances of Typeable. However, this leads to some pretty surprising error messages: because the instance is ignored any code that relies on that instance in the same module just fails, which appears pretty weird to the user.\r\n\r\n{{{\r\n#!haskell\r\nimport Data.Typeable\r\n\r\ndata K = K\r\n\r\ninstance Typeable K where\r\n typeRep _ = undefined\r\n\r\nex :: TypeRep\r\nex = typeRep (undefined :: Proxy K)\r\n}}}\r\n\r\nGives as an error:\r\n\r\n{{{\r\n No instance for (Typeable * K) arising from a use of ‛typeRep’\r\n In the expression: typeRep (undefined :: Proxy K)\r\n In an equation for ‛ex’: ex = typeRep (undefined :: Proxy K)\r\n}}}\r\n\r\nWhich is of course surprising because the user just defined the instance.\r\n\r\nAfter commenting out the code that uses the instance, one gets:\r\n\r\n{{{\r\nTypEx.hs:1:1: Warning:\r\n Typeable instances can only be derived; ignoring the following instance:\r\n instance Typeable * K -- Defined at TypEx.hs:5:10\r\n}}}\r\n\r\nThis information should clearly be somehow presented before or with the previous error if the user is to have any way to figure out what is going on.\r\n\r\nI suppose this could be fixed by:\r\n\r\n1. Turning the Typeable instance warning into an error\r\n2. Checking the missing instance in the existing error for Typeable and suggest that the user should look for hand written instances as a source of the problem.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1dreixeldreixelhttps://gitlab.haskell.org/ghc/ghc/-/issues/8124Possible leaks when using foreign export.2019-07-07T18:46:23Zlennart@augustsson.netPossible leaks when using foreign export.When a Haskell function exported with foreign export is called from outside Haskell a new Task may be allocated for it.
There will be one Task allocated for each OS thread calling into Haskell (this happens in rts_lock()). This Task is, ...When a Haskell function exported with foreign export is called from outside Haskell a new Task may be allocated for it.
There will be one Task allocated for each OS thread calling into Haskell (this happens in rts_lock()). This Task is, by design, never deallocated. This works fine with a small number of threads, but if the external caller generates a lot of threads that die the Haskell RTS will just get more and more Task objects that are never freed. The Task also contains a condition variable and a mutex, which incurs a HANDLE leak on Windows.
I don't see an elegant fix to this, but the attached code remembers the OS thread for "incall" Task, and every so often (every 100 Tasks created) if will scan the Tasks looking for ones where the OS thread is dead, and remove these.
The fix only works on Windows, I'm afraid.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Possible leaks when using foreign export.","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When a Haskell function exported with foreign export is called from outside Haskell a new Task may be allocated for it.\r\nThere will be one Task allocated for each OS thread calling into Haskell (this happens in rts_lock()). This Task is, by design, never deallocated. This works fine with a small number of threads, but if the external caller generates a lot of threads that die the Haskell RTS will just get more and more Task objects that are never freed. The Task also contains a condition variable and a mutex, which incurs a HANDLE leak on Windows.\r\n\r\nI don't see an elegant fix to this, but the attached code remembers the OS thread for \"incall\" Task, and every so often (every 100 Tasks created) if will scan the Tasks looking for ones where the OS thread is dead, and remove these.\r\nThe fix only works on Windows, I'm afraid.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8113Cannot override ghci builtin commands with :def[!]2019-10-23T09:59:13ZduncanCannot override ghci builtin commands with :def[!]In cabal we have a feature called "cabal repl" where it loads ghci with all the appropriate flags for the package or sandbox.
One of the nice things we want to do is extend the `:reload` (and related `:add`, `:load`) so that it calls ou...In cabal we have a feature called "cabal repl" where it loads ghci with all the appropriate flags for the package or sandbox.
One of the nice things we want to do is extend the `:reload` (and related `:add`, `:load`) so that it calls out to `cabal` to run any pre-processors (e.g. hsc2hs, happy, alex etc).
Unfortunately the `:def!` command does not override builtin ghc commands. It looks like it works (`:def` reports the thing) but then the builtin command is still used, e.g.:
```
:def! reload (\_ -> print "yay" >> return "")
:def
the following macros are defined:
reload
:reload
Ok, modules loaded: none.
```
Related to this overriding, is that we also want a way to run the original (the builtin). Technically speaking it's possible using `:undef`, but then it's rather tricky to define again. You have to do something like define reload to call out to cabal, `:undef reload`, `:reload`, `:def reload ...`. The tricky part is that last, we have to tie the knot, because that is the definition of `:reload` so it has to be able to access it's own code, tricky but not impossible (can load it from a file, but ugly).
So ideally we'd have something like `:builtin [cmd] [args]` that bypasses macros and executes the builtin command. Then we could define:
```
:def! reload :! cabal repl --reload ${other_stuff_here}
:builtin :reload
```
And similarly for the others `:add`, `:load` etc.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cannot override ghci builtin commands with :def[!]","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"In cabal we have a feature called \"cabal repl\" where it loads ghci with all the appropriate flags for the package or sandbox.\r\n\r\nOne of the nice things we want to do is extend the `:reload` (and related `:add`, `:load`) so that it calls out to `cabal` to run any pre-processors (e.g. hsc2hs, happy, alex etc).\r\n\r\nUnfortunately the `:def!` command does not override builtin ghc commands. It looks like it works (`:def` reports the thing) but then the builtin command is still used, e.g.:\r\n\r\n{{{\r\n:def! reload (\\_ -> print \"yay\" >> return \"\")\r\n:def\r\nthe following macros are defined:\r\nreload\r\n:reload\r\nOk, modules loaded: none.\r\n}}}\r\n\r\nRelated to this overriding, is that we also want a way to run the original (the builtin). Technically speaking it's possible using `:undef`, but then it's rather tricky to define again. You have to do something like define reload to call out to cabal, `:undef reload`, `:reload`, `:def reload ...`. The tricky part is that last, we have to tie the knot, because that is the definition of `:reload` so it has to be able to access it's own code, tricky but not impossible (can load it from a file, but ugly).\r\n\r\nSo ideally we'd have something like `:builtin [cmd] [args]` that bypasses macros and executes the builtin command. Then we could define:\r\n\r\n{{{\r\n:def! reload :! cabal repl --reload ${other_stuff_here}\r\n:builtin :reload\r\n}}}\r\n\r\nAnd similarly for the others `:add`, `:load` etc.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8103Segfault when passing unboxed Float# and Double# across modules2019-07-07T18:46:28ZJan Stolarekjan.stolarek@ed.ac.ukSegfault when passing unboxed Float# and Double# across modulesConsider this program consisting of two modules:
```
{-# LANGUAGE MagicHash #-}
module AddWraps where
import GHC.Exts
{-# NOINLINE foo #-}
foo :: Double# -> Double# -> Double#
foo a b = (a +## b)
```
```
{-# LANGUAGE MagicHash #-}
mo...Consider this program consisting of two modules:
```
{-# LANGUAGE MagicHash #-}
module AddWraps where
import GHC.Exts
{-# NOINLINE foo #-}
foo :: Double# -> Double# -> Double#
foo a b = (a +## b)
```
```
{-# LANGUAGE MagicHash #-}
module Main where
import AddWraps
float_text = case (0.0## `foo` 1.2##) of
0.0## -> "1"
_ -> "0"
main = putStrLn (float_text)
```
This program segfaults when compiled on i386 with HEAD:
```
[t-jastol@cam-05-unx : ~] $HOME/master-i386/bin/ghc -fforce-recomp add-double-extern.hs
[1 of 2] Compiling AddWraps ( AddWraps.hs, AddWraps.o )
[2 of 2] Compiling Main ( add-double-extern.hs, add-double-extern.o )
Linking add-double-extern ...
[t-jastol@cam-05-unx : ~] ./add-double-extern
Segmentation fault (core dumped)
```
The problem does not occur:
- on x86_64
- on 7.6.3
- when optimizations are turned on
- fot `Int#`, `Word#` and `Char#` - only `Float#` and `Double#` are affected
Segfault happens on line 223 of `rts/ThreadPaused.c` (`switch (info->i.type)`), which probably means that the stack gets corrupted.
It turns out that Cmm generated for the `foo` is the same in both cases:
```
[section "data" {
AddWraps.foo_closure:
const AddWraps.foo_info;
},
AddWraps.foo_slow() // [R1]
{ info_tbl: []
stack_info: arg_space: 20 updfr_space: Just 4
}
{offset
cfx:
_rf9::P32 = R1;
_B2::F64 = F64[Sp];
_B1::F64 = F64[Sp + 8];
D2 = _B1::F64;
D1 = _B2::F64;
R1 = _rf9::P32;
Sp = Sp + 16;
call AddWraps.foo_info(D2, D1, R1) args: 4, res: 0, upd: 4;
}
},
AddWraps.foo_entry() // [D2, D1]
{ info_tbl: [(cfB,
label: AddWraps.foo_info
rep:HeapRep static {
Fun {arity: 2 fun_type: ArgGen [True, True, True, True]} })]
stack_info: arg_space: 4 updfr_space: Just 4
}
{offset
cfB:
_B1::F64 = D2;
_B2::F64 = D1;
goto cfD;
cfD:
_cfA::F64 = %MO_F_Add_W64(_B2::F64, _B1::F64);
D1 = _cfA::F64;
call (P32[Sp])(D1) args: 4, res: 0, upd: 4;
}
}]
```
The difference lies in how the calls are generated. When `foo` is in the same module as caller the generated call looks like this:
```
cjY:
I32[Sp - 8] = stg_bh_upd_frame_info;
P32[Sp - 4] = Hp - 4;
I32[Sp - 12] = ck0;
D2 = 1.2 :: W64;
D1 = 0.0 :: W64;
Sp = Sp - 12;
call Main.foo_info(D2,
D1) returns to ck0, args: 4, res: 4, upd: 12;
ck0:
_sjs::F64 = D1;
Hp = Hp + 12;
if (Hp > HpLim) goto ckf; else goto ckc;
```
Whereas placing `foo` in separate module leads to this code:
```
ck5:
I32[Sp - 8] = stg_bh_upd_frame_info;
P32[Sp - 4] = Hp - 4;
I32[Sp - 12] = ck7;
D1 = 0.0 :: W64;
R1 = AddWraps.foo_closure;
I32[Sp - 24] = stg_ap_d_info;
F64[Sp - 20] = 1.0 :: W64;
Sp = Sp - 24;
call stg_ap_d_fast(D1,
R1) returns to ck7, args: 16, res: 4, upd: 12;
ck7:
_sjP::F64 = D1;
Hp = Hp + 12;
if (Hp > HpLim) goto ckm; else goto ckj;
```
The second version causes a segfault. This currently blocks merging of #6135 patches.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Segfault when passing unboxed Float# and Double# across modules","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this program consisting of two modules:\r\n\r\n{{{\r\n{-# LANGUAGE MagicHash #-}\r\nmodule AddWraps where\r\nimport GHC.Exts\r\n\r\n{-# NOINLINE foo #-}\r\nfoo :: Double# -> Double# -> Double#\r\nfoo a b = (a +## b)\r\n}}}\r\n\r\n{{{\r\n{-# LANGUAGE MagicHash #-}\r\nmodule Main where\r\nimport AddWraps\r\n\r\nfloat_text = case (0.0## `foo` 1.2##) of\r\n 0.0## -> \"1\"\r\n _ -> \"0\"\r\nmain = putStrLn (float_text)\r\n}}}\r\n\r\nThis program segfaults when compiled on i386 with HEAD:\r\n\r\n{{{\r\n[t-jastol@cam-05-unx : ~] $HOME/master-i386/bin/ghc -fforce-recomp add-double-extern.hs\r\n[1 of 2] Compiling AddWraps ( AddWraps.hs, AddWraps.o )\r\n[2 of 2] Compiling Main ( add-double-extern.hs, add-double-extern.o )\r\nLinking add-double-extern ...\r\n[t-jastol@cam-05-unx : ~] ./add-double-extern\r\nSegmentation fault (core dumped)\r\n}}}\r\n\r\nThe problem does not occur:\r\n\r\n * on x86_64\r\n * on 7.6.3\r\n * when optimizations are turned on\r\n * fot `Int#`, `Word#` and `Char#` - only `Float#` and `Double#` are affected\r\n\r\nSegfault happens on line 223 of `rts/ThreadPaused.c` (`switch (info->i.type)`), which probably means that the stack gets corrupted.\r\n\r\nIt turns out that Cmm generated for the `foo` is the same in both cases:\r\n\r\n{{{\r\n[section \"data\" {\r\n AddWraps.foo_closure:\r\n const AddWraps.foo_info;\r\n },\r\n AddWraps.foo_slow() // [R1]\r\n { info_tbl: []\r\n stack_info: arg_space: 20 updfr_space: Just 4\r\n }\r\n {offset\r\n cfx:\r\n _rf9::P32 = R1;\r\n _B2::F64 = F64[Sp];\r\n _B1::F64 = F64[Sp + 8];\r\n D2 = _B1::F64;\r\n D1 = _B2::F64;\r\n R1 = _rf9::P32;\r\n Sp = Sp + 16;\r\n call AddWraps.foo_info(D2, D1, R1) args: 4, res: 0, upd: 4;\r\n }\r\n },\r\n AddWraps.foo_entry() // [D2, D1]\r\n { info_tbl: [(cfB,\r\n label: AddWraps.foo_info\r\n rep:HeapRep static {\r\n Fun {arity: 2 fun_type: ArgGen [True, True, True, True]} })]\r\n stack_info: arg_space: 4 updfr_space: Just 4\r\n }\r\n {offset\r\n cfB:\r\n _B1::F64 = D2;\r\n _B2::F64 = D1;\r\n goto cfD;\r\n cfD:\r\n _cfA::F64 = %MO_F_Add_W64(_B2::F64, _B1::F64);\r\n D1 = _cfA::F64;\r\n call (P32[Sp])(D1) args: 4, res: 0, upd: 4;\r\n }\r\n }]\r\n}}}\r\n\r\nThe difference lies in how the calls are generated. When `foo` is in the same module as caller the generated call looks like this:\r\n\r\n{{{\r\ncjY:\r\n I32[Sp - 8] = stg_bh_upd_frame_info;\r\n P32[Sp - 4] = Hp - 4;\r\n I32[Sp - 12] = ck0;\r\n D2 = 1.2 :: W64;\r\n D1 = 0.0 :: W64;\r\n Sp = Sp - 12;\r\n call Main.foo_info(D2,\r\n D1) returns to ck0, args: 4, res: 4, upd: 12;\r\nck0:\r\n _sjs::F64 = D1;\r\n Hp = Hp + 12;\r\n if (Hp > HpLim) goto ckf; else goto ckc;\r\n}}}\r\n\r\nWhereas placing `foo` in separate module leads to this code:\r\n\r\n{{{\r\nck5:\r\n I32[Sp - 8] = stg_bh_upd_frame_info;\r\n P32[Sp - 4] = Hp - 4;\r\n I32[Sp - 12] = ck7;\r\n D1 = 0.0 :: W64;\r\n R1 = AddWraps.foo_closure;\r\n I32[Sp - 24] = stg_ap_d_info;\r\n F64[Sp - 20] = 1.0 :: W64;\r\n Sp = Sp - 24;\r\n call stg_ap_d_fast(D1,\r\n R1) returns to ck7, args: 16, res: 4, upd: 12;\r\nck7:\r\n _sjP::F64 = D1;\r\n Hp = Hp + 12;\r\n if (Hp > HpLim) goto ckm; else goto ckj;\r\n}}}\r\n\r\nThe second version causes a segfault. This currently blocks merging of #6135 patches.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Jan Stolarekjan.stolarek@ed.ac.ukJan Stolarekjan.stolarek@ed.ac.ukhttps://gitlab.haskell.org/ghc/ghc/-/issues/8101No pattern match non-exhaustiveness warnings when compiling with -fno-code2019-07-07T18:46:29Zexbb2No pattern match non-exhaustiveness warnings when compiling with -fno-code```
{-# OPTIONS_GHC -Wall #-}
module A where
data ABC = A | B | C
abc :: ABC -> Int
abc x = case x of
A -> 1
```
```
$ ghc -fno-code -fforce-recomp /tmp/A.hs
[1 of 1] Compiling A ( /tmp/A.hs, nothing )
```
```
$ g...```
{-# OPTIONS_GHC -Wall #-}
module A where
data ABC = A | B | C
abc :: ABC -> Int
abc x = case x of
A -> 1
```
```
$ ghc -fno-code -fforce-recomp /tmp/A.hs
[1 of 1] Compiling A ( /tmp/A.hs, nothing )
```
```
$ ghc -fobject-code -fforce-recomp /tmp/A.hs
[1 of 1] Compiling A ( /tmp/A.hs, /tmp/A.o )
/tmp/A.hs:7:9: Warning:
Pattern match(es) are non-exhaustive
In a case alternative:
Patterns not matched:
B
C
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| 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":"No pattern match non-exhaustiveness warnings when compiling with -fno-code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# OPTIONS_GHC -Wall #-}\r\nmodule A where\r\n\r\ndata ABC = A | B | C\r\n\r\nabc :: ABC -> Int\r\nabc x = case x of\r\n A -> 1\r\n}}}\r\n{{{\r\n$ ghc -fno-code -fforce-recomp /tmp/A.hs \r\n[1 of 1] Compiling A ( /tmp/A.hs, nothing )\r\n}}}\r\n{{{\r\n$ ghc -fobject-code -fforce-recomp /tmp/A.hs \r\n[1 of 1] Compiling A ( /tmp/A.hs, /tmp/A.o )\r\n\r\n/tmp/A.hs:7:9: Warning:\r\n Pattern match(es) are non-exhaustive\r\n In a case alternative:\r\n Patterns not matched:\r\n B\r\n C\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8083setNumCapabilities broken in HEAD2019-07-07T18:46:34ZparcssetNumCapabilities broken in HEAD```haskell
import GHC.Conc
import Control.Monad
main :: IO ()
main = do
n <- getNumCapabilities
when (n == 1) $ setNumCapabilities 2
print ()
```
One would expect this program to print () just once, but when compiled with -...```haskell
import GHC.Conc
import Control.Monad
main :: IO ()
main = do
n <- getNumCapabilities
when (n == 1) $ setNumCapabilities 2
print ()
```
One would expect this program to print () just once, but when compiled with -O or -O2 it prints () repeatedly and indefinitely!
This doesn't happen on GHC 7.6.2 or 7.4.1, only on HEAD.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"setNumCapabilities broken in HEAD","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n#!haskell\r\nimport GHC.Conc\r\nimport Control.Monad\r\n\r\nmain :: IO ()\r\nmain = do\r\n n <- getNumCapabilities\r\n when (n == 1) $ setNumCapabilities 2\r\n print ()\r\n}}}\r\n\r\nOne would expect this program to print () just once, but when compiled with -O or -O2 it prints () repeatedly and indefinitely!\r\n\r\nThis doesn't happen on GHC 7.6.2 or 7.4.1, only on HEAD.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8073TransformListComp weird type error2019-07-07T18:46:36ZSimon MarlowTransformListComp weird type errorAm I missing something, or is this broken?
```
Prelude> :set -XTransformListComp
Prelude> import Data.List
Prelude Data.List> [ x | x <- ['a'..'z'], then sort]
<interactive>:5:29:
No instance for (Ord a) arising from a use of `sor...Am I missing something, or is this broken?
```
Prelude> :set -XTransformListComp
Prelude> import Data.List
Prelude Data.List> [ x | x <- ['a'..'z'], then sort]
<interactive>:5:29:
No instance for (Ord a) arising from a use of `sort'
Possible fix:
add (Ord a) to the context of
a type expected by the context: [a] -> [a]
In the expression: sort
In a stmt of a list comprehension: then sort
In the expression: [x | x <- ['a' .. 'z'], then sort]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TransformListComp weird type error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Am I missing something, or is this broken?\r\n\r\n{{{\r\nPrelude> :set -XTransformListComp \r\nPrelude> import Data.List\r\nPrelude Data.List> [ x | x <- ['a'..'z'], then sort]\r\n\r\n<interactive>:5:29:\r\n No instance for (Ord a) arising from a use of `sort'\r\n Possible fix:\r\n add (Ord a) to the context of\r\n a type expected by the context: [a] -> [a]\r\n In the expression: sort\r\n In a stmt of a list comprehension: then sort\r\n In the expression: [x | x <- ['a' .. 'z'], then sort]\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1