GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-12-09T22:02:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2069GHC crashes when both -shared and --make flags are specified2021-12-09T22:02:55ZbchallenorGHC crashes when both -shared and --make flags are specifiedI'm not even sure if you're meant to be able to do this, but I wanted to build a DLL without manually specifying the files, so I tried to do the build and the archiving in one step.
But I get a panic:
```
>ghc -shared --make LibFunslan...I'm not even sure if you're meant to be able to do this, but I wanted to build a DLL without manually specifying the files, so I tried to do the build and the archiving in one step.
But I get a panic:
```
>ghc -shared --make LibFunslang
ghc: panic! (the 'impossible' happened)
(GHC version 6.8.1 for i386-unknown-mingw32):
main/DriverPipeline.hs:(270,0)-(337,23): Non-exhaustive patterns in function link
```6.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/1110Setting PATH needed in Windows Vista2021-09-29T14:55:32Zbr1@internet.com.uySetting PATH needed in Windows VistaI'm running Windows Vista 64 bits and GHC 6.6. I needed to put both ghc/bin and ghc/gcc-lib in my path for it to work, or I got cc1/as not found errors.
<details><summary>Trac metadata</summary>
| Trac field | Value ...I'm running Windows Vista 64 bits and GHC 6.6. I needed to put both ghc/bin and ghc/gcc-lib in my path for it to work, or I got cc1/as not found errors.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Setting PATH needed in Windows Vista","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm running Windows Vista 64 bits and GHC 6.6. I needed to put both ghc/bin and ghc/gcc-lib in my path for it to work, or I got cc1/as not found errors.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2080Bug in CmmOpt2021-02-15T17:33:39ZSimon MarlowBug in CmmOptTwo bugs are demonstrated by the following code. The first one is wrong code generated for the comparison, and the second is the panic (see the comment):
```
module Test where
import GHC.Base
utf8DecodeChar# :: Addr# -> Bool -> Bool
{-...Two bugs are demonstrated by the following code. The first one is wrong code generated for the comparison, and the second is the panic (see the comment):
```
module Test where
import GHC.Base
utf8DecodeChar# :: Addr# -> Bool -> Bool
{-# NOINLINE utf8DecodeChar# #-}
utf8DecodeChar# a# fred =
case () of
_ | word2Int# (indexWord8OffAddr# a# 0#) <=# 0x7F# -> True
-- Omitting the next line gives an ASSERT error:
-- ghc-6.9: panic! (the 'impossible' happened)
-- (GHC version 6.9 for x86_64-unknown-linux):
-- ASSERT failed! file nativeGen/MachCodeGen.hs line 1049
-- %MO_S_Le_I8(I8[R2], 127 :: I8)
| fred -> True
| otherwise -> False
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| 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":"Bug in CmmOpt","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8.3","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Two bugs are demonstrated by the following code. The first one is wrong code generated for the comparison, and the second is the panic (see the comment):\r\n\r\n{{{\r\nmodule Test where\r\nimport GHC.Base\r\n\r\nutf8DecodeChar# :: Addr# -> Bool -> Bool\r\n{-# NOINLINE utf8DecodeChar# #-}\r\nutf8DecodeChar# a# fred =\r\n case () of \r\n _ | word2Int# (indexWord8OffAddr# a# 0#) <=# 0x7F# -> True\r\n\r\n-- Omitting the next line gives an ASSERT error:\r\n-- ghc-6.9: panic! (the 'impossible' happened)\r\n-- (GHC version 6.9 for x86_64-unknown-linux):\r\n-- \tASSERT failed! file nativeGen/MachCodeGen.hs line 1049\r\n-- %MO_S_Le_I8(I8[R2], 127 :: I8)\r\n | fred -> True\r\n\r\n | otherwise -> False\r\n}}}\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/2083linker reports missing symbols Main.c:(.text+0x12): undefined reference to `_...2020-01-25T21:48:07ZAndrew U. Franklinker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain'i use 6.8.2 on linux (ubuntu 7.10).
i use mainly eclipse and ghci, but when i try to compile a program, the linker reports
the undefined references.
for the minimal program 'hello world' i get
```
Main.c:(.text+0x12): undefined referenc...i use 6.8.2 on linux (ubuntu 7.10).
i use mainly eclipse and ghci, but when i try to compile a program, the linker reports
the undefined references.
for the minimal program 'hello world' i get
```
Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain'
Main.c:(.text+0x2c): undefined reference to `ZCMain_main_closure'
```
for more interesting programs i get a lot more (i have experimented with wxhaskell and phooey, tv, eros -- and some problems with compiling them in the right order etc..)
suprisingly the problem goes away if the program is called Main.hs - then it links properly, but not when it is called Test.hs. the same program with
```
main = putStr....
```
according to the ghc documentation, it is permitted to have in file Test.hs the module main.
(and it works properly in ghci)6.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/2084GHC panic2019-11-05T21:15:02ZstimbermGHC panicGHC crashed with the following output, but I don't know what this is about. Do you need other kind of information?
ghc output:
```
ghc-6.8.1: panic! (the 'impossible' happened)
(GHC version 6.8.1 for i386-apple-darwin):
tcIfa...GHC crashed with the following output, but I don't know what this is about. Do you need other kind of information?
ghc output:
```
ghc-6.8.1: panic! (the 'impossible' happened)
(GHC version 6.8.1 for i386-apple-darwin):
tcIfaceGlobal (local): not found:
main:Eval.$fx2{v r4H}
[(r4J, Class `main:Eval.JustReturn{tc r4J}'),
(r4L, Type constructor `main:Eval.:Co:TJustReturn{tc r4L}'),
(r4M, Type constructor `main:Eval.:TJustReturn{tc r4M}'),
(r4N, Data constructor `main:Eval.:DJustReturn{d r4N}'),
(r4O, Identifier `main:Eval.:DJustReturn{v r4O}'),
(r4P, Identifier `main:Eval.justReturn{v r4P}'),
(r7Z, Class `main:Eval.Evaluator{tc r7Z}'),
(r80, Identifier `main:Eval.eval{v r80}'),
(r81, Class `main:Eval.ContextProceed{tc r81}'),
(r82, Identifier `main:Eval.proceed{v r82}'),
(ra8, Data constructor `main:Eval.:DEvaluator{d ra8}'),
(ra9, Type constructor `main:Eval.:TEvaluator{tc ra9}'),
(raf, Data constructor `main:Eval.:DContextProceed{d raf}'),
(rag, Type constructor `main:Eval.:TContextProceed{tc rag}'),
(raj, Type constructor `main:Eval.:Co:TEvaluator{tc raj}'),
(rak, Identifier `main:Eval.:DEvaluator{v rak}'),
(rao, Type constructor `main:Eval.:Co:TContextProceed{tc rao}'),
(rap, Identifier `main:Eval.:DContextProceed{v rap}')]
```6.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/629IO library locking doesn't count readers2019-07-07T19:17:42ZSimon MarlowIO library locking doesn't count readersWe aren't keeping track of the number of readers of a file, so that the first one to close a Handle removes the lock.
```
> main = do
> fc <- openFile "z" ReadMode -- sacrificial handle
> fr <- openFile "z" ReadMode
> ...We aren't keeping track of the number of readers of a file, so that the first one to close a Handle removes the lock.
```
> main = do
> fc <- openFile "z" ReadMode -- sacrificial handle
> fr <- openFile "z" ReadMode
> hClose fc
> fa <- openFile "z" AppendMode
> hPutStr fa "append this line\n"
> hGetLine fr >>= print
```
this should fail.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"IO library locking bug","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"We aren't keeping track of the number of readers of a file, so that the first one to close a Handle removes the lock.\r\n\r\n{{{\r\n> main = do\r\n> fc <- openFile \"z\" ReadMode -- sacrificial handle\r\n> fr <- openFile \"z\" ReadMode\r\n> hClose fc\r\n> fa <- openFile \"z\" AppendMode\r\n> hPutStr fa \"append this line\\n\"\r\n> hGetLine fr >>= print\r\n}}}\r\n\r\nthis should fail.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/967Simplifier in HEAD is iterating too much2019-07-07T19:16:05ZSimon MarlowSimplifier in HEAD is iterating too muchJust so we don't forget: the simplifier in the HEAD seems to be iterating too much, perhaps flip-flopping between states instead of stopping.
```
NOTE: Simplifier still going after 4 iterations; bailing out.
NOTE: Simplifier still going...Just so we don't forget: the simplifier in the HEAD seems to be iterating too much, perhaps flip-flopping between states instead of stopping.
```
NOTE: Simplifier still going after 4 iterations; bailing out.
NOTE: Simplifier still going after 4 iterations; bailing out.
NOTE: Simplifier still going after 4 iterations; bailing out.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Simplifier in HEAD is iterating too much","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Just so we don't forget: the simplifier in the HEAD seems to be iterating too much, perhaps flip-flopping between states instead of stopping.\r\n\r\n{{{\r\nNOTE: Simplifier still going after 4 iterations; bailing out.\r\nNOTE: Simplifier still going after 4 iterations; bailing out.\r\nNOTE: Simplifier still going after 4 iterations; bailing out.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/998Tab-completion of filenames does not work in GHCi 6.62019-07-07T19:15:56Zdm.maillists@gmail.comTab-completion of filenames does not work in GHCi 6.6Trying to tab-complete filenames, for example when doing a :load, does not work in GHCi 6.6. It did work in GHCi 6.4.2.
Scenario:
```
$> ls
Baz Foo
$> ls Foo/
Bar.hs
$> ghci
Prelude> :l F<<press tab>>
Prelude> :l Foo/<press tab twice>>...Trying to tab-complete filenames, for example when doing a :load, does not work in GHCi 6.6. It did work in GHCi 6.4.2.
Scenario:
```
$> ls
Baz Foo
$> ls Foo/
Bar.hs
$> ghci
Prelude> :l F<<press tab>>
Prelude> :l Foo/<press tab twice>>
Baz/ Foo/
```
Rather than listing options of Baz and Foo it should have completed to Foo/Bar.hs.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Tab-completion of filenames does not work in GHCi 6.6","status":"New","operating_system":"Linux","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Trying to tab-complete filenames, for example when doing a :load, does not work in GHCi 6.6. It did work in GHCi 6.4.2.\r\n\r\nScenario:\r\n\r\n{{{\r\n$> ls\r\nBaz Foo\r\n$> ls Foo/\r\nBar.hs\r\n$> ghci\r\nPrelude> :l F<<press tab>>\r\nPrelude> :l Foo/<press tab twice>>\r\nBaz/ Foo/\r\n}}}\r\n\r\nRather than listing options of Baz and Foo it should have completed to Foo/Bar.hs.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1061default class methods can be given too general a type as GHC tries to share t...2019-07-07T19:15:26ZIan Lynagh <igloo@earth.li>default class methods can be given too general a type as GHC tries to share them between instancesGHC does not accept this program:
```
class Baz v x where
foo :: x -> x
foo y = y
instance Baz Int Int
```
even though it does accept this one:
```
class Baz v x where
foo :: x -> x
foo y = y
instance Baz Int Int where
...GHC does not accept this program:
```
class Baz v x where
foo :: x -> x
foo y = y
instance Baz Int Int
```
even though it does accept this one:
```
class Baz v x where
foo :: x -> x
foo y = y
instance Baz Int Int where
foo y = y
```
I can't find an explicit answer in the report, but I think both should be accepted.
The tc199 test says, in a comment,
```
This code defines a default method with a highly dubious type,
because 'v' is not mentioned, and there are no fundeps
However, arguably the instance declaration should be accepted,
beause it's equivalent to
instance Baz Int Int where { foo x = x }
which *does* typecheck
GHC does not actually macro-expand the instance decl. Instead, it
defines a default method function, thus
$dmfoo :: Baz v x => x -> x
$dmfoo y = y
Notice that this is an ambiguous type: you can't call $dmfoo
without triggering an error. And when you write an instance decl,
it calls the default method:
instance Baz Int Int where foo = $dmfoo
I'd never thought of that. You might think that we should just
*infer* the type of the default method (here forall a. a->a), but
in the presence of higher rank types etc we can't necessarily do
that.
```6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1109lockFile: fd out of range2019-07-07T19:15:13ZguestlockFile: fd out of rangeMy program was terminated with the following message:
```
internal error: lockFile: fd out of range
(GHC version 6.6 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The reason...My program was terminated with the following message:
```
internal error: lockFile: fd out of range
(GHC version 6.6 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The reason appears to be the large number of simultaneously open files. If I limit the number of open descriptors to 1025 or lower, I get "openFile: resource exhausted (Too many open files" instead.6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1129recvFrom blocking2019-07-07T19:15:09ZJuanMarcusrecvFrom blockingUsing recvFrom inside a thread on Windows blocks the whole process, instead of blocking only the calling thread. On linux, the same function works perfectly fine.
Using only recv works fine on both systems.
Windows: latest MinGW, MSYS,...Using recvFrom inside a thread on Windows blocks the whole process, instead of blocking only the calling thread. On linux, the same function works perfectly fine.
Using only recv works fine on both systems.
Windows: latest MinGW, MSYS, GHC 6.6 or 6.4
Linux: gcc 3.3.5, posix threads, ghc 6.2 or 6.4
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/network |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"recvFrom blocking","status":"New","operating_system":"","component":"libraries/network","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Using recvFrom inside a thread on Windows blocks the whole process, instead of blocking only the calling thread. On linux, the same function works perfectly fine.\r\n\r\nUsing only recv works fine on both systems.\r\n\r\nWindows: latest MinGW, MSYS, GHC 6.6 or 6.4\r\nLinux: gcc 3.3.5, posix threads, ghc 6.2 or 6.4","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1288ghci 6.6 foreign import stdcall broken, panic, panic!!!!2019-07-07T19:14:17Zjvlask@hotmail.comghci 6.6 foreign import stdcall broken, panic, panic!!!!**ghci 6.6 foreign import stdcall broken, panic, panic!!!!**
I would like to report what I think is a problem with GHCI foreign function imports
of c functions declared with stdcall calling convention (1) and also with loading objects c...**ghci 6.6 foreign import stdcall broken, panic, panic!!!!**
I would like to report what I think is a problem with GHCI foreign function imports
of c functions declared with stdcall calling convention (1) and also with loading objects containing dll imports (2).
# WHAT IS THE PROBLEM ?
## 1. ghci handling of mangling of stdcall function names broken
```
Prelude> :load htest3
[1 of 1] Compiling Main ( htest3.hs, interpreted )
During interactive linking, GHCi couldn't find the following symbol:
test
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
```
## 2. ghci loading of c object files dll imports name resolution broken
```
>ghci -fglasgow-exts test_proxy5a.o -ltest3b
test_proxy5a.o: unknown symbol `__imp__test'
final link ... : linking extra libraries/objects failed
```
detail follows ...
# CONCLUSSION REACHED
## 1. Importing Stdcall Symbols
ghci dose not correctly look for symbols decorated in the stdcall manner in the
object files ie. it looks for **_test** when it should (according to stdcall convention) look for **_test\@4**.
stdcall symbols in object files are decorated with the number of bytes that should
be popped from the stack before the function returns.
## 2. linking objects with dllimports
ghci cannot properly resolve dllimports in c object files i.e. if an object loaded by ghci
(eg test_proxy, with c function test_proxy) calls functions from a dll (eg
**test**) then
that function in the object file will be decorated as **`__imp__test`**
this in normal course linked agains a .lib or a .a file will be resolved to **_test**
function in the dll but ghci does not do this.
Offcourse these problems go away when using ghc ... but well what's the point of ghci then?
# SUMMARY OF TESTS and METHODOLOGY
## 1. Reference Case
verify that ccall works ..
> \[\[BR\]\]Create c file test1a.c and function test(int) in the file
> \[\[BR\]\]create haskell file htest1.hs with function ctest calling test
> \[\[BR\]\]check this works ok with
> a. c object loaded (test1a.c, htest1.hs )-- OK, RIGHT \[\[BR\]\]
> b. windows dll, c is function a dll export (test1b.c, htest1.hs ) -- OK, RIGHT
== 3. change calling convention to stdcall ==
> a. check loading of function from object (test3a.c, htest3.hs) -- FAIL, WRONG\[\[BR\]\]
> b. check loading of stdcall function from dll -- FAIL, WRONG
## 4. try what shouldn't work
a. htest3 against object test1a
i.e. what hapens when you try loading a haskell module with foreign import stdcall against c function declared with ccall convention.
> ghci loaded -- OK!!, WRONG,
it should not have resolved the symbol and not loaded.\[\[BR\]\]
> ghci called the function and crashed -- given that it resolved the symbol and called the function, this is expected.
b. htest3 against dll htest1b.dll
> same result as 4a -- expected,
behaviour consistent in both cases with resolving stdcall callouts
(symbol **test**) in a manner consistent with ccalls.
i.e. resolving the call to c function **test** as a call to symbol **_test**
rather than **_test\@4** as it should be according to the stdcall convention.
yet the function is called as a stdcall c function, consequently ghci crashes when
the ccall function returns and the stack has not been cleared of the function arguments, as is required by the stdcall convention.
## 5. Lets try a proxy function/object
Hmm, lets see what happens when we have a ccall c proxy function calling stdcall c
function in dll etc?
a. test_proxy5a.o with test3b.dll
ccall function calling stdcall function in dll
`
unknown symbol __imp__test
`
> FAILED, WRONG.
dllimports are decorated with **`__imp__`** so a stdcall dllimport to a c function
**test** will appear as **`__imp__test@4`**
the dll will export symbol **_test\@4**, usually it is the function of the import
> library ( .a or .lib depending upon which linker mingw or msvc ) to resolve
**`__imp_test@4`** to reference **_test\@4** in the dll
b. test_proxy5b.o with test3b.dll, htest5.hs
ccall function calling stdcall function (not declared as dllimport)
LOADS OK, RUNS OK
test_proxy5b imports symbol **_test\@4** the test3b.dll exports symbol
**_test\@4**. Arguably this is correct behaviour as **`__imp__`** decoration is an
> MS innovation and case (a) should be handled together with case (b).
c. whell what about test_proxy5b.o with test1b.dll
> i.e. c stdcall to a c function declared with ccall convention from .o object
loaded by ghci should fail to resolve symbols, should crash program but does niether ????
hey this has me stumped test_proxy5b.o imports symbol **_test\@4**. test1b.dll
exports symbol **_test** hmmm how is the symbol **_test\@4** resolved ??? why
> isn't the stack corrupted when **test** is called ??? MYSTERY ???
# DETAIL
```
compiler: ghci version 6.6
platform: windows XP
```
*notes-*
- test1\[a,b\].c
- test3\[a,b\].c
difference in these files between a,b version is that the b version declares
dllexport, required when building a dll with msvc (and not using def file), not relevant with
mingw and using "dllwrap --export-all-symbols"
## TEST 1
### test1a.c
```
#include <stdio.h>
void test(int arg)
{
printf("The argument passed was %i\n", arg );
}
```
### test1b.c
```
#include <stdio.h>
__declspec(dllexport) void test(int arg)
{
printf("The argument passed was %i\n", arg );
}
```
### htest1.hs
```
import Foreign
import Foreign.C
foreign import ccall "test" ctest :: CInt -> IO ()
```
### COMPILATION OF C DLL/OBJECTS
```
gcc -c test1a.c
gcc -c test1b.c
ar -rv test1b.a test1b.o
dllwrap --export-all-symbols --output-lib test1b.dll.a -o test1b.dll test1b.a
```
### TEST 1A results
```
ghci -fglasgow-exts test1a.o
Loading package base ... linking ... done.
Loading object (static) test1a.o ... done
final link ... done
Prelude> :load htest1
[1 of 1] Compiling Main ( htest1.hs, interpreted )
Ok, modules loaded: Main.
*Main> ctest 5
The argument passed was 5
*Main>
```
### TEST 1B
```
ghci -fglasgow-exts -ltest1b
Loading package base ... linking ... done.
Loading object (dynamic) test1b ... done
final link ... done
Prelude> :load htest1
[1 of 1] Compiling Main ( htest1.hs, interpreted )
Ok, modules loaded: Main.
*Main> ctest 5
The argument passed was 5
*Main>
```
## TEST 3
### test3a.c
```
#include <stdio.h>
void _stdcall test(int arg)
{
printf("The argument passed was %i\n", arg );
}
```
### test3b.c
```
#include <stdio.h>
__declspec(dllexport) void _stdcall test(int arg)
{
printf("The argument passed was %i\n", arg );
}
```
### htest3.hs
```
import Foreign
import Foreign.C
foreign import stdcall "test" ctest :: CInt -> IO ()
```
### COMPILATION OF C DLL/OBJECTS
```
compilation (mingw)
gcc -c test3a.c
gcc -c test3b.c
ar -rv test3b.a test3b.o
E:\vvv\WP03\S00\ffi>dllwrap --export-all-symbols --output-lib test3b.dll.a -o
test3b.dll test3b.a
compilation msvc (same result with both mingw and msvc dll!!)
cl -c test3.c
link etc ...
```
### TEST 3A
```
ghci -fglasgow-exts test3a.o
Loading package base ... linking ... done.
Loading object (static) test3a.o ... done
final link ... done
Prelude> :load htest3.hs
[1 of 1] Compiling Main ( htest3.hs, interpreted )
During interactive linking, GHCi couldn't find the following symbol:
test
```
### TEST 3B
```
ghci -fglasgow-exts -ltest3b
Loading package base ... linking ... done.
Loading object (dynamic) test3b ... done
final link ... done
Prelude> :load htest3.hs
[1 of 1] Compiling Main ( htest3.hs, interpreted )
During interactive linking, GHCi couldn't find the following symbol:
test
```
the actual symbol in the object file is **_test\@4**
### TEST 4A
```
ghci -fglasgow-exts test1a.o
Prelude> :load htest3
[1 of 1] Compiling Main ( htest3.hs, interpreted )
Ok, modules loaded: Main.
*Main> ctest 5
The argument passed was 5
```
1. .. ghci then crashes .... as expected ...
after all ccall function was called using the stdcall calling convention !
but the module should not have loaded as ghci should have been looking for a
**_test\@4** symbol
## TEST 5
### test_proxy5a.c
```
#include <stdio.h>
__declspec(dllimport) void _stdcall test(int arg);
void test_proxy(int arg)
{
test(arg);
}
```
### test_proxy5a.c
```
#include <stdio.h>
void _stdcall test(int arg);
void test_proxy(int arg)
{
test(arg);
}
```
### htest5.hs
```
module Main where
import Foreign
import Foreign.C
foreign import ccall "test_proxy" ctest :: CInt -> IO ()
```
### COMPILATION OF C OBJECTS
```
gcc -c test_proxy5a.c
gcc -c test_proxy5b.c
```
### TEST 5A
```
E:\vvv\WP03\S00\ffi>ghci -fglasgow-exts test_proxy5a.o -ltest3b
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done.
Loading object (static) test_proxy5a.o ... done
Loading object (dynamic) test3b ... done
:
test_proxy5a.o: unknown symbol `__imp__test'
final link ... : linking extra libraries/objects failed
```
### TEST 5B
```
E:\vvv\WP03\S00\ffi>ghci -fglasgow-exts test_proxy5b.o -ltest3b
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done.
Loading object (static) test_proxy5b.o ... done
Loading object (dynamic) test3b ... done
final link ... done
Prelude> :load htest5
[1 of 1] Compiling Main ( htest5.hs, interpreted )
Ok, modules loaded: Main.
*Main> ctest 5
The argument passed was 5
*Main>
```
### TEST 5C
```
E:\vvv\WP03\S00\ffi>ghci -fglasgow-exts test_proxy5b.o -ltest1b
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done.
Loading object (static) test_proxy5b.o ... done
Loading object (dynamic) test1b ... done
final link ... done
Prelude> :load htest5
[1 of 1] Compiling Main ( htest5.hs, interpreted )
Ok, modules loaded: Main.
*Main> ctest 5
The argument passed was 5
*Main> ctest 5
The argument passed was 5
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci 6.6 foreign import stdcall broken, panic, panic!!!!","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":["dll","ffi","foreign","ghci","import","stdcall"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"'''ghci 6.6 foreign import stdcall broken, panic, panic!!!!'''\r\n\r\nI would like to report what I think is a problem with GHCI foreign function imports \r\nof c functions declared with stdcall calling convention (1) and also with loading objects containing dll imports (2).\r\n\r\n= WHAT IS THE PROBLEM ? =\r\n\r\n== 1. ghci handling of mangling of stdcall function names broken ==\r\n{{{\r\nPrelude> :load htest3\r\n[1 of 1] Compiling Main ( htest3.hs, interpreted )\r\n\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n test\r\nThis may be due to you not asking GHCi to load extra object files,\r\narchives or DLLs needed by your current session. Restart GHCi, specifying\r\nthe missing library using the -L/path/to/object/dir and -lmissinglibname\r\nflags, or simply by naming the relevant files on the GHCi command line.\r\nAlternatively, this link failure might indicate a bug in GHCi.\r\nIf you suspect the latter, please send a bug report to:\r\n glasgow-haskell-bugs@haskell.org\r\n}}}\r\n\r\n== 2. ghci loading of c object files dll imports name resolution broken ==\r\n{{{\r\n>ghci -fglasgow-exts test_proxy5a.o -ltest3b\r\n\r\ntest_proxy5a.o: unknown symbol `__imp__test'\r\nfinal link ... : linking extra libraries/objects failed\r\n\r\n}}}\r\n\r\ndetail follows ...\r\n\r\n= CONCLUSSION REACHED =\r\n\r\n== 1. Importing Stdcall Symbols ==\r\n\r\nghci dose not correctly look for symbols decorated in the stdcall manner in the \r\nobject files ie. it looks for '''_test''' when it should (according to stdcall convention) look for '''_test@4'''.\r\n\r\nstdcall symbols in object files are decorated with the number of bytes that should \r\nbe popped from the stack before the function returns.\r\n\r\n== 2. linking objects with dllimports ==\r\n\r\nghci cannot properly resolve dllimports in c object files i.e. if an object loaded by ghci \r\n(eg test_proxy, with c function test_proxy) calls functions from a dll (eg \r\n'''test''') then \r\nthat function in the object file will be decorated as '''`__imp__test`''' \r\nthis in normal course linked agains a .lib or a .a file will be resolved to '''_test''' \r\nfunction in the dll but ghci does not do this.\r\n\r\nOffcourse these problems go away when using ghc ... but well what's the point of ghci then?\r\n\r\n= SUMMARY OF TESTS and METHODOLOGY =\r\n\r\n== 1. Reference Case ==\r\n\r\nverify that ccall works ..\r\n [[BR]]Create c file test1a.c and function test(int) in the file\r\n [[BR]]create haskell file htest1.hs with function ctest calling test\r\n [[BR]]check this works ok with \r\n\r\n a. c object loaded (test1a.c, htest1.hs )-- OK, RIGHT [[BR]]\r\n b. windows dll, c is function a dll export (test1b.c, htest1.hs ) -- OK, RIGHT\r\n \r\n== 3. change calling convention to stdcall ==\r\n\r\n a. check loading of function from object (test3a.c, htest3.hs) -- FAIL, WRONG[[BR]]\r\n b. check loading of stdcall function from dll -- FAIL, WRONG\r\n\r\n== 4. try what shouldn't work ==\r\n\r\n a. htest3 against object test1a\r\n i.e. what hapens when you try loading a haskell module with foreign import stdcall against c function declared with ccall convention.\r\n \r\n ghci loaded -- OK!!, WRONG, \r\n\r\n it should not have resolved the symbol and not loaded.[[BR]]\r\n ghci called the function and crashed -- given that it resolved the symbol and called the function, this is expected.\r\n\r\n b. htest3 against dll htest1b.dll\r\n same result as 4a -- expected, \r\n\r\nbehaviour consistent in both cases with resolving stdcall callouts \r\n(symbol '''test''') in a manner consistent with ccalls.\r\ni.e. resolving the call to c function '''test''' as a call to symbol '''_test'''\r\nrather than '''_test@4''' as it should be according to the stdcall convention.\r\n\r\nyet the function is called as a stdcall c function, consequently ghci crashes when\r\nthe ccall function returns and the stack has not been cleared of the function arguments, as is required by the stdcall convention.\r\n\r\n== 5. Lets try a proxy function/object ==\r\n\r\nHmm, lets see what happens when we have a ccall c proxy function calling stdcall c \r\nfunction in dll etc?\r\n\r\n a. test_proxy5a.o with test3b.dll\r\n ccall function calling stdcall function in dll\r\n {{{\r\n unknown symbol __imp__test \r\n }}}\r\n \r\n FAILED, WRONG.\r\n\r\n dllimports are decorated with '''`__imp__`''' so a stdcall dllimport to a c function \r\n '''test''' will appear as '''`__imp__test@4`''' \r\n the dll will export symbol '''_test@4''', usually it is the function of the import \r\n library ( .a or .lib depending upon which linker mingw or msvc ) to resolve \r\n'''`__imp_test@4`''' to reference '''_test@4''' in the dll\r\n\r\n b. test_proxy5b.o with test3b.dll, htest5.hs\r\n ccall function calling stdcall function (not declared as dllimport)\r\n \r\n LOADS OK, RUNS OK\r\n \r\n test_proxy5b imports symbol '''_test@4''' the test3b.dll exports symbol \r\n '''_test@4'''. Arguably this is correct behaviour as '''`__imp__`''' decoration is an \r\n MS innovation and case (a) should be handled together with case (b).\r\n\r\n c. whell what about test_proxy5b.o with test1b.dll \r\n i.e. c stdcall to a c function declared with ccall convention from .o object \r\nloaded by ghci should fail to resolve symbols, should crash program but does niether ???? \r\n\r\n hey this has me stumped test_proxy5b.o imports symbol '''_test@4'''. test1b.dll \r\n exports symbol '''_test''' hmmm how is the symbol '''_test@4''' resolved ??? why \r\n isn't the stack corrupted when '''test''' is called ??? MYSTERY ???\r\n\r\n= DETAIL =\r\n{{{\r\ncompiler: ghci version 6.6\r\nplatform: windows XP\r\n}}}\r\n\r\n''notes-''\r\n\r\n * test1[a,b].c \r\n * test3[a,b].c\r\n\r\ndifference in these files between a,b version is that the b version declares \r\ndllexport, required when building a dll with msvc (and not using def file), not relevant with \r\nmingw and using \"dllwrap --export-all-symbols\"\r\n\r\n== TEST 1 ==\r\n\r\n=== test1a.c ===\r\n\r\n{{{\r\n#include <stdio.h>\r\n\r\nvoid test(int arg)\r\n{\r\n printf(\"The argument passed was %i\\n\", arg );\r\n}\r\n}}}\r\n\r\n=== test1b.c ===\r\n\r\n{{{\r\n#include <stdio.h>\r\n\r\n__declspec(dllexport) void test(int arg)\r\n{\r\n printf(\"The argument passed was %i\\n\", arg );\r\n}\r\n}}}\r\n\r\n=== htest1.hs ===\r\n\r\n{{{\r\nimport Foreign\r\nimport Foreign.C\r\n\r\n\r\nforeign import ccall \"test\" ctest :: CInt -> IO ()\r\n}}}\r\n\r\n=== COMPILATION OF C DLL/OBJECTS ===\r\n\r\n{{{\r\ngcc -c test1a.c\r\ngcc -c test1b.c\r\nar -rv test1b.a test1b.o\r\ndllwrap --export-all-symbols --output-lib test1b.dll.a -o test1b.dll test1b.a\r\n}}}\r\n\r\n=== TEST 1A results ===\r\n\r\n{{{\r\nghci -fglasgow-exts test1a.o\r\nLoading package base ... linking ... done.\r\nLoading object (static) test1a.o ... done\r\nfinal link ... done\r\nPrelude> :load htest1\r\n[1 of 1] Compiling Main ( htest1.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> ctest 5\r\nThe argument passed was 5\r\n*Main>\r\n}}}\r\n\r\n=== TEST 1B ===\r\n\r\n{{{\r\nghci -fglasgow-exts -ltest1b\r\nLoading package base ... linking ... done.\r\nLoading object (dynamic) test1b ... done\r\nfinal link ... done\r\n\r\nPrelude> :load htest1\r\n[1 of 1] Compiling Main ( htest1.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> ctest 5\r\nThe argument passed was 5\r\n*Main>\r\n}}}\r\n\r\n== TEST 3 ==\r\n\r\n=== test3a.c ===\r\n\r\n{{{\r\n#include <stdio.h>\r\n\r\nvoid _stdcall test(int arg)\r\n{\r\n printf(\"The argument passed was %i\\n\", arg );\r\n}\r\n}}}\r\n\r\n=== test3b.c ===\r\n\r\n{{{\r\n#include <stdio.h>\r\n\r\n__declspec(dllexport) void _stdcall test(int arg)\r\n{\r\n printf(\"The argument passed was %i\\n\", arg );\r\n}\r\n}}}\r\n\r\n=== htest3.hs ===\r\n\r\n{{{\r\nimport Foreign\r\nimport Foreign.C\r\n\r\n\r\nforeign import stdcall \"test\" ctest :: CInt -> IO ()\r\n}}}\r\n\r\n=== COMPILATION OF C DLL/OBJECTS ===\r\n\r\n{{{\r\ncompilation (mingw)\r\ngcc -c test3a.c\r\ngcc -c test3b.c\r\nar -rv test3b.a test3b.o\r\nE:\\vvv\\WP03\\S00\\ffi>dllwrap --export-all-symbols --output-lib test3b.dll.a -o \r\n\r\ntest3b.dll test3b.a\r\n\r\ncompilation msvc (same result with both mingw and msvc dll!!)\r\ncl -c test3.c\r\nlink etc ...\r\n}}}\r\n\r\n=== TEST 3A ===\r\n\r\n{{{\r\nghci -fglasgow-exts test3a.o\r\nLoading package base ... linking ... done.\r\nLoading object (static) test3a.o ... done\r\nfinal link ... done\r\n\r\nPrelude> :load htest3.hs\r\n[1 of 1] Compiling Main ( htest3.hs, interpreted )\r\n\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n test\r\n}}}\r\n\r\n=== TEST 3B ===\r\n\r\n{{{\r\nghci -fglasgow-exts -ltest3b\r\nLoading package base ... linking ... done.\r\nLoading object (dynamic) test3b ... done\r\nfinal link ... done\r\n\r\nPrelude> :load htest3.hs\r\n[1 of 1] Compiling Main ( htest3.hs, interpreted )\r\n\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n test\r\n}}}\r\n\r\nthe actual symbol in the object file is '''_test@4'''\r\n\r\n=== TEST 4A ===\r\n\r\n{{{\r\nghci -fglasgow-exts test1a.o\r\nPrelude> :load htest3\r\n[1 of 1] Compiling Main ( htest3.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> ctest 5\r\nThe argument passed was 5\r\n\r\n}}}\r\n\r\n... ghci then crashes .... as expected ...\r\nafter all ccall function was called using the stdcall calling convention !\r\nbut the module should not have loaded as ghci should have been looking for a \r\n'''_test@4''' symbol\r\n\r\n== TEST 5 ==\r\n\r\n=== test_proxy5a.c ===\r\n\r\n{{{\r\n#include <stdio.h>\r\n\r\n__declspec(dllimport) void _stdcall test(int arg);\r\n\r\nvoid test_proxy(int arg)\r\n{\r\n test(arg);\r\n}\r\n}}}\r\n\r\n=== test_proxy5a.c ===\r\n\r\n{{{\r\n#include <stdio.h>\r\n\r\nvoid _stdcall test(int arg); \r\n\r\nvoid test_proxy(int arg)\r\n{\r\n test(arg);\r\n}\r\n}}}\r\n\r\n=== htest5.hs ===\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport Foreign\r\nimport Foreign.C\r\n\r\n\r\nforeign import ccall \"test_proxy\" ctest :: CInt -> IO ()\r\n}}}\r\n\r\n=== COMPILATION OF C OBJECTS ===\r\n\r\n{{{\r\ngcc -c test_proxy5a.c\r\ngcc -c test_proxy5b.c\r\n\r\n}}}\r\n\r\n=== TEST 5A ===\r\n\r\n{{{\r\nE:\\vvv\\WP03\\S00\\ffi>ghci -fglasgow-exts test_proxy5a.o -ltest3b\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base ... linking ... done.\r\nLoading object (static) test_proxy5a.o ... done\r\nLoading object (dynamic) test3b ... done\r\n:\r\ntest_proxy5a.o: unknown symbol `__imp__test'\r\nfinal link ... : linking extra libraries/objects failed\r\n}}}\r\n\r\n=== TEST 5B ===\r\n\r\n{{{\r\nE:\\vvv\\WP03\\S00\\ffi>ghci -fglasgow-exts test_proxy5b.o -ltest3b\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base ... linking ... done.\r\nLoading object (static) test_proxy5b.o ... done\r\nLoading object (dynamic) test3b ... done\r\nfinal link ... done\r\nPrelude> :load htest5\r\n[1 of 1] Compiling Main ( htest5.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> ctest 5\r\nThe argument passed was 5\r\n*Main>\r\n}}}\r\n\r\n=== TEST 5C ===\r\n\r\n{{{\r\nE:\\vvv\\WP03\\S00\\ffi>ghci -fglasgow-exts test_proxy5b.o -ltest1b\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base ... linking ... done.\r\nLoading object (static) test_proxy5b.o ... done\r\nLoading object (dynamic) test1b ... done\r\nfinal link ... done\r\nPrelude> :load htest5\r\n[1 of 1] Compiling Main ( htest5.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> ctest 5\r\nThe argument passed was 5\r\n*Main> ctest 5\r\nThe argument passed was 5\r\n\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/1312runghc doesn't respect -main-is2019-07-07T19:14:11ZSimon Marlowrunghc doesn't respect -main-isrunghc always invokes `Main.main`, it doesn't pay any attention to a `-main-is` flag if there is one. The right way to fix this is for `runghc` to invoke GHCi's `:main` command, but unfortunately then we'd need to pass multiple commands ...runghc always invokes `Main.main`, it doesn't pay any attention to a `-main-is` flag if there is one. The right way to fix this is for `runghc` to invoke GHCi's `:main` command, but unfortunately then we'd need to pass multiple commands to `ghc -e`, because we also need to `:set prog`, for example. So probably `ghc -e` should split the input expression into lines and execute each line as a separate statement/command.
<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 | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"runghc doesn't respect -main-is","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"runghc always invokes `Main.main`, it doesn't pay any attention to a `-main-is` flag if there is one. The right way to fix this is for `runghc` to invoke GHCi's `:main` command, but unfortunately then we'd need to pass multiple commands to `ghc -e`, because we also need to `:set prog`, for example. So probably `ghc -e` should split the input expression into lines and execute each line as a separate statement/command.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1370Obscure loop in interaction between arity and case-of-bottom2019-07-07T19:13:51ZSimon Peyton JonesObscure loop in interaction between arity and case-of-bottomJohn Meacham discovered that this program makes the simplifier loop:
```
newtype T = V T deriving(Eq,Ord)
```
It's a silly program, but it shouldn't kill GHC! I investigated and the reason is because we get this:
```
rec { compare :...John Meacham discovered that this program makes the simplifier loop:
```
newtype T = V T deriving(Eq,Ord)
```
It's a silly program, but it shouldn't kill GHC! I investigated and the reason is because we get this:
```
rec { compare :: T -> T -> Ordering
compare [arity 2] = compare }
max :: T -> T -> T
max x y = case compare x y of { GT -> x; other -> y }
```
The real bug is that `compare` has been eta-reduced, but still has arity 2. That's wrong. Anyway, since `compare` diverges, we get
```
max x y = compare `cast` UnsafeCoerce (T->T->T) T
```
and now we try to eta-expand the RHS of `max`, and that is a stupid thing to do (and loops in `CoreUtils.etaExpand`.
The real bug is the unsound eta-reducion for `compare`, which I knew about (comments in `Note [Add IdInfo back onto a let-bound Id]` in `SimplEnv`).
It's a dark corner case, and I'm not going to fix it today.
<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":"Obscure loop in interaction between arity and case-of-bottom","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"John Meacham discovered that this program makes the simplifier loop:\r\n{{{\r\nnewtype T = V T deriving(Eq,Ord)\r\n}}}\r\nIt's a silly program, but it shouldn't kill GHC! I investigated and the reason is because we get this:\r\n{{{\r\n rec { compare :: T -> T -> Ordering\r\n compare [arity 2] = compare }\r\n \r\n max :: T -> T -> T\r\n max x y = case compare x y of { GT -> x; other -> y }\r\n}}}\r\nThe real bug is that `compare` has been eta-reduced, but still has arity 2. That's wrong. Anyway, since `compare` diverges, we get\r\n{{{\r\n max x y = compare `cast` UnsafeCoerce (T->T->T) T\r\n}}}\r\nand now we try to eta-expand the RHS of `max`, and that is a stupid thing to do (and loops in `CoreUtils.etaExpand`.\r\n\r\nThe real bug is the unsound eta-reducion for `compare`, which I knew about (comments in `Note [Add IdInfo back onto a let-bound Id]` in `SimplEnv`). \r\n\r\nIt's a dark corner case, and I'm not going to fix it today.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Simon Peyton JonesSimon Peyton Joneshttps://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/1429:list gets confused by bang patterns in .lhs files2019-07-07T19:13:35Zmnislaih:list gets confused by bang patterns in .lhs filesA bang pattern in a .lhs file confuses :list by one lineA bang pattern in a .lhs file confuses :list by one line6.8.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1495newtype fixpoint sends the compiler into an infinite loop2019-07-07T19:13:13Zguestnewtype fixpoint sends the compiler into an infinite loopI was playing around with some edge cases in the type system and hit an infinite loop compiling the following program:
```
module CompilerBug where
newtype Fix a = Fix (a (Fix a))
data ID a = ID a
newtype I a = I a
testOk :: Fix ID
te...I was playing around with some edge cases in the type system and hit an infinite loop compiling the following program:
```
module CompilerBug where
newtype Fix a = Fix (a (Fix a))
data ID a = ID a
newtype I a = I a
testOk :: Fix ID
testOk = undefined
-- this definition causes the compiler to fail to terminate
testInfiniteLoop :: Fix I
testInfiniteLoop = undefined
```
<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 | Windows |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"newtype fix sends the compiler into an infinite loop","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"I was playing around with some edge cases in the type system and hit an infinite loop compiling the following program:\r\n\r\n{{{\r\nmodule CompilerBug where\r\n\r\nnewtype Fix a = Fix (a (Fix a))\r\ndata ID a = ID a\r\nnewtype I a = I a\r\n\r\ntestOk :: Fix ID\r\ntestOk = undefined\r\n\r\n-- this definition causes the compiler to fail to terminate\r\ntestInfiniteLoop :: Fix I\r\ntestInfiniteLoop = undefined\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/1523Constant overhead of threadDelay2019-07-07T19:13:04ZManuel M T ChakravartyConstant overhead of threadDelayOn x86/MacOS 10.4.10, the function Control.Concurrenct.threadDelay has a constant overhead of 100-200ms. Consequently, the observed delay is 100-200ms longer than the specified delay and 100-200ms is the minimum delay that can be realise...On x86/MacOS 10.4.10, the function Control.Concurrenct.threadDelay has a constant overhead of 100-200ms. Consequently, the observed delay is 100-200ms longer than the specified delay and 100-200ms is the minimum delay that can be realised.
When run under `ktrace`, the Haskell process spends the time in a larger number of poll-like `select()` calls. I observed around 2800 `select()` calls for `threadDelay 1`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Constant overhead of threadDelay","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On x86/MacOS 10.4.10, the function Control.Concurrenct.threadDelay has a constant overhead of 100-200ms. Consequently, the observed delay is 100-200ms longer than the specified delay and 100-200ms is the minimum delay that can be realised.\r\n\r\nWhen run under `ktrace`, the Haskell process spends the time in a larger number of poll-like `select()` calls. I observed around 2800 `select()` calls for `threadDelay 1`.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/1583GHCi + large Integer arithmetic + Ctrl-C = bad2019-07-07T19:12:48ZIsaac DupreeGHCi + large Integer arithmetic + Ctrl-C = badNow detected and mostly repeatable on x86, not just powerpc.
```
$ ghci
Prelude> product [1..50000]
[press control-C repeatedly, without pausing the assault,
until the following line appears:]
3347320509<interactive>: exception :: Ghc...Now detected and mostly repeatable on x86, not just powerpc.
```
$ ghci
Prelude> product [1..50000]
[press control-C repeatedly, without pausing the assault,
until the following line appears:]
3347320509<interactive>: exception :: GhcException
[sometimes this line appears instead, in which case try
again until GhcException reproduced:
3347320509Interrupted.]
```
The exact number of digits printed can vary - they ARE the initial digits of 50000! (factorial), by the way. The `GhcException` can happen whether this expression is the first thing to be entered into the ghci prompt session or not. Once it happens, the terminal is rather frozen, although control-Z to suspend ghci and regain a shell prompt, seems to make the terminal usable again, and `kill (ghc's pid)` or `kill -9 (ghc's pid)` (I needed the -9/-KILL once and not another time I tried, inexplicably) also returns from ghci to my shell.
Even when not so many control-C's are used and it just says Interrupted, ghci takes an awfully long time before returning to the ghci prompt, which is undesirable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"GHCi + large Integer arithmetic + Ctrl-C = bad","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Now detected and mostly repeatable on x86, not just powerpc.\r\n{{{\r\n$ ghci\r\nPrelude> product [1..50000]\r\n[press control-C repeatedly, without pausing the assault,\r\n until the following line appears:]\r\n3347320509<interactive>: exception :: GhcException\r\n[sometimes this line appears instead, in which case try\r\n again until GhcException reproduced:\r\n 3347320509Interrupted.]\r\n}}}\r\nThe exact number of digits printed can vary - they ARE the initial digits of 50000! (factorial), by the way. The `GhcException` can happen whether this expression is the first thing to be entered into the ghci prompt session or not. Once it happens, the terminal is rather frozen, although control-Z to suspend ghci and regain a shell prompt, seems to make the terminal usable again, and `kill (ghc's pid)` or `kill -9 (ghc's pid)` (I needed the -9/-KILL once and not another time I tried, inexplicably) also returns from ghci to my shell.\r\n\r\nEven when not so many control-C's are used and it just says Interrupted, ghci takes an awfully long time before returning to the ghci prompt, which is undesirable.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1621GHCi wrong execution time report2019-07-07T19:12:34ZguestGHCi wrong execution time reportHello,
using latest GHC 6.6.1 binary package for windows, I've received strange information about execution time for the module below.
My machine: OS WinXP Pro SP2, Intel Core 2, 2GB RAM.
How to reproduce error:
```
:set +s
:set -02
...Hello,
using latest GHC 6.6.1 binary package for windows, I've received strange information about execution time for the module below.
My machine: OS WinXP Pro SP2, Intel Core 2, 2GB RAM.
How to reproduce error:
```
:set +s
:set -02
:cd <path to the file in the attachment>
:l Primes
```
Then running
```
take 10000 primes1
take 10000 primes2
take 10000 primes3
take 10000 primes1'
take 10000 primes2'
take 10000 primes3'
```
Results seem to be correct, but the execution time reported no. First column is the GHCi report, the second column is th stop-watch data (just to correlate). No other task, except core windows, was running at the moment.
```
GHCi Stop-watch
236.03 672.2
63.52 63.9
63.01 64.0
1098.75 671.0
-365.07 65.2 // it's not a typo, really minus three hundred and sixty five
63.59 63.6
```
Best regards,
> Dusan
---------
```
module Primes (
primes1
,primes2
,primes3
,primes2'
,primes3'
) where
candidates = map (\x -> (True,x)) [2..]
candidates' = [2..]
skipmap f toSkip list = domap toSkip list
where
domap n (x:xs)
| n > 1 = x : domap (n-1) xs
| True = f x : domap toSkip xs
domap _ [] = []
primes1 = sieve candidates
where
sieve (pp@(isp,p):xs)
| isp = p : (sieve $ skipmap (\(_,v) -> (False,v)) p xs)
| True = sieve xs
primes1' = sieve candidates'
where
sieve (p:xs)
| p > 0 = p : (sieve $ skipmap (\n -> if n>0 then (-n) else n) p xs)
| True = sieve xs
sieve (p:xs) = p : sieve [y | y <- xs, y `mod` p /= 0]
sieve' (p:xs) = p : sieve [y | y <- xs, y `mod` p > 0]
primes2 = sieve [2..]
primes3 = 2 : sieve [3,5..]
primes2' = sieve' [2..]
primes3' = 2 : sieve' [3,5..]
```6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>