GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:13:41Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/1405Make ghc (stage1) be compilable by non-GHC2019-07-07T19:13:41ZIsaac DupreeMake ghc (stage1) be compilable by non-GHCThis depends a bit on the existence of a good-enough non-GHC compiler. Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet. Also pattern guards might need...This depends a bit on the existence of a good-enough non-GHC compiler. Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet. Also pattern guards might need to be implemented in that compiler. Maybe for testing, a ghc that doesn't define __GLASGOW_HASKELL__ (and doesn't use ghc-specific flags ?? possibly a wrapper script of some sort) could be used too.
See http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962 ... GHC also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that everyone provides, but would still be good to document.
I'm working on this now, we'll see how far I get --Isaac⊥https://gitlab.haskell.org/ghc/ghc/-/issues/1406Constraint doesn't reduce in the presence of quantified type variables2019-07-07T19:13:41ZccshanConstraint doesn't reduce in the presence of quantified type variables```
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
module Problem where
data Z
data S a
class HPrefix l
instance (NSub (S Z) ndiff, HDrop ndiff l l) => HPrefix l
class NSub n1 n3 | n1 -> n3
instance NSub...```
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
module Problem where
data Z
data S a
class HPrefix l
instance (NSub (S Z) ndiff, HDrop ndiff l l) => HPrefix l
class NSub n1 n3 | n1 -> n3
instance NSub Z Z
instance NSub n1 n3 => NSub (S n1) n3
class HDrop n l1 l2 | n l1 -> l2
instance HDrop Z l l
t_hPrefix :: HPrefix l => l -> ()
t_hPrefix = undefined
-- This works...
thr' :: (forall r. l -> a) -> a
thr' f = f undefined
thP4' = thr' t_hPrefix
-- ... but this doesn't work...?
thr :: (forall r. r -> a) -> a
thr f = f undefined
thP4 = thr t_hPrefix
```
```
$ ghci GHCProblem.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done.
[1 of 1] Compiling Problem ( GHCProblem.hs, interpreted )
GHCProblem.hs:30:11:
No instance for (HDrop ndiff r r)
arising from use of `t_hPrefix' at GHCProblem.hs:30:11-19
Possible fix:
add (HDrop ndiff r r) to the expected type of an expression
In the first argument of `thr', namely `t_hPrefix'
In the expression: thr t_hPrefix
In the definition of `thP4': thP4 = thr t_hPrefix
Failed, modules loaded: none.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Constraint doesn't reduce in the presence of quantified type variables","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\n{-# OPTIONS -fallow-undecidable-instances #-}\r\n\r\nmodule Problem where\r\n\r\ndata Z\r\ndata S a\r\n\r\nclass HPrefix l\r\ninstance (NSub (S Z) ndiff, HDrop ndiff l l) => HPrefix l\r\n\r\nclass NSub n1 n3 | n1 -> n3\r\ninstance NSub Z Z\r\ninstance NSub n1 n3 => NSub (S n1) n3\r\n\r\nclass HDrop n l1 l2 | n l1 -> l2\r\ninstance HDrop Z l l\r\n\r\nt_hPrefix :: HPrefix l => l -> ()\r\nt_hPrefix = undefined\r\n\r\n-- This works...\r\nthr' :: (forall r. l -> a) -> a\r\nthr' f = f undefined\r\nthP4' = thr' t_hPrefix\r\n\r\n-- ... but this doesn't work...?\r\nthr :: (forall r. r -> a) -> a\r\nthr f = f undefined\r\nthP4 = thr t_hPrefix\r\n}}}\r\n{{{\r\n$ ghci GHCProblem.hs \r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Problem ( GHCProblem.hs, interpreted )\r\n\r\nGHCProblem.hs:30:11:\r\n No instance for (HDrop ndiff r r)\r\n arising from use of `t_hPrefix' at GHCProblem.hs:30:11-19\r\n Possible fix:\r\n add (HDrop ndiff r r) to the expected type of an expression\r\n In the first argument of `thr', namely `t_hPrefix'\r\n In the expression: thr t_hPrefix\r\n In the definition of `thP4': thP4 = thr t_hPrefix\r\nFailed, modules loaded: none.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1407Add the ability to :set -l{foo} in .ghci files2019-07-07T19:13:40ZguestAdd the ability to :set -l{foo} in .ghci filesCurrently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ...Currently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ignored in both 6.4.2 and 6.6.
The only other place it would make sense to pass it would be as something like OPTIONS_GHC, but that results in "unknown flags in {-\# OPTIONS \#-} pragma: -lidn" in 6.4.2 and appears to be silently ignored in 6.6.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| 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":"Add the ability to :set -l{foo} in .ghci files","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":"FeatureRequest","description":"Currently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ignored in both 6.4.2 and 6.6.\r\n\r\nThe only other place it would make sense to pass it would be as something like OPTIONS_GHC, but that results in \"unknown flags in {-# OPTIONS #-} pragma: -lidn\" in 6.4.2 and appears to be silently ignored in 6.6.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3archblobarchblobhttps://gitlab.haskell.org/ghc/ghc/-/issues/1408groupWhen – a groupBy that compares consecutive values2019-07-07T19:13:40ZJoachim Breitner <mail@joachim-breitner.de>groupWhen – a groupBy that compares consecutive values`groupBy` has a minor problem: It always uses the first value of a group to decide whether a new value belongs to this group or the next. In several cases it would be more useful if it would take the last value of a group, thus always co...`groupBy` has a minor problem: It always uses the first value of a group to decide whether a new value belongs to this group or the next. In several cases it would be more useful if it would take the last value of a group, thus always comparing consecutive values.
Example code:
```
groupWhen :: (a -> a -> Bool) -> [a] -> [[a]]
groupWhen _ [] = []
groupWhen _ [a] = [[a]]
groupWhen f (a:l) = if f a (head c) then (a:c):r
else [a]:c:r
where (c:r) = groupWhen f l
```
Uses:
```
groupWhen (\a b -> b - a < 5) [1,2,4,10,14,16,18] -- Finding holes in a increasing series, e.g. log time stamps (my real use case)
```
or
```
groupWhen (<) [1,2,3,2,10,12,10,11] -- Group into strictly increasing sublists
```
Note that for transitive and symetrical comparision functions `f` (such as `(==)`), `groupBy f == groupWhen f`.
It should probably go to Data.List
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| 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":"groupWhen – a groupBy that compares consecutive values","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"`groupBy` has a minor problem: It always uses the first value of a group to decide whether a new value belongs to this group or the next. In several cases it would be more useful if it would take the last value of a group, thus always comparing consecutive values.\r\n\r\nExample code:\r\n{{{\r\ngroupWhen :: (a -> a -> Bool) -> [a] -> [[a]]\r\ngroupWhen _ [] = []\r\ngroupWhen _ [a] = [[a]]\r\ngroupWhen f (a:l) = if f a (head c) then (a:c):r\r\n else [a]:c:r\r\n where (c:r) = groupWhen f l\r\n}}}\r\n\r\nUses:\r\n{{{\r\ngroupWhen (\\a b -> b - a < 5) [1,2,4,10,14,16,18] -- Finding holes in a increasing series, e.g. log time stamps (my real use case)\r\n}}}\r\nor\r\n{{{\r\ngroupWhen (<) [1,2,3,2,10,12,10,11] -- Group into strictly increasing sublists\r\n}}}\r\n\r\n\r\nNote that for transitive and symetrical comparision functions `f` (such as `(==)`), `groupBy f == groupWhen f`.\r\n\r\nIt should probably go to Data.List","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1410Control.Monad.Reader documentation2019-07-07T19:13:40ZguestControl.Monad.Reader documentationAdded Haddock documentation. Converted the existing module documentation to Haddock format. Created examples. Per Jeff Newberns permission included parts his tutorial "All About Monads" http://haskell.org/all_about_monads/.
<details><su...Added Haddock documentation. Converted the existing module documentation to Haddock format. Created examples. Per Jeff Newberns permission included parts his tutorial "All About Monads" http://haskell.org/all_about_monads/.
<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 | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Control.Monad.Reader documentation","status":"New","operating_system":"Multiple","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Added Haddock documentation. Converted the existing module documentation to Haddock format. Created examples. Per Jeff Newberns permission included parts his tutorial \"All About Monads\" http://haskell.org/all_about_monads/.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/1411Typo in type error for lazy patterns2019-07-07T19:13:39ZguestTypo in type error for lazy patternsThere's a small typo in one of the type-error messages for lazy patterns. I've attached a patch that fixes it.
\[Corrected typo in compiler/typecheck/TcPat.lhs:
stefan\@cs.uu.nl\*\*20070601054931
- connot ===\> cannot
\] {
hunk ./comp...There's a small typo in one of the type-error messages for lazy patterns. I've attached a patch that fixes it.
\[Corrected typo in compiler/typecheck/TcPat.lhs:
stefan\@cs.uu.nl\*\*20070601054931
- connot ===\> cannot
\] {
hunk ./compiler/typecheck/TcPat.lhs 958
- hang (ptext SLIT("A lazy (\~) pattern connot bind existential type variables
"))
+ hang (ptext SLIT("A lazy (\~) pattern cannot bind existential type variables
"))
}
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Typo in type error for lazy patterns","status":"New","operating_system":"Multiple","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":["typo"],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"There's a small typo in one of the type-error messages for lazy patterns. I've attached a patch that fixes it.\r\n\r\n[Corrected typo in compiler/typecheck/TcPat.lhs:\r\nstefan@cs.uu.nl**20070601054931\r\n * connot ===> cannot\r\n] {\r\nhunk ./compiler/typecheck/TcPat.lhs 958\r\n- hang (ptext SLIT(\"A lazy (~) pattern connot bind existential type variables\r\n\"))\r\n+ hang (ptext SLIT(\"A lazy (~) pattern cannot bind existential type variables\r\n\"))\r\n}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1412Typo in type error for lazy patterns2019-07-07T19:13:39Zstefan@cs.uu.nlTypo in type error for lazy patternsThere's a small typo in one of the type-error messages for lazy patterns. I've attached a patch that fixes it.
\[Corrected typo in compiler/typecheck/TcPat.lhs:
stefan\@cs.uu.nl\*\*20070601054931
- connot ===\> cannot
\] {
hunk ./comp...There's a small typo in one of the type-error messages for lazy patterns. I've attached a patch that fixes it.
\[Corrected typo in compiler/typecheck/TcPat.lhs:
stefan\@cs.uu.nl\*\*20070601054931
- connot ===\> cannot
\] {
hunk ./compiler/typecheck/TcPat.lhs 958
- hang (ptext SLIT("A lazy (\~) pattern connot bind existential type variables
"))
+ hang (ptext SLIT("A lazy (\~) pattern cannot bind existential type variables
"))
}
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Typo in type error for lazy patterns","status":"New","operating_system":"Multiple","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":["typo"],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"There's a small typo in one of the type-error messages for lazy patterns. I've attached a patch that fixes it.\r\n\r\n[Corrected typo in compiler/typecheck/TcPat.lhs:\r\nstefan@cs.uu.nl**20070601054931\r\n * connot ===> cannot\r\n] {\r\nhunk ./compiler/typecheck/TcPat.lhs 958\r\n- hang (ptext SLIT(\"A lazy (~) pattern connot bind existential type variables\r\n\"))\r\n+ hang (ptext SLIT(\"A lazy (~) pattern cannot bind existential type variables\r\n\"))\r\n}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1413copyFile: atomicity docs/code mismatch2019-07-07T19:13:39ZguestcopyFile: atomicity docs/code mismatchhttp://haskell.org/ghc/docs/latest/html/libraries/base/System-Directory.html\#v%3AcopyFile says:
> copyFile old new copies the existing file from old to new. If the new file already exists, it is *atomically replaced* by the old file. N...http://haskell.org/ghc/docs/latest/html/libraries/base/System-Directory.html\#v%3AcopyFile says:
> copyFile old new copies the existing file from old to new. If the new file already exists, it is *atomically replaced* by the old file. Neither path may refer to an existing directory. The permissions of old are copied to new, if possible.
AFAIK the only way to do atomic replacement is to write to a temporary file, then rename it over the target. However, strace shows that copyFile does open(), ftruncate(), then multiple write()s; this is clearly not atomic.
Conclusion: Either the docs or the code are wrong.
<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":"copyFile: atomicity docs/code mismatch","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":"http://haskell.org/ghc/docs/latest/html/libraries/base/System-Directory.html#v%3AcopyFile says:\r\n\r\n copyFile old new copies the existing file from old to new. If the new file already exists, it is ''atomically replaced'' by the old file. Neither path may refer to an existing directory. The permissions of old are copied to new, if possible.\r\n\r\nAFAIK the only way to do atomic replacement is to write to a temporary file, then rename it over the target. However, strace shows that copyFile does open(), ftruncate(), then multiple write()s; this is clearly not atomic.\r\n\r\nConclusion: Either the docs or the code are wrong.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1414CString marshalling functions do not perform the specified conversion2019-07-07T19:13:39ZRoss Patersonr.paterson@city.ac.ukCString marshalling functions do not perform the specified conversionThe `CString` and `CStringLen` marshalling functions are specified in the FFI addendum as performing a locale-based conversion, but this is not implemented.
<details><summary>Trac metadata</summary>
| Trac field | Value ...The `CString` and `CStringLen` marshalling functions are specified in the FFI addendum as performing a locale-based conversion, but this is not implemented.
<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":"CString marshalling functions do not perform the specified conversion","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":"The `CString` and `CStringLen` marshalling functions are specified in the FFI addendum as performing a locale-based conversion, but this is not implemented.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/1415Provide a way to runInteractiveCommand without passing all your filedescriptors2019-07-07T19:13:38ZIan Lynagh <igloo@earth.li>Provide a way to runInteractiveCommand without passing all your filedescriptorsWe should make it easy for people to write secure programs, and currently
it's non-trivial to run another program without giving it all of your
file descriptors etc.
See the thread starting
http://www.haskell.org/pipermail/libraries/200...We should make it easy for people to write secure programs, and currently
it's non-trivial to run another program without giving it all of your
file descriptors etc.
See the thread starting
http://www.haskell.org/pipermail/libraries/2007-June/007566.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| 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":"Provide a way to runInteractiveCommand without passing all your filedescriptors","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"We should make it easy for people to write secure programs, and currently\r\nit's non-trivial to run another program without giving it all of your\r\nfile descriptors etc.\r\n\r\nSee the thread starting\r\nhttp://www.haskell.org/pipermail/libraries/2007-June/007566.html","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1416Testsuite doesn't always work on MSYS with Cygwin Python2019-07-07T19:13:38ZSimon Peyton JonesTestsuite doesn't always work on MSYS with Cygwin Python**Problem 1**. Using the Cygwin Python. `testsuite/mk/test.mk` makes the GHC into `ghc-inplace.bat`. But `testlib.py` (the `runCmd` procedure) invokes `timeout`, which always calls a Bourne shell, so `ghc-inplace.bat` doesn't work.
The ...**Problem 1**. Using the Cygwin Python. `testsuite/mk/test.mk` makes the GHC into `ghc-inplace.bat`. But `testlib.py` (the `runCmd` procedure) invokes `timeout`, which always calls a Bourne shell, so `ghc-inplace.bat` doesn't work.
The timeout program must use a Bourne shell, because `testlib.py` often passes it a complex command in Bourne shell syntax.
Current workaound: in `testsuite\mk\test.mk` disable the windows-specific setting of the GHC paths.
**IDEA**: it's a mess having a `ghc-inplace` shell script *and* a `ghc-inplace.bat` script. Instead we should have one executable, which we can invoke from anywhere.
*PS* Why should we care about Cygwin Python and MSYS? Well, it's exposed a fragility with this ghc-inplace stuff; and the testsuite doesn't work with native Python under MSYS either.6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1417Add pseudoterminal support to the unix package2019-07-07T19:13:38ZbosAdd pseudoterminal support to the unix packageI propose to enhance the unix package by adding pty support:
-- \| \@openPseudoTerminal@ creates a pseudoterminal (pty) pair, and
-- returns the newly created pair as a (\@master@, \@slave@) tuple.
openPseudoTerminal :: IO (Fd, Fd)
-- ...I propose to enhance the unix package by adding pty support:
-- \| \@openPseudoTerminal@ creates a pseudoterminal (pty) pair, and
-- returns the newly created pair as a (\@master@, \@slave@) tuple.
openPseudoTerminal :: IO (Fd, Fd)
-- \| \@getSlaveTerminalName@ calls \@ptsname@ to obtain the name of the
-- slave terminal associated with a pseudoterminal pair. The file
-- descriptor to pass in must be that of the master.
getSlaveTerminalName :: Fd -\> IO FilePath
This is all that's required to get pseudoterminals working on Unix-like systems.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Add pseudoterminal support to the unix package","status":"New","operating_system":"Unknown","component":"libraries/unix","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I propose to enhance the unix package by adding pty support:\r\n\r\n-- | @openPseudoTerminal@ creates a pseudoterminal (pty) pair, and\r\n-- returns the newly created pair as a (@master@, @slave@) tuple.\r\nopenPseudoTerminal :: IO (Fd, Fd)\r\n\r\n-- | @getSlaveTerminalName@ calls @ptsname@ to obtain the name of the\r\n-- slave terminal associated with a pseudoterminal pair. The file\r\n-- descriptor to pass in must be that of the master.\r\ngetSlaveTerminalName :: Fd -> IO FilePath\r\n\r\nThis is all that's required to get pseudoterminals working on Unix-like systems.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/1418Heap profiling woes2019-07-07T19:13:38ZguestHeap profiling woesI have a large program with a space leak. So I want to heap profiling, of course.
Here's what happens:
I compile with -prof -auto-all and run with -hc. All (99%) allocation is attributed to Main.CAF.
I add -caf-all, run with -hc. All a...I have a large program with a space leak. So I want to heap profiling, of course.
Here's what happens:
I compile with -prof -auto-all and run with -hc. All (99%) allocation is attributed to Main.CAF.
I add -caf-all, run with -hc. All allocation is attributed to Main.main.
I try running with -hd. The program segfaults.
I try running with -hy. The program segfaults.
I try running with -hb. The program dies with a GHC RTS internal error.
I try running with -hr. The generated profile cannot be read by hp2ps because it's truncated.
I edit the truncated file by hand. The allocation is now split between main and SYSTEM.
> -- Lennart
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart.augustsson@credit-suisse.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Heap profiling woes","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart.augustsson@credit-suisse.com"],"type":"Bug","description":"I have a large program with a space leak. So I want to heap profiling, of course.\r\nHere's what happens:\r\n\r\nI compile with -prof -auto-all and run with -hc. All (99%) allocation is attributed to Main.CAF.\r\n\r\nI add -caf-all, run with -hc. All allocation is attributed to Main.main.\r\n\r\nI try running with -hd. The program segfaults.\r\n\r\nI try running with -hy. The program segfaults.\r\n\r\nI try running with -hb. The program dies with a GHC RTS internal error.\r\n\r\nI try running with -hr. The generated profile cannot be read by hp2ps because it's truncated.\r\n\r\nI edit the truncated file by hand. The allocation is now split between main and SYSTEM.\r\n\r\n -- Lennart","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1419"GHC as a library" stalls when nobody is consuming it's output2019-07-07T19:13:37ZSimon Marlow"GHC as a library" stalls when nobody is consuming it's outputReported by Mads Lindstrøm \<mads_lindstroem\@yahoo.dk\> on glasgow-haskell-users:
While trying to implement a GUI for GHCi, I have run into an annoying
concurrency problems. I think "GHC as a library" is at fault, as it
stalls (maybe s...Reported by Mads Lindstrøm \<mads_lindstroem\@yahoo.dk\> on glasgow-haskell-users:
While trying to implement a GUI for GHCi, I have run into an annoying
concurrency problems. I think "GHC as a library" is at fault, as it
stalls (maybe some deadlock) when nobody is consuming it's output.
This message is a literate Haskell program, which illustrates the
problem.
This test-program starts a thread which prints an 'A' on stderr every
second. Then it wait three seconds (meanwhile the 'A's are printing),
and runs, via "GHC as a library", the following Haskell code "\[1..\]".
If I start the program as:
```
./IsGhcBlocking >/dev/null
```
everything works fine and the 'A' keeps coming out on stderr.
However, if I do:
```
./IsGhcBlocking | sleep 10
```
I only see three 'A's. I believe that is because the sleep-command, do
not consume any input.
The program was tested on Debian Etch running GHC 6.6.
```
> module Main where
>
Compile with: ghc -threaded -package ghc-6.6 --make IsGhcBlocking.lhs
> import qualified GHC as GHC
> import qualified Outputable as GHC
> import qualified Packages as GHC
> import qualified DynFlags as GHC
> import qualified ErrUtils as GHC
>
> import System.IO
> import Control.Concurrent
> -- the path of our GHC 6.6 installation
> path :: FilePath
> -- path = "c:\\ghc-6.6"
> path = "/usr/lib/ghc-6.6/"
>
> main :: IO()
> main = do let printAs = do threadDelay (10^6)
> hPutStrLn stderr "A"
> printAs
> forkOS printAs -- forkIO gives the same result
> threadDelay (10^6 * 3)
> session <- initializeSession
> GHC.runStmt session "[1..]"
> return ()
>
> initializeSession =
> do session <- GHC.newSession GHC.Interactive (Just path)
>
> -- initialize the default packages
> dflags0 <- GHC.getSessionDynFlags session
> let myLogAction _ locSpec style errMsg = hPutStrLn stderr showMsg where
> showMsg = GHC.showSDoc $ GHC.withPprStyle style $ GHC.mkLocMessage locSpec errMsg
> dflags1 = dflags0 { GHC.log_action = myLogAction }
> (dflags2, packageIds) <- GHC.initPackages dflags1
> GHC.setSessionDynFlags session dflags2{GHC.hscTarget=GHC.HscInterpreted}
> GHC.setContext session [] []
> return session
```
The stalling becomes a problem, when one wants to interrupt "GHC as a
library"'s runStmt function. One could interrupt "GHC as a library" with
Panic.interruptTargetThread (see
http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/12289). However,
as "GHC as a library" locks up (stalls, deadlocks) there is no way of
executing Panic.interruptTargetThread.
Some people may suggest that I should always consume the output from
"GHC as a library". But that is easier said than done. Many GUI
libraries (including !WxHaskell, which I am using) only allows for one
active thread at a time (see
http://wxhaskell.sourceforge.net/faq.html). Thus my GUI cannot
simultaneously tell "GHC as a library" to interrupt it's execution and
read it's output.
For thus wondering how I can run both a GUI and "GHC as a library", if
!WxHaskell is not happy about threading, the answer is that I run the
GUI and "GHC as a library" in separate processes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"\"GHC as a library\" stalls when nobody is consuming it's output","status":"New","operating_system":"Unknown","component":"GHC API","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Reported by Mads Lindstrøm <mads_lindstroem@yahoo.dk> on glasgow-haskell-users:\r\n\r\nWhile trying to implement a GUI for GHCi, I have run into an annoying\r\nconcurrency problems. I think \"GHC as a library\" is at fault, as it\r\nstalls (maybe some deadlock) when nobody is consuming it's output.\r\n\r\nThis message is a literate Haskell program, which illustrates the\r\nproblem.\r\n\r\nThis test-program starts a thread which prints an 'A' on stderr every\r\nsecond. Then it wait three seconds (meanwhile the 'A's are printing),\r\nand runs, via \"GHC as a library\", the following Haskell code \"[1..]\".\r\n\r\nIf I start the program as:\r\n{{{\r\n./IsGhcBlocking >/dev/null\r\n}}}\r\neverything works fine and the 'A' keeps coming out on stderr.\r\n\r\nHowever, if I do:\r\n{{{\r\n./IsGhcBlocking | sleep 10\r\n}}}\r\nI only see three 'A's. I believe that is because the sleep-command, do\r\nnot consume any input.\r\n\r\nThe program was tested on Debian Etch running GHC 6.6.\r\n{{{\r\n> module Main where\r\n> \r\n\r\nCompile with: ghc -threaded -package ghc-6.6 --make IsGhcBlocking.lhs\r\n\r\n> import qualified GHC as GHC\r\n> import qualified Outputable as GHC\r\n> import qualified Packages as GHC\r\n> import qualified DynFlags as GHC\r\n> import qualified ErrUtils as GHC\r\n> \r\n> import System.IO\r\n> import Control.Concurrent\r\n\r\n> -- the path of our GHC 6.6 installation\r\n> path :: FilePath\r\n> -- path = \"c:\\\\ghc-6.6\"\r\n> path = \"/usr/lib/ghc-6.6/\"\r\n> \r\n> main :: IO()\r\n> main = do let printAs = do threadDelay (10^6)\r\n> hPutStrLn stderr \"A\"\r\n> printAs\r\n> forkOS printAs -- forkIO gives the same result\r\n> threadDelay (10^6 * 3)\r\n> session <- initializeSession\r\n> GHC.runStmt session \"[1..]\"\r\n> return ()\r\n> \r\n> initializeSession =\r\n> do session <- GHC.newSession GHC.Interactive (Just path)\r\n> \r\n> -- initialize the default packages\r\n> dflags0 <- GHC.getSessionDynFlags session\r\n> let myLogAction _ locSpec style errMsg = hPutStrLn stderr showMsg where\r\n> showMsg = GHC.showSDoc $ GHC.withPprStyle style $ GHC.mkLocMessage locSpec errMsg\r\n> dflags1 = dflags0 { GHC.log_action = myLogAction }\r\n> (dflags2, packageIds) <- GHC.initPackages dflags1\r\n> GHC.setSessionDynFlags session dflags2{GHC.hscTarget=GHC.HscInterpreted}\r\n> GHC.setContext session [] []\r\n> return session\r\n}}}\r\nThe stalling becomes a problem, when one wants to interrupt \"GHC as a\r\nlibrary\"'s runStmt function. One could interrupt \"GHC as a library\" with\r\nPanic.interruptTargetThread (see\r\nhttp://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/12289). However,\r\nas \"GHC as a library\" locks up (stalls, deadlocks) there is no way of\r\nexecuting Panic.interruptTargetThread.\r\n\r\nSome people may suggest that I should always consume the output from\r\n\"GHC as a library\". But that is easier said than done. Many GUI\r\nlibraries (including !WxHaskell, which I am using) only allows for one\r\nactive thread at a time (see\r\nhttp://wxhaskell.sourceforge.net/faq.html). Thus my GUI cannot\r\nsimultaneously tell \"GHC as a library\" to interrupt it's execution and\r\nread it's output.\r\n\r\nFor thus wondering how I can run both a GUI and \"GHC as a library\", if\r\n!WxHaskell is not happy about threading, the answer is that I run the\r\nGUI and \"GHC as a library\" in separate processes.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1421elf object code problem exposed when linking under i386 Solaris 102019-07-07T19:13:37ZChristian Maederelf object code problem exposed when linking under i386 Solaris 10The object code generated for i386 Solaris 10 can not be linked with newer solaris linkers.
It works for:
```
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.486
```
and probably for all other linkers before 5.11-1.55...The object code generated for i386 Solaris 10 can not be linked with newer solaris linkers.
It works for:
```
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.486
```
and probably for all other linkers before 5.11-1.554 (and gnu linkers)
It fails for:
```
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.555
```
and probably for 5.11-1.554 and newer ones, too
The failure message is as follows:
```
Linking hello ...
ld: fatal: symbol `GHC_ZCCReturnable_static_info' in file /export/home/sparvu/ghcnew/lib/ghc-6.6.1/libHSrts.a(PrimOps.o): section [1] .text: size 8464: symbol (address 0x2110, size 4) lies outside of containing section
ld: fatal: File processing errors. No output written to hello
collect2: ld returned 1 exit status
```
In fact `elfdump(1)` (for ld 5.10-1.486) displays:
```
Section Header[1]: sh_name: .text
sh_addr: 0 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ]
sh_size: 0x2110 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x34 sh_entsize: 0
sh_link: 0 sh_info: 0
```
and
```
Symbol Table Section: .symtab
index value size type bind oth ver shndx name
[...]
[200] 0x0000210c 0x00000004 OBJT GLOB D 0 .text GHC_ZCCCallable_static_info
[201] 0x00002110 0x00000004 OBJT GLOB D 0 .text GHC_ZCCReturnable_static_info
```
The same size problem is described under:
http://www.opensolaris.org/jive/thread.jspa?threadID=32325&tstart=0
for the splitted object file `Utils__90.o`.
I've found a possible related link here:
http://hackage.haskell.org/trac/ghc/changeset/8920
Rod.Evans at sun.com wrote:
```
The checking we've added was under:
6488141 ld(1) should detect attempt to reference 0-length .bss section
integrated in Nevada snv_54. It stemmed from our compiler development
giving ld(1) some bad files that resulted in us core dumping. An ld(1)
that reported:
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.554
would have been the first to contain the above "bug fix". I don't
believe this change has found its way back to a Solaris 10 port yet.
```
and
```
We'd be happy to work with you directly to investigate things.
```
simonmarhaskell at gmail.com wrote:
I'm guessing the bogus .size information is a result of the reorganisation of the .s file that we do before assembling it: gcc inserts .size directives, we move things around in the .s, and at the end it the .size directives aren't right any more.
The only reason we keep the .size directives around at all is because certain tools (like Valgind for example) don't work without .size information. GHC itself, including our dynamic linker, works fine without it.
I can't tell exactly what has gone wrong in this particular instance - you'll need to compile the offending module with -keep-raw-s-file -keep-s-file and inspect those .size directives.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| 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":"elf object code problem exposed when linking under i386 Solaris 10","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The object code generated for i386 Solaris 10 can not be linked with newer solaris linkers.\r\n\r\nIt works for: \r\n{{{\r\nld: Software Generation Utilities - Solaris Link Editors: 5.10-1.486\r\n}}}\r\nand probably for all other linkers before 5.11-1.554 (and gnu linkers)\r\n\r\nIt fails for:\r\n{{{\r\nld: Software Generation Utilities - Solaris Link Editors: 5.11-1.555\r\n}}}\r\nand probably for 5.11-1.554 and newer ones, too\r\n\r\nThe failure message is as follows:\r\n{{{\r\nLinking hello ...\r\nld: fatal: symbol `GHC_ZCCReturnable_static_info' in file /export/home/sparvu/ghcnew/lib/ghc-6.6.1/libHSrts.a(PrimOps.o): section [1] .text: size 8464: symbol (address 0x2110, size 4) lies outside of containing section\r\nld: fatal: File processing errors. No output written to hello\r\ncollect2: ld returned 1 exit status\r\n}}}\r\n\r\nIn fact `elfdump(1)` (for ld 5.10-1.486) displays:\r\n{{{\r\nSection Header[1]: sh_name: .text\r\n sh_addr: 0 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ]\r\n sh_size: 0x2110 sh_type: [ SHT_PROGBITS ]\r\n sh_offset: 0x34 sh_entsize: 0\r\n sh_link: 0 sh_info: 0\r\n}}}\r\n\r\nand\r\n\r\n{{{\r\nSymbol Table Section: .symtab\r\n index value size type bind oth ver shndx name\r\n[...]\r\n [200] 0x0000210c 0x00000004 OBJT GLOB D 0 .text GHC_ZCCCallable_static_info\r\n [201] 0x00002110 0x00000004 OBJT GLOB D 0 .text GHC_ZCCReturnable_static_info\r\n}}}\r\n\r\nThe same size problem is described under:\r\nhttp://www.opensolaris.org/jive/thread.jspa?threadID=32325&tstart=0\r\nfor the splitted object file `Utils__90.o`.\r\n\r\nI've found a possible related link here:\r\nhttp://hackage.haskell.org/trac/ghc/changeset/8920\r\n\r\nRod.Evans at sun.com wrote:\r\n{{{\r\n\r\nThe checking we've added was under:\r\n\r\n 6488141 ld(1) should detect attempt to reference 0-length .bss section\r\n\r\nintegrated in Nevada snv_54. It stemmed from our compiler development\r\ngiving ld(1) some bad files that resulted in us core dumping. An ld(1)\r\nthat reported:\r\n\r\n ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.554\r\n\r\nwould have been the first to contain the above \"bug fix\". I don't\r\nbelieve this change has found its way back to a Solaris 10 port yet.\r\n}}}\r\n\r\nand\r\n\r\n{{{\r\nWe'd be happy to work with you directly to investigate things.\r\n}}}\r\n\r\nsimonmarhaskell at gmail.com wrote:\r\n\r\nI'm guessing the bogus .size information is a result of the reorganisation of the .s file that we do before assembling it: gcc inserts .size directives, we move things around in the .s, and at the end it the .size directives aren't right any more.\r\n\r\nThe only reason we keep the .size directives around at all is because certain tools (like Valgind for example) don't work without .size information. GHC itself, including our dynamic linker, works fine without it.\r\n\r\nI can't tell exactly what has gone wrong in this particular instance - you'll need to compile the offending module with -keep-raw-s-file -keep-s-file and inspect those .size directives.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1422wrong warning for exporting all constructors of a void type2019-07-07T19:13:37ZSamuel Bronsonwrong warning for exporting all constructors of a void type```
{-# LANGUAGE EmptyDataDecls #-}
module WrongExportWarning (Empty(..)) where
data Empty
```
produces the incorrect warning:
```
WrongExportWarning.hs:3:27:
Warning: The export item `Empty(..)'
suggests that `Empty...```
{-# LANGUAGE EmptyDataDecls #-}
module WrongExportWarning (Empty(..)) where
data Empty
```
produces the incorrect warning:
```
WrongExportWarning.hs:3:27:
Warning: The export item `Empty(..)'
suggests that `Empty' has constructor or class methods
but it has none; it is a type synonym or abstract type or class
```
If this was already fixed, I state in my defense that trac's search sucks.
<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":"wrong warning for exporting all constructors of a void type","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":"{{{\r\n{-# LANGUAGE EmptyDataDecls #-}\r\n\r\nmodule WrongExportWarning (Empty(..)) where\r\n\r\ndata Empty\r\n}}}\r\n\r\nproduces the incorrect warning:\r\n\r\n{{{\r\nWrongExportWarning.hs:3:27:\r\n Warning: The export item `Empty(..)'\r\n suggests that `Empty' has constructor or class methods\r\n but it has none; it is a type synonym or abstract type or class\r\n}}}\r\n\r\nIf this was already fixed, I state in my defense that trac's search sucks.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1423compilation with profiling makes gcc run out of memory2019-07-07T19:13:37Zguestcompilation with profiling makes gcc run out of memoryCompiling a cabal library with profiling turned on caused gcc to run out of (1.5Gb of) memory and crash. Specifying -fasm in the cabal file works.
The repository can be darcsed from \[http://malde.org/\~ketil/bio
\]. Tested with ghc-6-6...Compiling a cabal library with profiling turned on caused gcc to run out of (1.5Gb of) memory and crash. Specifying -fasm in the cabal file works.
The repository can be darcsed from \[http://malde.org/\~ketil/bio
\]. Tested with ghc-6-6 (Ubuntu Feisty default install).
\<ketil at malde dot org\>
```
% ./Setup.hs configure -p
[...]
% ulimit -d 1500000
% ./Setup.hs build
Preprocessing library bio-0.3.1...
Building bio-0.3.1...
[ 1 of 15] Compiling Bio.Alignment.Matrices ( Bio/Alignment/Matrices.hs, dist/build/Bio/Alignment/Matrices.p_o )
gcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
<URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.
```
<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 | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"compilation with profiling makes gcc run out of memory","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":["compile","gcc","profile","via-c"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling a cabal library with profiling turned on caused gcc to run out of (1.5Gb of) memory and crash. Specifying -fasm in the cabal file works.\r\n\r\nThe repository can be darcsed from [http://malde.org/~ketil/bio\r\n]. Tested with ghc-6-6 (Ubuntu Feisty default install).\r\n\r\n<ketil at malde dot org>\r\n\r\n{{{\r\n% ./Setup.hs configure -p\r\n [...]\r\n% ulimit -d 1500000\r\n% ./Setup.hs build \r\nPreprocessing library bio-0.3.1...\r\nBuilding bio-0.3.1...\r\n[ 1 of 15] Compiling Bio.Alignment.Matrices ( Bio/Alignment/Matrices.hs, dist/build/Bio/Alignment/Matrices.p_o )\r\ngcc: Internal error: Killed (program cc1)\r\nPlease submit a full bug report.\r\nSee <URL:http://gcc.gnu.org/bugs.html> for instructions.\r\nFor Debian GNU/Linux specific bug reporting instructions, see\r\n<URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1424Argument corruption in FFI with many arguments (maybe 64-bit related)2019-07-07T19:13:36ZguestArgument corruption in FFI with many arguments (maybe 64-bit related)With many arguments, something strange occurs in argument passing with FFI. The misbehaviour only occurs on my 64-bit machine; the program works correctly on my 32-bit one. It seems as though an extra value is inserted into the argument ...With many arguments, something strange occurs in argument passing with FFI. The misbehaviour only occurs on my 64-bit machine; the program works correctly on my 32-bit one. It seems as though an extra value is inserted into the argument list.
First, here is the code. There's a foreign function that takes 10 doubles.
----
```
chris@mars:~/dev/haskell/ffi$ cat c.c
fC (double a,
double b,
double c,
double d,
double e,
double f,
double g,
double h,
double i,
double j)
{
printf("%f %f %f %f %f %f %f %f %f %f\n", a,b,c,d,e,f,g,h,i,j);
}
chris@mars:~/dev/haskell/ffi$ cat Ffi.hs
{-# OPTIONS_GHC -fglasgow-exts #-}
f :: Double -> Double -> Double -> Double -> Double -> Double -> Double -> Double -> Double -> Double -> IO ()
f a b c d e f g h i j = do
print [a, b, c, d, e, f, g, h, i, j]
fC a b c d e f g h i j
foreign import ccall unsafe "fC" fC ::
Double -> Double -> Double
-> Double -> Double -> Double
-> Double -> Double -> Double -> Double -> IO ()
main = do
f 1 2 3 4 5 6 7 8 9 10
```
----
Here is the correct behaviour, on my 32-bit machine. The important output is the line starting with "1.000000 2.000000 3.00\[...\]"
----
```
chris@loki:~/tmp/ffi$ gcc -c c.c
c.c: In function ‘fC’:
c.c:12: warning: incompatible implicit declaration of built-in function ‘printf’
chris@loki:~/tmp/ffi$ ghc --make Ffi c.o
[1 of 1] Compiling Main ( Ffi.hs, Ffi.o )
Linking Ffi ...
./chris@loki:~/tmp/ffi$ ./Ffi
[1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0]
1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 7.000000 8.000000 9.000000 10.000000
chris@loki:~/tmp/ffi$ ghc -v
Glasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by GHC version 6.6.1
Using package config file: /usr/lib/ghc-6.6.1/package.conf
Using package config file: /home/chris/.ghc/i386-linux-6.6.1/package.conf
wired-in package base mapped to base-2.1.1
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.1
Hsc static flags: -static
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
ghc-6.6.1: no input files
Usage: For basic information, try the `--help' option.
chris@loki:~/tmp/ffi$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070601 (prerelease) (Debian 4.1.2-12)
```
----
Here is the bad behaviour, on my 64-bit machine. Note that the Haskell list has the values \[1..10\], but the C arguments are 1,2,3,4,5,6,7,8,0,9 (a zero is inserted between 8 and 9).
----
```
chris@mars:~/dev/haskell/ffi$ gcc -c c.c
c.c: In function ‘fC’:
c.c:12: warning: incompatible implicit declaration of built-in function ‘printf’
chris@mars:~/dev/haskell/ffi$ ghc --make Ffi c.o
[1 of 1] Compiling Main ( Ffi.hs, Ffi.o )
Linking Ffi ...
chris@mars:~/dev/haskell/ffi$ ./Ffi
[1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0]
1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 7.000000 8.000000 0.000000 9.000000
chris@mars:~/dev/haskell/ffi$ ghc -v
Glasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by GHC version 6.6.1
Using package config file: /usr/lib/ghc-6.6.1/package.conf
Using package config file: /home/chris/.ghc/x86_64-linux-6.6.1/package.conf
wired-in package base mapped to base-2.1.1
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.1
Hsc static flags: -static
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
ghc-6.6.1: no input files
Usage: For basic information, try the `--help' option.
chris@mars:~/dev/haskell/ffi$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070429 (prerelease) (Debian 4.1.2-5)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | chris@cmears.id.au |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Argument corruption in FFI with many arguments (maybe 64-bit related)","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":["ffi"],"differentials":[],"test_case":"","architecture":"","cc":["chris@cmears.id.au"],"type":"Bug","description":"With many arguments, something strange occurs in argument passing with FFI. The misbehaviour only occurs on my 64-bit machine; the program works correctly on my 32-bit one. It seems as though an extra value is inserted into the argument list.\r\n\r\nFirst, here is the code. There's a foreign function that takes 10 doubles.\r\n\r\n----\r\n{{{\r\nchris@mars:~/dev/haskell/ffi$ cat c.c\r\nfC (double a,\r\n double b,\r\n double c,\r\n double d,\r\n double e,\r\n double f,\r\n double g,\r\n double h,\r\n double i,\r\n double j)\r\n{\r\n printf(\"%f %f %f %f %f %f %f %f %f %f\\n\", a,b,c,d,e,f,g,h,i,j);\r\n}\r\nchris@mars:~/dev/haskell/ffi$ cat Ffi.hs\r\n{-# OPTIONS_GHC -fglasgow-exts #-}\r\n\r\nf :: Double -> Double -> Double -> Double -> Double -> Double -> Double -> Double -> Double -> Double -> IO ()\r\nf a b c d e f g h i j = do\r\n print [a, b, c, d, e, f, g, h, i, j]\r\n fC a b c d e f g h i j\r\n\r\nforeign import ccall unsafe \"fC\" fC ::\r\n Double -> Double -> Double\r\n -> Double -> Double -> Double\r\n -> Double -> Double -> Double -> Double -> IO ()\r\n\r\nmain = do\r\n f 1 2 3 4 5 6 7 8 9 10\r\n}}}\r\n----\r\n\r\nHere is the correct behaviour, on my 32-bit machine. The important output is the line starting with \"1.000000 2.000000 3.00[...]\"\r\n\r\n----\r\n{{{\r\nchris@loki:~/tmp/ffi$ gcc -c c.c\r\nc.c: In function ‘fC’:\r\nc.c:12: warning: incompatible implicit declaration of built-in function ‘printf’\r\nchris@loki:~/tmp/ffi$ ghc --make Ffi c.o\r\n[1 of 1] Compiling Main ( Ffi.hs, Ffi.o )\r\nLinking Ffi ...\r\n./chris@loki:~/tmp/ffi$ ./Ffi \r\n[1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0]\r\n1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 7.000000 8.000000 9.000000 10.000000\r\nchris@loki:~/tmp/ffi$ ghc -v\r\nGlasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by GHC version 6.6.1\r\nUsing package config file: /usr/lib/ghc-6.6.1/package.conf\r\nUsing package config file: /home/chris/.ghc/i386-linux-6.6.1/package.conf\r\nwired-in package base mapped to base-2.1.1\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0\r\nwired-in package template-haskell mapped to template-haskell-2.1\r\nHsc static flags: -static\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Deleting temp dirs:\r\nDeleting: \r\nghc-6.6.1: no input files\r\nUsage: For basic information, try the `--help' option.\r\nchris@loki:~/tmp/ffi$ gcc -v\r\nUsing built-in specs.\r\nTarget: i486-linux-gnu\r\nConfigured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu\r\nThread model: posix\r\ngcc version 4.1.3 20070601 (prerelease) (Debian 4.1.2-12)\r\n}}}\r\n----\r\n\r\nHere is the bad behaviour, on my 64-bit machine. Note that the Haskell list has the values [1..10], but the C arguments are 1,2,3,4,5,6,7,8,0,9 (a zero is inserted between 8 and 9).\r\n\r\n----\r\n{{{\r\nchris@mars:~/dev/haskell/ffi$ gcc -c c.c\r\nc.c: In function ‘fC’:\r\nc.c:12: warning: incompatible implicit declaration of built-in function ‘printf’\r\nchris@mars:~/dev/haskell/ffi$ ghc --make Ffi c.o\r\n[1 of 1] Compiling Main ( Ffi.hs, Ffi.o )\r\nLinking Ffi ...\r\nchris@mars:~/dev/haskell/ffi$ ./Ffi \r\n[1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0]\r\n1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 7.000000 8.000000 0.000000 9.000000\r\nchris@mars:~/dev/haskell/ffi$ ghc -v\r\nGlasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by GHC version 6.6.1\r\nUsing package config file: /usr/lib/ghc-6.6.1/package.conf\r\nUsing package config file: /home/chris/.ghc/x86_64-linux-6.6.1/package.conf\r\nwired-in package base mapped to base-2.1.1\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0\r\nwired-in package template-haskell mapped to template-haskell-2.1\r\nHsc static flags: -static\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Deleting temp dirs:\r\nDeleting: \r\nghc-6.6.1: no input files\r\nUsage: For basic information, try the `--help' option.\r\nchris@mars:~/dev/haskell/ffi$ gcc -v\r\nUsing built-in specs.\r\nTarget: x86_64-linux-gnu\r\nConfigured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu\r\nThread model: posix\r\ngcc version 4.1.3 20070429 (prerelease) (Debian 4.1.2-5)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1425Print operator types as infix2019-07-07T19:13:36ZMichael D. AdamsPrint operator types as infixConsider the type
```
{-# OPTIONS -fglasgow-exts #-}
data a :-> b = a :-> b deriving (Show)
```
Load that file into GHCi and print the type of a simple expression with it.
```
*Main> :t True :-> False
```
The actual output will be
`...Consider the type
```
{-# OPTIONS -fglasgow-exts #-}
data a :-> b = a :-> b deriving (Show)
```
Load that file into GHCi and print the type of a simple expression with it.
```
*Main> :t True :-> False
```
The actual output will be
```
True :-> False :: (:->) Bool Bool
```
Notice that the type constructor has been printed in prefix form.
It would be nice if these infix type constructors printed in infix form just like infix data constructors do. For example the desired output would be:
```
True :-> False :: Bool :-> Bool
```
<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":"Print operator types as infix","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":["constructor","infix","type"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"Consider the type\r\n\r\n{{{\r\n{-# OPTIONS -fglasgow-exts #-}\r\ndata a :-> b = a :-> b deriving (Show)\r\n}}}\r\n\r\nLoad that file into GHCi and print the type of a simple expression with it.\r\n\r\n{{{\r\n*Main> :t True :-> False\r\n}}}\r\n\r\nThe actual output will be\r\n{{{\r\nTrue :-> False :: (:->) Bool Bool\r\n}}}\r\n\r\nNotice that the type constructor has been printed in prefix form.\r\nIt would be nice if these infix type constructors printed in infix form just like infix data constructors do. For example the desired output would be:\r\n{{{\r\nTrue :-> False :: Bool :-> Bool\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1426warning about `import Control.Monad.Fix` being unused when mdo is used2019-07-07T19:13:36ZIsaac Dupreewarning about `import Control.Monad.Fix` being unused when mdo is usedand the use is exported. This should not be warned about since Control.Monad.Fix is supposed to be imported in modules that use mdo, to be portable or something. "You should import Control.Monad.Fix. (Note: Strictly speaking, this import...and the use is exported. This should not be warned about since Control.Monad.Fix is supposed to be imported in modules that use mdo, to be portable or something. "You should import Control.Monad.Fix. (Note: Strictly speaking, this import is required only when you need to refer to the name MonadFix in your program, but the import is always safe, and the programmers are encouraged to always import this module when using the mdo-notation.)"
```
{-# OPTIONS_GHC -fglasgow-exts -fwarn-unused-imports #-}
module Test where
import Control.Monad.Fix
isEven :: Int -> Maybe Int
isEven n = if even n then Just n else Nothing
puzzle :: [Int]
puzzle = mdo (x, z) <- [(y, 1), (y^2, 2), (y^3, 3)]
Just y <- map isEven [z+1 .. 2*z]
return (x + y)
```
produces
```
Test.hs:5:0:
Warning: Module `Control.Monad.Fix' is imported, but nothing from it is used,
except perhaps instances visible in `Control.Monad.Fix'
To suppress this warning, use: import Control.Monad.Fix()
```
Just doing `import Control.Monad.Fix()` wouldn't fulfill the purpose of importing that module!
I wonder if there are any other special syntaxes (arrows maybe?) with this effect.
<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":"warning about `import Control.Monad.Fix` being unused when mdo is 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":"and the use is exported. This should not be warned about since Control.Monad.Fix is supposed to be imported in modules that use mdo, to be portable or something. \"You should import Control.Monad.Fix. (Note: Strictly speaking, this import is required only when you need to refer to the name MonadFix in your program, but the import is always safe, and the programmers are encouraged to always import this module when using the mdo-notation.)\"\r\n\r\n{{{\r\n{-# OPTIONS_GHC -fglasgow-exts -fwarn-unused-imports #-}\r\n\r\nmodule Test where\r\n\r\nimport Control.Monad.Fix\r\n\r\nisEven :: Int -> Maybe Int\r\nisEven n = if even n then Just n else Nothing\r\n\r\npuzzle :: [Int]\r\npuzzle = mdo (x, z) <- [(y, 1), (y^2, 2), (y^3, 3)]\r\n Just y <- map isEven [z+1 .. 2*z]\r\n return (x + y)\r\n}}}\r\n\r\nproduces\r\n\r\n{{{\r\nTest.hs:5:0:\r\n Warning: Module `Control.Monad.Fix' is imported, but nothing from it is used,\r\n except perhaps instances visible in `Control.Monad.Fix'\r\n To suppress this warning, use: import Control.Monad.Fix()\r\n}}}\r\n\r\nJust doing `import Control.Monad.Fix()` wouldn't fulfill the purpose of importing that module!\r\n\r\nI wonder if there are any other special syntaxes (arrows maybe?) with this effect.","type_of_failure":"OtherFailure","blocking":[]} -->