GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:19:18Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/171ghci panics2019-07-07T19:19:18ZIavor S. Diatchkighci panics```
hello,
i seem to be getting a panic from ghci on a very simple
program. apologies if this is not a bug, but something
wrong with my installation. this is on linux (mandrake
9.1), and i just installed the rpm for redhat available
fr...```
hello,
i seem to be getting a panic from ghci on a very simple
program. apologies if this is not a bug, but something
wrong with my installation. this is on linux (mandrake
9.1), and i just installed the rpm for redhat available
from the site. the same problem was happening with the
binary distribution as well.
this is what happens:
diatchki@chara: Haskell >ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version
6.0, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done.
Prelude> let Just x = Nothing in x
ghc-6.0: panic! (the `impossible' happened, GHC version
6.0):
getLinkDeps No iface for [<pkg>]GHCziErr
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
bye
iavor
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci panics","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nhello,\ni seem to be getting a panic from ghci on a very simple\nprogram. apologies if this is not a bug, but something\nwrong with my installation. this is on linux (mandrake\n9.1), and i just installed the rpm for redhat available\nfrom the site. the same problem was happening with the\nbinary distribution as well.\nthis is what happens:\n\ndiatchki@chara: Haskell >ghci\n ___ ___ _\n / _ \\ /\\ /\\/ __(_)\n / /_\\// /_/ / / | | GHC Interactive, version\n6.0, for Haskell 98.\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\n\\____/\\/ /_/\\____/|_| Type :? for help.\n\nLoading package base ... linking ... done.\nPrelude> let Just x = Nothing in x\nghc-6.0: panic! (the `impossible' happened, GHC version\n6.0):\n getLinkDeps No iface for [<pkg>]GHCziErr\n\nPlease report it as a compiler bug to\nglasgow-haskell-bugs@haskell.org,\nor http://sourceforge.net/projects/ghc/.\n\nbye\niavor\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/170warning: implicit declaration of function foo2019-07-07T19:19:18Znobodywarning: implicit declaration of function foo```
Hi,
when I compile a simple program with a function
imported from C using -fffi -O, I get the following:
warning: implicit declaration of function 'foo'
the imported function simply returns its argument
multiplied by two.
if I c...```
Hi,
when I compile a simple program with a function
imported from C using -fffi -O, I get the following:
warning: implicit declaration of function 'foo'
the imported function simply returns its argument
multiplied by two.
if I compile it without -O option, everything is fine, but
with the -O option it gives the warning and when I run
the program it gives the wrong result ( 1.0 for any
number)
Thanks.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"warning: implicit declaration of function foo","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nHi,\n\nwhen I compile a simple program with a function \nimported from C using -fffi -O, I get the following:\nwarning: implicit declaration of function 'foo'\n\nthe imported function simply returns its argument \nmultiplied by two.\n\nif I compile it without -O option, everything is fine, but \nwith the -O option it gives the warning and when I run \nthe program it gives the wrong result ( 1.0 for any \nnumber)\n\nThanks.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/169Panic (non-exhaustive pattern in compiler)2019-07-07T19:19:19ZxbiffPanic (non-exhaustive pattern in compiler)```
The following module strangely fails to compile with
GHC 6.0 (it works with GHC 5.02.2, I did not try any
other version).
----
module Bug where
pair t = (t, t)
a = (pair 'x', undefined)
b = a
----
ghc-6.0: panic! (the `impossible' ...```
The following module strangely fails to compile with
GHC 6.0 (it works with GHC 5.02.2, I did not try any
other version).
----
module Bug where
pair t = (t, t)
a = (pair 'x', undefined)
b = a
----
ghc-6.0: panic! (the `impossible' happened, GHC version
6.0):
coreSyn/CoreUtils.lhs:1188: Non-exhaustive patterns in
function isCrossDllArg
The error also happens when 'x' is replaced by a
non-empty list or string, and when it is replaced by a
numeral constant with an explicit type. Compilation
works when 'x' is replaced by an integer with no type
specification, or by a type contructor with no literal
in it (i.e. [] or Nothing). It also works when the
declaration « b = a » is removed, or when « pair 'x' »
is replaced by « ('x', 'x') », or when « (pair 'x',
undefined) » is replaced by « pair 'x' ».
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic (non-exhaustive pattern in compiler)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe following module strangely fails to compile with\nGHC 6.0 (it works with GHC 5.02.2, I did not try any\nother version).\n\n----\nmodule Bug where\npair t = (t, t)\na = (pair 'x', undefined)\nb = a\n----\n\nghc-6.0: panic! (the `impossible' happened, GHC version\n6.0):\ncoreSyn/CoreUtils.lhs:1188: Non-exhaustive patterns in\nfunction isCrossDllArg\n\nThe error also happens when 'x' is replaced by a\nnon-empty list or string, and when it is replaced by a\nnumeral constant with an explicit type. Compilation\nworks when 'x' is replaced by an integer with no type\nspecification, or by a type contructor with no literal\nin it (i.e. [] or Nothing). It also works when the\ndeclaration « b = a » is removed, or when « pair 'x' »\nis replaced by « ('x', 'x') », or when « (pair 'x',\nundefined) » is replaced by « pair 'x' ».\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/168GHCi removes source files!!2019-07-07T19:19:19ZdleijenGHCi removes source files!!```
GHCi removes source files on windows under
certain circumstances! Of course, this is very
bad when it actually happens.
It happens when loading a source file in a
subdirectory, i.e.
> ghci -package wx wx\HelloWorld.hs
[snip]
Loadi...```
GHCi removes source files on windows under
certain circumstances! Of course, this is very
bad when it actually happens.
It happens when loading a source file in a
subdirectory, i.e.
> ghci -package wx wx\HelloWorld.hs
[snip]
Loading package wx ... linking ... done.
Compiling Main ( wx/HelloWorld.hs, interpreted )
Ok, modules loaded: Main.
*Main> :q
Leaving GHCi.
>ghci -package wx wx\HelloWorld.hs
[snip]
Loading package wx ... linking ... done.
can't find file `wx\HelloWorld.hs'
It only happens when using the normal windows prompt.
It doesn't happen when using 'bash' (with cygwin).
Nice bug for an interpreter :-)
-- Daan.
(daanleijen@xs4all.nl)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | ResolvedDuplicate |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi removes source files!!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedDuplicate","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nGHCi removes source files on windows under\ncertain circumstances! Of course, this is very\nbad when it actually happens.\n\nIt happens when loading a source file in a\nsubdirectory, i.e.\n\n> ghci -package wx wx\\HelloWorld.hs\n[snip]\nLoading package wx ... linking ... done.\nCompiling Main ( wx/HelloWorld.hs, interpreted )\nOk, modules loaded: Main.\n*Main> :q\nLeaving GHCi.\n\n>ghci -package wx wx\\HelloWorld.hs\n[snip]\nLoading package wx ... linking ... done.\ncan't find file `wx\\HelloWorld.hs'\n\n\nIt only happens when using the normal windows prompt.\nIt doesn't happen when using 'bash' (with cygwin).\n\nNice bug for an interpreter :-)\n -- Daan.\n\n(daanleijen@xs4all.nl)\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/167File deleted2019-07-07T19:19:19ZnobodyFile deleted```
When compiling a file with errors, the file gets deleted!
Running WinXP
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | ...```
When compiling a file with errors, the file gets deleted!
Running WinXP
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"File deleted","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen compiling a file with errors, the file gets deleted!\nRunning WinXP\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/166ghc-pkg --list-packages-local is the wrong choice2019-07-07T19:19:19Zas49ghc-pkg --list-packages-local is the wrong choice```
I guess adding the --list-packages-local flag to
ghc-pkg wasn't a good thing afterall since
--list-packages is now useless:
~:$ ghc-pkg --list-packages
option `--list-packages' is ambiguous; could be one of:
-l --list-packages ...```
I guess adding the --list-packages-local flag to
ghc-pkg wasn't a good thing afterall since
--list-packages is now useless:
~:$ ghc-pkg --list-packages
option `--list-packages' is ambiguous; could be one of:
-l --list-packages List packages in all
config files
-L --list-packages-local List packages in the
specified config file
Could the "local" option be changed to
--list-local-packages? It scans better anyway.
Thanks,
Axel.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg --list-packages-local is the wrong choice","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI guess adding the --list-packages-local flag to\nghc-pkg wasn't a good thing afterall since\n--list-packages is now useless:\n\n~:$ ghc-pkg --list-packages\noption `--list-packages' is ambiguous; could be one of:\n -l --list-packages List packages in all\nconfig files\n -L --list-packages-local List packages in the\nspecified config file\n\nCould the \"local\" option be changed to\n--list-local-packages? It scans better anyway.\n\nThanks,\nAxel.\n\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/165hsc2hs fails to link intermediate program2019-07-07T19:19:20Zas49hsc2hs fails to link intermediate program```
On Mac OS X 10.2.6 and the binary package of ghc 6.00 I
get the following linker error when running hsc2hs on a
trivial program:
ld: Undefined symbols:
_Main_zdmain_closure
It seems that hsc2hs uses ghc now by default to compile ...```
On Mac OS X 10.2.6 and the binary package of ghc 6.00 I
get the following linker error when running hsc2hs on a
trivial program:
ld: Undefined symbols:
_Main_zdmain_closure
It seems that hsc2hs uses ghc now by default to compile the
C program. That doesn't seem to be the problem, though,
since it worked with ghc 5.04.
Axel.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hsc2hs fails to link intermediate program","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nOn Mac OS X 10.2.6 and the binary package of ghc 6.00 I \nget the following linker error when running hsc2hs on a \ntrivial program:\n\nld: Undefined symbols:\n_Main_zdmain_closure\n\nIt seems that hsc2hs uses ghc now by default to compile the \nC program. That doesn't seem to be the problem, though, \nsince it worked with ghc 5.04.\n\nAxel.\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/164bad warning for parallel list comprehension2019-07-07T19:19:20Znobodybad warning for parallel list comprehension```
this piece of code:
module ParComp where
t :: [(Char,Char)]
t = [ (a,b) | a <- "foo" | b <- "bar" ]
will generate this warning:
ParComp.hs:4: Warning: Defined but not used: b
ParComp.hs:4: Warning: Defined but not used: a
This i...```
this piece of code:
module ParComp where
t :: [(Char,Char)]
t = [ (a,b) | a <- "foo" | b <- "bar" ]
will generate this warning:
ParComp.hs:4: Warning: Defined but not used: b
ParComp.hs:4: Warning: Defined but not used: a
This is on Linux ghc version 6.0
Brett Letner
bletner@galois.com
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"bad warning for parallel list comprehension","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nthis piece of code:\n\nmodule ParComp where\n\nt :: [(Char,Char)]\nt = [ (a,b) | a <- \"foo\" | b <- \"bar\" ]\n\nwill generate this warning:\nParComp.hs:4: Warning: Defined but not used: b\n\nParComp.hs:4: Warning: Defined but not used: a\n\nThis is on Linux ghc version 6.0\n\nBrett Letner\nbletner@galois.com\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/163Error in compile deletes the sourcefile2019-07-07T19:19:20ZnobodyError in compile deletes the sourcefile```
If I try to compile a source file (any .hs file) and the
compiler returns an error (any error), the source file
gets deleted.
The compiler however, returns me to the "Prelude>"
cursor and still accepts commands
To recompile, I h...```
If I try to compile a source file (any .hs file) and the
compiler returns an error (any error), the source file
gets deleted.
The compiler however, returns me to the "Prelude>"
cursor and still accepts commands
To recompile, I have to save the file again from my
editor.
When the compilation is successful, the sourcefile is still
there.
I'm using the latest GHCi 6.0 on a WinXP sp 1 machine.
best regards
Jon Malmquist
d01jm@efd.lth.se
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Error in compile deletes the sourcefile","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nIf I try to compile a source file (any .hs file) and the \ncompiler returns an error (any error), the source file \ngets deleted.\n\nThe compiler however, returns me to the \"Prelude>\" \ncursor and still accepts commands\n\nTo recompile, I have to save the file again from my \neditor.\n\nWhen the compilation is successful, the sourcefile is still \nthere.\n\nI'm using the latest GHCi 6.0 on a WinXP sp 1 machine.\n\nbest regards\nJon Malmquist\nd01jm@efd.lth.se\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/162why delete?2019-07-07T19:19:20Znobodywhy delete?```
if there are some errors in the souce file, after loading
to GHCi, the file is deleted, why, it is cruel.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------...```
if there are some errors in the souce file, after loading
to GHCi, the file is deleted, why, it is cruel.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"why delete?","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nif there are some errors in the souce file, after loading \nto GHCi, the file is deleted, why, it is cruel.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/161GHCi breaks the terminal2019-07-07T19:19:20ZhampusrGHCi breaks the terminal```
After running ghci the terminal does not work exactly
as it should: Running "su" does no longer work for some
unknown reason (su stops after reading the first
character of the password). This happens with ghc 5.04
as well as 6.0 and ...```
After running ghci the terminal does not work exactly
as it should: Running "su" does no longer work for some
unknown reason (su stops after reading the first
character of the password). This happens with ghc 5.04
as well as 6.0 and current CVS-version, both in xterm
and console. This only seem to be a problem with my
Linux/Debian installation, I cannot reproduce the
problem on Solaris.
Also some minor spelling :) According to the CVS
users-guide the reverse of -frules-off is the very same
-frules-off.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi breaks the terminal","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nAfter running ghci the terminal does not work exactly\nas it should: Running \"su\" does no longer work for some\nunknown reason (su stops after reading the first\ncharacter of the password). This happens with ghc 5.04\nas well as 6.0 and current CVS-version, both in xterm\nand console. This only seem to be a problem with my\nLinux/Debian installation, I cannot reproduce the\nproblem on Solaris.\n\nAlso some minor spelling :) According to the CVS\nusers-guide the reverse of -frules-off is the very same\n-frules-off.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/160ghc failed to build ghc2021-03-22T06:17:57Znobodyghc failed to build ghc```
I tried building the ghc v6.0 source using ghc and it
failed. I tried both ghc v6.0 and ghc v5.04.2 compilers.
Platform: Linux RedHat v9.0
Memory: 194MB
CPU: Celeron 466
GHC Compiler: v6.0 (Linux binary tar)
...```
I tried building the ghc v6.0 source using ghc and it
failed. I tried both ghc v6.0 and ghc v5.04.2 compilers.
Platform: Linux RedHat v9.0
Memory: 194MB
CPU: Celeron 466
GHC Compiler: v6.0 (Linux binary tar)
v5.04.2 (Linux RedHat RPM)
GNU tool chain: Default RH v9.0 installation.
Configure options: --with-x --enable-src-tree-haddock
--enable-objectio
The compilation died while linking ghc-pkg.bin
The error message is:
libHSrts.a (RtsFlags.o) (.text + 0xf1): In function
'splitRtsFlags':
undefined reference to '__ctype_b'
Both v6.0 and v5.04.2 compilers gave the same error
message.
Regards
Tee Teoh
tty4@hotmail.com
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc failed to build ghc","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI tried building the ghc v6.0 source using ghc and it\nfailed. I tried both ghc v6.0 and ghc v5.04.2 compilers.\n\nPlatform: Linux RedHat v9.0\nMemory: 194MB\nCPU: Celeron 466\nGHC Compiler: v6.0 (Linux binary tar)\n v5.04.2 (Linux RedHat RPM)\nGNU tool chain: Default RH v9.0 installation.\n\nConfigure options: --with-x --enable-src-tree-haddock\n--enable-objectio\n\nThe compilation died while linking ghc-pkg.bin\n\nThe error message is:\n\nlibHSrts.a (RtsFlags.o) (.text + 0xf1): In function\n'splitRtsFlags': \n undefined reference to '__ctype_b'\n\nBoth v6.0 and v5.04.2 compilers gave the same error\nmessage. \n\nRegards\n\nTee Teoh\ntty4@hotmail.com\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/159The impossible happened2019-07-07T19:19:21ZrjmhThe impossible happened```
Using GHC version 6, I loaded a compiled module into
GHCi, then changed directory and tried to call a
function. Error message:
panic! (the `impossible´happened, GHC version 6.0):
loadObj: failed
I'm attaching the source ...```
Using GHC version 6, I loaded a compiled module into
GHCi, then changed directory and tried to call a
function. Error message:
panic! (the `impossible´happened, GHC version 6.0):
loadObj: failed
I'm attaching the source of the module in case you need
it.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The impossible happened","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nUsing GHC version 6, I loaded a compiled module into \nGHCi, then changed directory and tried to call a \nfunction. Error message:\n\npanic! (the `impossible´happened, GHC version 6.0):\n\n loadObj: failed\n\nI'm attaching the source of the module in case you need \nit.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/158Non-exhaultive patterns from derived Read2021-08-09T18:05:22ZnobodyNon-exhaultive patterns from derived Read```
When switching from GHC 5.04.1 to 6.0 I started getting
a load of warnings like these:
source/SDL/Types.hs:33:
Warning: Pattern match(es) are non-exhaustive
In a pattern binding in
a 'do' expre...```
When switching from GHC 5.04.1 to 6.0 I started getting
a load of warnings like these:
source/SDL/Types.hs:33:
Warning: Pattern match(es) are non-exhaustive
In a pattern binding in
a 'do' expression:
Patterns not matched:
Text.Read.Lex.EOF
Text.Read.Lex.Rat _
Text.Read.Lex.Int _
Text.Read.Lex.Symbol _
...
The source in question looks like this
data Expected
= ExpectedType String
| ExpectedValue String
deriving (Read, Show)
It looks as though everything deriving Read causes this
warning (there are several such constructs in the file).
Deriving only Show does not. Found no mention of
change to behavior of derived reads in release notes or in
google.
Cheers,
Jason Feingold
jfeingol@haverford.edu
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedWon'tFix |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Non-exhaultive patterns from derived Read","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedWon'tFix","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen switching from GHC 5.04.1 to 6.0 I started getting \na load of warnings like these:\n\n\n\n\n source/SDL/Types.hs:33:\n\n\n Warning: Pattern match(es) are non-exhaustive\n\n\n In a pattern binding in\n\n\n a 'do' expression:\n\n\n Patterns not matched:\n\n\n Text.Read.Lex.EOF\n\n\n Text.Read.Lex.Rat _\n\n\n Text.Read.Lex.Int _\n\n\n Text.Read.Lex.Symbol _\n\n\n ...\n\n\n\n\nThe source in question looks like this\n\n\n\n\ndata Expected\n\n\n\t= ExpectedType String\n\n\n\t| ExpectedValue String\n\n\n\tderiving (Read, Show)\n\n\n\n\nIt looks as though everything deriving Read causes this \nwarning (there are several such constructs in the file). \nDeriving only Show does not. Found no mention of \nchange to behavior of derived reads in release notes or in \ngoogle.\n\n\n\n\nCheers,\n\n\nJason Feingold\n\n\njfeingol@haverford.edu\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/157openFileEx remove from GHC.Handle2019-07-07T19:19:21ZnobodyopenFileEx remove from GHC.Handle```
SimonM removed openFileEx from GHC.Handle (it is still
included, though deprecated in IOExts). It is still
imported from GHC.Handle and used in
fptools/ghc/compiler/utils/Binary.hs
My build on a CVS source checked out on 20th of ...```
SimonM removed openFileEx from GHC.Handle (it is still
included, though deprecated in IOExts). It is still
imported from GHC.Handle and used in
fptools/ghc/compiler/utils/Binary.hs
My build on a CVS source checked out on 20th of June
failed at stage2.
I've attached a trivial patch which worked on my build.
-nate (jnf21@cantab.net)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"openFileEx remove from GHC.Handle","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nSimonM removed openFileEx from GHC.Handle (it is still \nincluded, though deprecated in IOExts). It is still \nimported from GHC.Handle and used in \nfptools/ghc/compiler/utils/Binary.hs\n\nMy build on a CVS source checked out on 20th of June\nfailed at stage2.\n\nI've attached a trivial patch which worked on my build.\n\n-nate (jnf21@cantab.net)\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/156Class op should mention class tyvar2019-07-07T19:19:21ZSimon Peyton JonesClass op should mention class tyvar```
class Foo a where
op :: Int
is accepted, but it should be rejected. Any use of op
give ambiguity errors, of course, but it should be
rejected up front.
```
<details><summary>Trac metadata</summary>
| Trac field ...```
class Foo a where
op :: Int
is accepted, but it should be rejected. Any use of op
give ambiguity errors, of course, but it should be
rejected up front.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Class op should mention class tyvar","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n class Foo a where\n op :: Int\n\nis accepted, but it should be rejected. Any use of op \ngive ambiguity errors, of course, but it should be \nrejected up front.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/155ghc-6.0: panic!2023-05-24T21:02:06Zpdejuanghc-6.0: panic!```
Make fails to build Parsec with GHC-6.0 at ParsecPrim.o
in a Linux box.
The error message is as it follows:
ghc-6.0: panic! (thee 'impossible' happened, GHC
version 6.0): coreSyn/CoreUtils.lhs:1188:
Non-exhaustive patterns in functio...```
Make fails to build Parsec with GHC-6.0 at ParsecPrim.o
in a Linux box.
The error message is as it follows:
ghc-6.0: panic! (thee 'impossible' happened, GHC
version 6.0): coreSyn/CoreUtils.lhs:1188:
Non-exhaustive patterns in function isCrossDllArg
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-6.0: panic!","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nMake fails to build Parsec with GHC-6.0 at ParsecPrim.o\nin a Linux box.\nThe error message is as it follows:\nghc-6.0: panic! (thee 'impossible' happened, GHC\nversion 6.0): coreSyn/CoreUtils.lhs:1188:\nNon-exhaustive patterns in function isCrossDllArg\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/154mutiparameter classes problem2024-02-05T17:53:11Znobodymutiparameter classes problem```
hello,
i have run into something that looks like a bug in ghc 6.0.
here is an example:
> module A where
> class C a b where f :: a -> b
> g x = fst (f x)
for this program hugs reports that "g" has an ambiguous
type:
C a (b,c) => ...```
hello,
i have run into something that looks like a bug in ghc 6.0.
here is an example:
> module A where
> class C a b where f :: a -> b
> g x = fst (f x)
for this program hugs reports that "g" has an ambiguous
type:
C a (b,c) => a -> b
which seems reasonable.
however ghc does not report an error, and infers the
following type:
C a (b, ()) => a -> b
(i have changed the formatting for easier comparing).
it seems that somehow the second component of the tuple
became (),
but i don't see why.
bye
iavor
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"mutiparameter classes problem","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nhello,\ni have run into something that looks like a bug in ghc 6.0.\nhere is an example:\n\n> module A where\n> class C a b where f :: a -> b\n> g x = fst (f x)\n\nfor this program hugs reports that \"g\" has an ambiguous\ntype:\n C a (b,c) => a -> b\nwhich seems reasonable.\nhowever ghc does not report an error, and infers the\nfollowing type:\n C a (b, ()) => a -> b\n(i have changed the formatting for easier comparing).\nit seems that somehow the second component of the tuple\nbecame (),\nbut i don't see why.\n\nbye\niavor\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/153forkProcess does not terminate main threads2023-03-29T22:12:25ZSimon MarlowforkProcess does not terminate main threads```
There is a defficiency in the current implementation of
forkProcess, namely that main threads are not
terminated. Currently, it is only safe to call forkProcess
when there is a single main thread in the system, and
forkProcess m...```
There is a defficiency in the current implementation of
forkProcess, namely that main threads are not
terminated. Currently, it is only safe to call forkProcess
when there is a single main thread in the system, and
forkProcess must be called from that thread.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"forkProcess does not terminate main threads","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThere is a defficiency in the current implementation of \nforkProcess, namely that main threads are not \nterminated. Currently, it is only safe to call forkProcess \nwhen there is a single main thread in the system, and \nforkProcess must be called from that thread.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/152(->) used prefix doesn't work with unboxed kinds2019-07-07T19:19:22ZSimon Peyton Jones(->) used prefix doesn't work with unboxed kinds```
This fails, but should succeed
f :: (->) Int# Int#
f x = x
-- Here's the comment from TypeRep:
--
-- funTyCon = mkFunTyCon funTyConName
-- (mkArrowKinds [liftedTypeKind,
liftedTypeKind]
-- liftedTypeKind)
-- You might...```
This fails, but should succeed
f :: (->) Int# Int#
f x = x
-- Here's the comment from TypeRep:
--
-- funTyCon = mkFunTyCon funTyConName
-- (mkArrowKinds [liftedTypeKind,
liftedTypeKind]
-- liftedTypeKind)
-- You might think that (->) should have type (? -> ? ->
*), and you'd be right
-- But if we do that we get kind errors when saying
-- instance Control.Arrow (->)
-- becuase the expected kind is (*->*->*). The trouble
is that the
-- expected/actual stuff in the unifier does not go
contra-variant, whereas
-- the kind sub-typing does. Sigh. It really only
matters if you use (->) in
-- a prefix way, thus: (->) Int# Int#. And this is
unusual.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"(->) used prefix doesn't work with unboxed kinds","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThis fails, but should succeed\n f :: (->) Int# Int#\n f x = x\n\n\n-- Here's the comment from TypeRep:\n--\n-- funTyCon = mkFunTyCon funTyConName \n--\t\t(mkArrowKinds [liftedTypeKind, \nliftedTypeKind]\n--\t\t\t\tliftedTypeKind)\n-- You might think that (->) should have type (? -> ? -> \n*), and you'd be right\n-- But if we do that we get kind errors when saying\n--\tinstance Control.Arrow (->)\n-- becuase the expected kind is (*->*->*). The trouble \nis that the\n-- expected/actual stuff in the unifier does not go \ncontra-variant, whereas\n-- the kind sub-typing does. Sigh. It really only \nmatters if you use (->) in\n-- a prefix way, thus: (->) Int# Int#. And this is \nunusual.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobody