GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:37:48Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/10046Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales2019-07-07T18:37:48ZHoward B. GoldenLinker script patch in rts/Linker.c doesn't work for (non-C or non-en..) localesPlease see [ticket:2615\#comment:95729](https://gitlab.haskell.org//ghc/ghc/issues/2615#note_95729) and replies.
A bug is illustrated by this Haskell program:
```
import ObjLink
import Foreign
import Foreign.C.Types
import Foreign.C.St...Please see [ticket:2615\#comment:95729](https://gitlab.haskell.org//ghc/ghc/issues/2615#note_95729) and replies.
A bug is illustrated by this Haskell program:
```
import ObjLink
import Foreign
import Foreign.C.Types
import Foreign.C.String
foreign import ccall "setlocale" c_setlocale :: CInt -> CString -> IO CString
main = do
withCString "zh_CN.UTF-8" $ \lc -> c_setlocale 5 lc
r <- loadDLL "/usr/lib/libc.so"
putStrLn (show r)
```
which outputs:
```
Just "/usr/lib/libc.so: \26080\25928\30340 ELF \22836"
```
The "\\26080\\25928\\30340 ELF \\22836" part is "无效的ELF头" in Chinese.
This error only occurs on systems where linker scripts are used. The linker script patch (as it has evolved) assumes that the error messages it will receive are in English. This would be true if the locale (LC_MESSAGES) is C or en (or one of the en variants). However, in other locales, the message will be in a different language. Unfortunately, the semantics of POSIX dlerror() specify that the error is returned as a pointer to a human-readable text string, rather than an error code. The string returned depends on the locale.
The code could be made more robust by momentarily changing the locale (LC_MESSAGES) to C before calling dlerror() and reverting it to its previous value immediately after. This has been tested on a zh_CN.utf-8 (see [ticket:2615\#comment:95752](https://gitlab.haskell.org//ghc/ghc/issues/2615#note_95752)) and works. The only concern I have is in the case of multithreaded code that _might_ be affected if it is running while the locale is changed. I don't know enough to know if this is a real issue or not, nor do I know how to deal with it if necessary.
Also see #9237 for another corner case in the linker script code that should be dealt with at the same time.8.0.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8981ghc-pkg complains about missing haddock interface files2022-07-07T15:20:45Zthoughtpoliceghc-pkg complains about missing haddock interface filesAs Conal reported on the mailing list\[1\], `ghc-pkg check` on Mavericks allegedly returns:
```
bash-3.2$ ghc-pkg check
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.ha...As Conal reported on the mailing list\[1\], `ghc-pkg check` on Mavericks allegedly returns:
```
bash-3.2$ ghc-pkg check
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file
Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file
Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory
```
It's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not.
Marking for 7.8.2. I'm looking into this soon.
\[1\]http://www.haskell.org/pipermail/glasgow-haskell-users/2014-April/024846.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Fuuzetsu |
| Operating system | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg complains about missing haddock interface files","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"7.8.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1","keywords":["ghc-pkg"],"differentials":[],"test_case":"","architecture":"","cc":["Fuuzetsu"],"type":"Bug","description":"As Conal reported on the mailing list[1], `ghc-pkg check` on Mavericks allegedly returns:\r\n\r\n{{{\r\n\r\nbash-3.2$ ghc-pkg check\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file\r\n Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file\r\n Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory\r\n\r\n}}}\r\n\r\nIt's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not.\r\n\r\nMarking for 7.8.2. I'm looking into this soon.\r\n\r\n[1]http://www.haskell.org/pipermail/glasgow-haskell-users/2014-April/024846.html","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/8695Arithmetic overflow from (minBound :: Int) `quot` (-1)2024-03-17T18:32:24ZrleslieArithmetic overflow from (minBound :: Int) `quot` (-1)According to the documentation for Data.Int, “All arithmetic is performed modulo 2!\^n, where n is the number of bits in the type.”
However, this promise is broken by the following exception:
```
Prelude> (minBound :: Int) `quot` (-1)
...According to the documentation for Data.Int, “All arithmetic is performed modulo 2!\^n, where n is the number of bits in the type.”
However, this promise is broken by the following exception:
```
Prelude> (minBound :: Int) `quot` (-1)
*** Exception: arithmetic overflow
```
(This also occurs with Int8, Int16, Int32, and Int64, and likewise for `div`.)
If all arithmetic is performed modulo 2!\^n, I would rather expect the above to evaluate to `minBound`, since after all `minBound * (-1) == minBound`. The fact that an exception is raised adds an unnecessary burden in pure code to ensure `quot` (or `div`) is never called with these specific arguments.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/haskell2010 |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Arithmetic overflow from (minBound :: Int) `quot` (-1)","status":"New","operating_system":"","component":"libraries/haskell2010","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to the documentation for Data.Int, “All arithmetic is performed modulo 2!^n, where n is the number of bits in the type.”\r\n\r\nHowever, this promise is broken by the following exception:\r\n\r\n{{{\r\nPrelude> (minBound :: Int) `quot` (-1)\r\n*** Exception: arithmetic overflow\r\n}}}\r\n\r\n(This also occurs with Int8, Int16, Int32, and Int64, and likewise for `div`.)\r\n\r\nIf all arithmetic is performed modulo 2!^n, I would rather expect the above to evaluate to `minBound`, since after all `minBound * (-1) == minBound`. The fact that an exception is raised adds an unnecessary burden in pure code to ensure `quot` (or `div`) is never called with these specific arguments.","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/8362Filesystem related tests failed on solaris (SmartOS)2019-07-07T18:45:23ZlerouxFilesystem related tests failed on solaris (SmartOS)Getting filesystem (files/permissions) related test faiures on SmartOS (32bit).
```
$ uname -a
SunOS pkgx86 5.11 joyent_20130919T215407Z i86pc i386 i86pc Solaris
```
Unexpected failures: `TEST="openFile003 getPermissions001 processGrou...Getting filesystem (files/permissions) related test faiures on SmartOS (32bit).
```
$ uname -a
SunOS pkgx86 5.11 joyent_20130919T215407Z i86pc i386 i86pc Solaris
```
Unexpected failures: `TEST="openFile003 getPermissions001 processGroup002 user001 posix005"`
The testsuite output is attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Filesystem related tests failed on solaris (SmartOS)","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"7.8.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Getting filesystem (files/permissions) related test faiures on SmartOS (32bit).\r\n\r\n{{{\r\n$ uname -a\r\nSunOS pkgx86 5.11 joyent_20130919T215407Z i86pc i386 i86pc Solaris\r\n}}}\r\n\r\nUnexpected failures: `TEST=\"openFile003 getPermissions001 processGroup002 user001 posix005\"`\r\n\r\nThe testsuite output is attached.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/8285unexpected behavior with encodeFloat on large inputs2019-07-07T18:45:43ZCarter Schonwaldunexpected behavior with encodeFloat on large inputs```
> encodeFloat 1 1023
8.98846567431158e307 -- ok
> encodeFloat 1 1024
Infinity -- ok
> encodeFloat 1 (2^31 - 1)
Infinity -- ok
> encodeFloat 1 (2^31)
0.0 -- not ok
``````
> encodeFloat 1 1023
8.98846567431158e307 -- ok
> encodeFloat 1 1024
Infinity -- ok
> encodeFloat 1 (2^31 - 1)
Infinity -- ok
> encodeFloat 1 (2^31)
0.0 -- not ok
```8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/7297LLVM incorrectly hoisting loads2019-07-07T18:50:28ZdtereiLLVM incorrectly hoisting loadstest 367_letnoescape fails under LLVM as a load of the !HpLim register is hoisted out of the loop. So yielding is never done.
What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different w...test 367_letnoescape fails under LLVM as a load of the !HpLim register is hoisted out of the loop. So yielding is never done.
What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'.
All the following work:
- mark the load as volatile. (seems to give nicest code as well)
- mark the load as atomic with either monotonic or seq_cst ordering.
- mark the load as both volatile and atomic.
This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM?
And what semantics do we need to communicate? I think we are fine other than the STG registers...
So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing.
e.g., Code in question:
Bad version (LBB0_1 loops forever as load hoisted out):
```
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
movq 144(%r13), %rax
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
incq %r14
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
```
Code when marked with atomic (either monatonic or seq_cst) or both atomic and volatile:
```
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
incq %r14
movq 144(%r13), %rax
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
```
Code when marked volatile:
```
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
incq %r14
cmpq $0, 144(%r13)
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
```8.0.1dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/7246Callstack depends on way (prof, profasm, profthreaded2019-07-07T18:50:42ZJoachim Breitnermail@joachim-breitner.deCallstack depends on way (prof, profasm, profthreadedConsider the attached test case. The expected output is the that of the ```prof``` way, while for ```profasm``` and ```profthreaded```, I get this result:
```
=====> callstack003(profthreaded) 19 of 21 [0, 1, 0]
cd . && '/home/jojo/doku...Consider the attached test case. The expected output is the that of the ```prof``` way, while for ```profasm``` and ```profthreaded```, I get this result:
```
=====> callstack003(profthreaded) 19 of 21 [0, 1, 0]
cd . && '/home/jojo/dokumente/Uni/info/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o callstack003 callstack003.hs -O -prof -auto-all -threaded -fprof-auto-calls -fno-full-laziness -fno-state-hack >callstack003.comp.stderr 2>&1
cd . && ./callstack003 +RTS -p -RTS </dev/null >callstack003.run.stdout 2>callstack003.run.stderr
Actual stdout output differs from expected:
--- ./callstack003.stdout 2012-09-17 11:27:02.607458948 +0200
+++ ./callstack003.run.stdout 2012-09-17 12:20:33.988109494 +0200
@@ -1,8 +1,8 @@
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:15-17)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:22-24)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:15-17)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:22-24)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:15-17)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:22-24)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:15-17)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:22-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
*** unexpected failure for callstack003(profthreaded)
```
Not sure if this really hurts anyone, and the behavior of the call stack WRT recursive calls is anyways not quite perfect yet (see #7240), this makes adding good test cases a bit difficult.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Callstack depends on way (prof, profasm, profthreaded","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the attached test case. The expected output is the that of the ```prof``` way, while for ```profasm``` and ```profthreaded```, I get this result:\r\n\r\n{{{\r\n=====> callstack003(profthreaded) 19 of 21 [0, 1, 0]\r\ncd . && '/home/jojo/dokumente/Uni/info/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o callstack003 callstack003.hs -O -prof -auto-all -threaded -fprof-auto-calls -fno-full-laziness -fno-state-hack >callstack003.comp.stderr 2>&1\r\ncd . && ./callstack003 +RTS -p -RTS </dev/null >callstack003.run.stdout 2>callstack003.run.stderr\r\nActual stdout output differs from expected:\r\n--- ./callstack003.stdout\t2012-09-17 11:27:02.607458948 +0200\r\n+++ ./callstack003.run.stdout\t2012-09-17 12:20:33.988109494 +0200\r\n@@ -1,8 +1,8 @@\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:15-17)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:22-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:15-17)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:22-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:15-17)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:22-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:15-17)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:22-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n*** unexpected failure for callstack003(profthreaded)\r\n}}}\r\n\r\nNot sure if this really hurts anyone, and the behavior of the call stack WRT recursive calls is anyways not quite perfect yet (see #7240), this makes adding good test cases a bit difficult.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/9307LLVM vs NCG: floating point numbers close to zero have different sign2019-07-07T18:40:56Zjrp2014LLVM vs NCG: floating point numbers close to zero have different signCompiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether th...Compiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether the numbers generated depend on some feature of the build settings, or OS.
```
HC = /Users/xxx/Projects/ghc/inplace/bin/ghc-stage2
HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -cpp -fglasgow-exts -rtsopts
RUNTEST_OPTS = -ghc-timing
==nofib== wave4main: size of wave4main follows...
__TEXT __DATA __OBJC others dec hex
4091904 450560 0 4295947176 4300489640 1005443a8
==nofib== wave4main: time to run wave4main follows...
../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000;
real 0m0.217s
user 0m0.191s
sys 0m0.011s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16932.1 2014-07-13 13:43:22.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
real 0m0.197s
user 0m0.186s
sys 0m0.008s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16961.1 2014-07-13 13:43:22.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
real 0m0.201s
user 0m0.189s
sys 0m0.009s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17011.1 2014-07-13 13:43:22.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
real 0m0.201s
user 0m0.190s
sys 0m0.008s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17051.1 2014-07-13 13:43:23.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
real 0m0.200s
user 0m0.189s
sys 0m0.009s
././wave4main 4000 < /dev/null
expected stdout not matched by reality
--- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100
+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17080.1 2014-07-13 13:43:23.000000000 +0100
@@ -1 +1 @@
-69923/1465
+69096/1465
make: *** [runtests] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"wave4main in nofib fails","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["wave4main"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nCompiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether the numbers generated depend on some feature of the build settings, or OS.\r\n\r\n\r\n{{{\r\nHC = /Users/xxx/Projects/ghc/inplace/bin/ghc-stage2\r\nHC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -cpp -fglasgow-exts -rtsopts\r\nRUNTEST_OPTS = -ghc-timing\r\n==nofib== wave4main: size of wave4main follows...\r\n__TEXT\t__DATA\t__OBJC\tothers\tdec\thex\r\n4091904\t450560\t0\t4295947176\t4300489640\t1005443a8\r\n==nofib== wave4main: time to run wave4main follows...\r\n../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000;\r\n\r\nreal\t0m0.217s\r\nuser\t0m0.191s\r\nsys\t0m0.011s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16932.1\t2014-07-13 13:43:22.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\n\r\nreal\t0m0.197s\r\nuser\t0m0.186s\r\nsys\t0m0.008s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16961.1\t2014-07-13 13:43:22.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\n\r\nreal\t0m0.201s\r\nuser\t0m0.189s\r\nsys\t0m0.009s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17011.1\t2014-07-13 13:43:22.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\n\r\nreal\t0m0.201s\r\nuser\t0m0.190s\r\nsys\t0m0.008s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17051.1\t2014-07-13 13:43:23.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\n\r\nreal\t0m0.200s\r\nuser\t0m0.189s\r\nsys\t0m0.009s\r\n././wave4main 4000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- wave4main.stdout\t2014-07-08 20:57:14.000000000 +0100\r\n+++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17080.1\t2014-07-13 13:43:23.000000000 +0100\r\n@@ -1 +1 @@\r\n-69923/1465\r\n+69096/1465\r\nmake: *** [runtests] Error 1\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/5262Compiling with -O makes some expressions too lazy and causes space leaks2022-10-24T16:34:06Zmichal.palkaCompiling with -O makes some expressions too lazy and causes space leaksHere are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execut...Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.
Here are terms that get compiled too lazy with -O only when full strictness is on:
```
seq (id (\a -> seq a (\b -> (undefined::Int))) (undefined::Bool))
\a -> seq (seq a (\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\b -> ([]::[] Int)) length
\a -> seq (id (\b -> seq b (\c -> seq)) (length a)) ([]::[] Int)
```
Here are terms which are compiled too lazy with -O regardless of full strictness:
```
seq (seq (odd (undefined::Int)) (\a -> (undefined::[] (Int -> Bool))))
foldr (\a -> seq) id ((:) True (undefined::[] Bool))
\a -> foldr (\b -> \c -> seq c (\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False
\a -> (\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\b -> (undefined::([] Bool))))
map (seq (seq (seq 0 (undefined::Bool)) (\a -> \b -> (undefined::Bool)) (undefined::Int)))
map (seq (seq (id (\a -> (undefined::Int)) ([]::[] Int)) (\a -> undefined::Bool)))
\a -> (\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\b -> (undefined::Int -> [] Int)))
```
To discover the differences, just run the terms (whose types are \[Int\] -\> \[Int\]) on some partially or fully-defined small lists.
It is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).
All programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.
Is this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiling with -O makes some expressions too lazy and causes space leaks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":["laziness,","leak","space","strictness,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.\r\n\r\nHere are terms that get compiled too lazy with -O only when full strictness is on:\r\n{{{\r\nseq (id (\\a -> seq a (\\b -> (undefined::Int))) (undefined::Bool))\r\n\\a -> seq (seq a (\\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\\b -> ([]::[] Int)) length\r\n\\a -> seq (id (\\b -> seq b (\\c -> seq)) (length a)) ([]::[] Int)\r\n}}}\r\n\r\nHere are terms which are compiled too lazy with -O regardless of full strictness:\r\n{{{\r\nseq (seq (odd (undefined::Int)) (\\a -> (undefined::[] (Int -> Bool))))\r\nfoldr (\\a -> seq) id ((:) True (undefined::[] Bool))\r\n\\a -> foldr (\\b -> \\c -> seq c (\\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False\r\n\\a -> (\\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\\b -> (undefined::([] Bool))))\r\nmap (seq (seq (seq 0 (undefined::Bool)) (\\a -> \\b -> (undefined::Bool)) (undefined::Int)))\r\nmap (seq (seq (id (\\a -> (undefined::Int)) ([]::[] Int)) (\\a -> undefined::Bool)))\r\n\\a -> (\\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\\b -> (undefined::Int -> [] Int)))\r\n}}}\r\n\r\nTo discover the differences, just run the terms (whose types are [Int] -> [Int]) on some partially or fully-defined small lists.\r\n\r\nIt is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).\r\n\r\nAll programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.\r\n\r\nIs this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug.","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4942GHC.ConsoleHandler does not call back application when Close button is pressed2019-07-07T18:57:41ZAmaticGHC.ConsoleHandler does not call back application when Close button is pressedThe test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Cl...The test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Close button is pressed.
```
import Control.Concurrent (threadDelay)
import GHC.ConsoleHandler
import System.IO
onConsoleEventReceived :: ConsoleEvent -> IO ()
onConsoleEventReceived event = withFile "console_event.log" AppendMode $ \ file -> do
hPutStrLn file $ case event of
ControlC -> "Received Ctrl-C event"
Break -> "Received Ctrl-Break event"
Close -> "Received X button event"
_ -> "Received other console event"
hFlush file
main :: IO ()
main = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)
```
The host OS is Windows XP SP3.
Please let me know if you need any more info.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lightwing15@hotmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.ConsoleHandler does not call back application when Close button is pressed","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lightwing15@hotmail.com"],"type":"Bug","description":"The test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Close button is pressed.\r\n\r\n{{{\r\nimport Control.Concurrent (threadDelay)\r\nimport GHC.ConsoleHandler\r\nimport System.IO\r\n\r\nonConsoleEventReceived :: ConsoleEvent -> IO ()\r\nonConsoleEventReceived event = withFile \"console_event.log\" AppendMode $ \\ file -> do\r\n hPutStrLn file $ case event of\r\n ControlC -> \"Received Ctrl-C event\"\r\n Break -> \"Received Ctrl-Break event\"\r\n Close -> \"Received X button event\"\r\n _ -> \"Received other console event\"\r\n hFlush file\r\n \r\nmain :: IO ()\r\nmain = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)\r\n}}}\r\n\r\nThe host OS is Windows XP SP3.\r\n\r\nPlease let me know if you need any more info.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4413(^^) is not correct for Double and Float2019-07-07T18:59:07Zdaniel.is.fischer(^^) is not correct for Double and FloatConsider
```
Prelude> 2 ^^ (-1024)
0.0
Prelude> 0.5 ^^ 1024
5.562684646268003e-309
```
The cause is
```
x ^^ n = if n >= 0 then x^n else recip (x^(negate n))
```
If we change it to
```
x ^^ n = if n >= 0 then x^n...Consider
```
Prelude> 2 ^^ (-1024)
0.0
Prelude> 0.5 ^^ 1024
5.562684646268003e-309
```
The cause is
```
x ^^ n = if n >= 0 then x^n else recip (x^(negate n))
```
If we change it to
```
x ^^ n = if n >= 0 then x^n else ((recip x)^(negate n))
```
it'll do the right thing for Double and Float, and I don't know of any type where it would produce incorrect results.
Does it need a library proposal or can the change be made without?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"(^^) is not correct for Double and Float","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":["Double,","Float,","exponentiation"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider\r\n{{{\r\nPrelude> 2 ^^ (-1024)\r\n0.0\r\nPrelude> 0.5 ^^ 1024\r\n5.562684646268003e-309\r\n}}}\r\nThe cause is\r\n{{{\r\nx ^^ n = if n >= 0 then x^n else recip (x^(negate n))\r\n}}}\r\nIf we change it to\r\n{{{\r\nx ^^ n = if n >= 0 then x^n else ((recip x)^(negate n))\r\n}}}\r\nit'll do the right thing for Double and Float, and I don't know of any type where it would produce incorrect results.\r\n\r\nDoes it need a library proposal or can the change be made without?","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1tcsavagetcsavagehttps://gitlab.haskell.org/ghc/ghc/-/issues/4049Support for ABI versioning of C libraries2019-07-07T19:00:57ZmpiechotkaSupport for ABI versioning of C librariesCurrently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.
Also it does not provide any support for ldscripts an...Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.
Also it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.
More informations:
http://bugs.gentoo.org/show_bug.cgi?id=290974
http://bugs.gentoo.org/show_bug.cgi?id=311361
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.2 |
| 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":"Support for ldscripts and ABI versioning","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.\r\n\r\nAlso it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.\r\n\r\nMore informations:\r\nhttp://bugs.gentoo.org/show_bug.cgi?id=290974\r\nhttp://bugs.gentoo.org/show_bug.cgi?id=311361","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/2401aborting an STM transaction should throw an exception2019-07-07T19:08:45Zsclvaborting an STM transaction should throw an exceptionThe attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place...The attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place on a PowerPC with 32 bit architecture and no multicore.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| 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":"unsafeIOToSTM hangs with 64 bit multicore.","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place on a PowerPC with 32 bit architecture and no multicore.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/15553GHC.IO.Encoding not flushing partially converted input2019-07-07T18:04:10ZMasahiro SakaiGHC.IO.Encoding not flushing partially converted inputConversion by `GHC.IO.Encoding` produces incomplete output for some encodings because it does not flush *partially converted input* at the end of the string.
[iconv(3)](https://manpages.debian.org/stretch/manpages-dev/iconv.3) provides ...Conversion by `GHC.IO.Encoding` produces incomplete output for some encodings because it does not flush *partially converted input* at the end of the string.
[iconv(3)](https://manpages.debian.org/stretch/manpages-dev/iconv.3) provides API for the flushing.
> In each series of calls to iconv(), the last should be one with inbuf or \*inbuf equal to NULL, in order to flush out any partially converted input.
But `GHC.IO.Encoding` does not perform the flushing properly and it can cause incomplete conversion result.
I found two cases that it actually produces incomplete output, but there might be more cases.
# Case 1: EUC-JISX0213
For example, the following code is expected to output two bytes 0xa4 0xb1, but it outputs none.
```hs
enc <- mkTextEncoding "EUC-JISX0213"
withFile "test.txt" WriteMode $ \h -> hSetEncoding h enc >> hPutStr h "\x3051"
```
The problem happens because of the following mapping between Unicode and EUC-JISX0213.
<table><tr><td>Unicode</td>
<td>EUC-JISX0213</td></tr>
<tr><td>U+3051 U+309A</td>
<td>0xa4 0xfa</td></tr>
<tr><td>U+3051</td>
<td>0xa4 0xb1</td></tr></table>
After seeing the codepoint U+3051, the converter is unable to determine which of the two byte sequence to output until it sees the next character or *the end of the string*. But `GHC.IO.Encoding` does not call the above mentioned *flushing* API, therefore the converter is unable to recognize the end of the string.
# Case 2: ISO-2022-JP
Similarly, following code is expected to output byte sequence `0x1b 0x24 0x42` `0x24 0x22` `0x1b 0x28 0x42` but the last three bytes `0x1b 0x28 0x42` is not produced.
```hs
enc <- mkTextEncoding "ISO-2022-JP"
withFile "test.txt" WriteMode $ \h -> hSetEncoding h enc >> hPutStr h "\x3042"
```
ISO-2022-JP is a stateful encoding and [RFC 1468](https://www.ietf.org/rfc/rfc1468.txt) requires the state is reset to initial state at the end of the string. The missing three bytes `0x1b 0x28 0x42` are the escape sequence for that purpose. But again `GHC.IO.Encoding` does not call the above mentioned`flushing` API, therefore the converter cannot recognize the end of the string and cannot reset the state.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.IO.Encoding not flushing partially converted input","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Conversion by `GHC.IO.Encoding` produces incomplete output for some encodings because it does not flush ''partially converted input'' at the end of the string.\r\n\r\n[https://manpages.debian.org/stretch/manpages-dev/iconv.3 iconv(3)] provides API for the flushing.\r\n\r\n> In each series of calls to iconv(), the last should be one with inbuf or *inbuf equal to NULL, in order to flush out any partially converted input.\r\n\r\nBut `GHC.IO.Encoding` does not perform the flushing properly and it can cause incomplete conversion result.\r\nI found two cases that it actually produces incomplete output, but there might be more cases.\r\n\r\n= Case 1: EUC-JISX0213\r\n\r\nFor example, the following code is expected to output two bytes 0xa4 0xb1, but it outputs none.\r\n\r\n{{{#!hs\r\nenc <- mkTextEncoding \"EUC-JISX0213\"\r\nwithFile \"test.txt\" WriteMode $ \\h -> hSetEncoding h enc >> hPutStr h \"\\x3051\"\r\n}}}\r\n\r\nThe problem happens because of the following mapping between Unicode and EUC-JISX0213. \r\n\r\n||Unicode||EUC-JISX0213||\r\n||U+3051 U+309A||0xa4 0xfa||\r\n||U+3051||0xa4 0xb1||\r\n\r\nAfter seeing the codepoint U+3051, the converter is unable to determine which of the two byte sequence to output until it sees the next character or ''the end of the string''. But `GHC.IO.Encoding` does not call the above mentioned ''flushing'' API, therefore the converter is unable to recognize the end of the string.\r\n\r\n= Case 2: ISO-2022-JP\r\n\r\nSimilarly, following code is expected to output byte sequence `0x1b 0x24 0x42` `0x24 0x22` `0x1b 0x28 0x42` but the last three bytes `0x1b 0x28 0x42` is not produced. \r\n\r\n{{{#!hs\r\nenc <- mkTextEncoding \"ISO-2022-JP\"\r\nwithFile \"test.txt\" WriteMode $ \\h -> hSetEncoding h enc >> hPutStr h \"\\x3042\"\r\n}}}\r\n\r\nISO-2022-JP is a stateful encoding and [https://www.ietf.org/rfc/rfc1468.txt RFC 1468] requires the state is reset to initial state at the end of the string. The missing three bytes `0x1b 0x28 0x42` are the escape sequence for that purpose. But again `GHC.IO.Encoding` does not call the above mentioned`flushing` API, therefore the converter cannot recognize the end of the string and cannot reset the state.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/5611Asynchronous exception discarded after safe FFI call2019-07-07T18:54:23ZjoeyadamsAsynchronous exception discarded after safe FFI call**Note:** This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.
The bug is: when an asynchronous exception is thrown to a thread making a (safe) foreig...**Note:** This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.
The bug is: when an asynchronous exception is thrown to a thread making a (safe) foreign call, the thread throwing the exception blocks like it should, but then the exception isn't actually delivered. For example:
```haskell
{-# LANGUAGE ForeignFunctionInterface #-}
import Control.Concurrent
import Foreign.C
import System.IO
foreign import ccall safe "unistd.h sleep"
sleep :: CUInt -> IO CUInt
main :: IO ()
main = do
hSetBuffering stdout LineBuffering
tid <- forkIO $ do
putStrLn "child: Sleeping"
_ <- sleep 1
-- The following lines should not happen after the killThread from the
-- parent thread completes. However, they do...
putStrLn "child: Done sleeping"
threadDelay 1000000
putStrLn "child: Done waiting"
threadDelay 100000
putStrLn $ "parent: Throwing exception to thread " ++ show tid
throwTo tid $ userError "Exception delivered successfully"
putStrLn "parent: Done throwing exception"
threadDelay 2000000
```
When the bug is present, the program prints:
```
child: Sleeping
parent: Throwing exception to thread ThreadId 4
child: Done sleeping
parent: Done throwing exception
child: Done waiting
```
"child: Done waiting" should not be printed after completion of the throwTo, and the exception message should appear. On GHC 7.2.1, the program prints:
```
child: Sleeping
parent: Throwing exception to thread ThreadId 4
parent: Done throwing exception
ffi-sleep: user error (Exception delivered successfully)
```
This bug has been reproduced in GHC 7.0.3, on both Linux and Windows. It has also been reproduced on GHC 7.0.4.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Asynchronous exception discarded after safe FFI call","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["FFI,","exception"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"'''Note:''' This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.\r\n\r\nThe bug is: when an asynchronous exception is thrown to a thread making a (safe) foreign call, the thread throwing the exception blocks like it should, but then the exception isn't actually delivered. For example:\r\n\r\n{{{\r\n\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n\r\nimport Control.Concurrent\r\nimport Foreign.C\r\nimport System.IO\r\n\r\nforeign import ccall safe \"unistd.h sleep\"\r\n sleep :: CUInt -> IO CUInt\r\n\r\nmain :: IO ()\r\nmain = do\r\n hSetBuffering stdout LineBuffering\r\n\r\n tid <- forkIO $ do\r\n putStrLn \"child: Sleeping\"\r\n _ <- sleep 1\r\n\r\n -- The following lines should not happen after the killThread from the\r\n -- parent thread completes. However, they do...\r\n putStrLn \"child: Done sleeping\"\r\n threadDelay 1000000\r\n putStrLn \"child: Done waiting\"\r\n\r\n threadDelay 100000\r\n putStrLn $ \"parent: Throwing exception to thread \" ++ show tid\r\n throwTo tid $ userError \"Exception delivered successfully\"\r\n putStrLn \"parent: Done throwing exception\"\r\n\r\n threadDelay 2000000\r\n}}}\r\n\r\nWhen the bug is present, the program prints:\r\n\r\n{{{\r\nchild: Sleeping\r\nparent: Throwing exception to thread ThreadId 4\r\nchild: Done sleeping\r\nparent: Done throwing exception\r\nchild: Done waiting\r\n}}}\r\n\r\n\"child: Done waiting\" should not be printed after completion of the throwTo, and the exception message should appear. On GHC 7.2.1, the program prints:\r\n\r\n{{{\r\nchild: Sleeping\r\nparent: Throwing exception to thread ThreadId 4\r\nparent: Done throwing exception\r\nffi-sleep: user error (Exception delivered successfully)\r\n}}}\r\n\r\nThis bug has been reproduced in GHC 7.0.3, on both Linux and Windows. It has also been reproduced on GHC 7.0.4.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7411Exceptions are optimized away in certain situations2020-05-27T16:04:30ZSimon Hengelsol@typeful.netExceptions are optimized away in certain situationsThe issue came up in [this thread on glasgow-haskell-users](http://www.haskell.org/pipermail/glasgow-haskell-users/2012-November/023027.html).
## Steps to reproduce:
```hs
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
...The issue came up in [this thread on glasgow-haskell-users](http://www.haskell.org/pipermail/glasgow-haskell-users/2012-November/023027.html).
## Steps to reproduce:
```hs
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq` return () :: IO ())
```
```
$ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs
```
### Expected result:
The program should fail with:
```
Foo: Prelude.undefined
```
### Actual result:
The program succeeds.
Compiling the program with `-fno-state-hack` helps.8.10.2Tobias Dammerstdammers@gmail.comTobias Dammerstdammers@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/21575withDict produces incorrect runtime results with optimization enabled2023-08-11T07:39:14ZRyan ScottwithDict produces incorrect runtime results with optimization enabledAfter attempting to change the `reflection` library to use `withDict` instead of `unsafeCoerce` (see #21568 for the motivation) using GHC 9.4.1-alpha1, `reflection`'s test suite started to error out. Here is a minimized example of the er...After attempting to change the `reflection` library to use `withDict` instead of `unsafeCoerce` (see #21568 for the motivation) using GHC 9.4.1-alpha1, `reflection`'s test suite started to error out. Here is a minimized example of the error:
```hs
{-# LANGUAGE CPP #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE UndecidableInstances #-}
#define WITH_DICT 1
module Main (main) where
import Control.Monad (unless)
import qualified Data.Map as M
import Data.Map (Map)
#if WITH_DICT
import GHC.Exts (withDict)
#else
import Unsafe.Coerce (unsafeCoerce)
#endif
main :: IO ()
main = do
testCase (give Normal (toJSON (Foo Bar)))
(Object (M.fromList [("Foo",String "Bar")]))
testCase (give ViaShow (toJSON (Foo Bar)))
(Object (M.fromList [("Foo",String "SHOWBAR")]))
putStrLn "All tests passed!"
-----
testCase :: (Eq a, Show a) => a -> a -> IO ()
testCase expected actual =
unless (expected == actual) $
error $ unlines
[ ""
, "Expected: " ++ show expected
, "Actual: " ++ show actual
]
class Given a where
given :: a
give :: forall a r. a -> (Given a => r) -> r
#if WITH_DICT
give = withDict @a @(Given a)
#else
give a k = unsafeCoerce (Gift k :: Gift a r) a
newtype Gift a r = Gift (Given a => r)
#endif
data Foo = Foo Bar
instance Show Foo where
show _ = "SHOWFOO"
data Bar = Bar | BarBar
instance Show Bar where
show _ = "SHOWBAR"
----------------------------------------------------------------------------
-- ToJSON instances
----------------------------------------------------------------------------
instance Given Style => ToJSON Foo where
toJSON (Foo x) = Object $ M.singleton "Foo" (toJSON x)
instance Given Style => ToJSON Bar where
toJSON x = case given of
Normal -> String $ case x of
Bar -> "Bar"
BarBar -> "BarBar"
ViaShow -> String $ show x
data Style = Normal | ViaShow
----------------------------------------------------------------------------
-- Minimized aeson
----------------------------------------------------------------------------
class ToJSON a where
toJSON :: a -> Value
data Value
= Object !(Map String Value)
| String !String
deriving (Eq, Show)
```
If you compile this with GHC 9.4.1-alpha1 plus optimization, it will unexpectedly fail:
```
$ ~/Software/ghc-9.4.0.20220501/bin/ghc Bug.hs -O -fforce-recomp
[1 of 2] Compiling Main ( Bug.hs, Bug.o )
[2 of 2] Linking Bug [Objects changed]
$ ./Bug
Bug:
Expected: Object (fromList [("Foo",String "Bar")])
Actual: Object (fromList [("Foo",String "SHOWBAR")])
CallStack (from HasCallStack):
error, called at Bug.hs:33:5 in main:Main
```
On the other hand, if you compile it without optimization, it succeeds:
```
$ ~/Software/ghc-9.4.0.20220501/bin/ghc Bug.hs -O0 -fforce-recomp
[1 of 2] Compiling Main ( Bug.hs, Bug.o )
[2 of 2] Linking Bug [Objects changed]
$ ./Bug
All tests passed!
```
This behavior appears to be exclusive to `withDict`. If I define `give` in terms of `unsafeCoerce` (which is how `reflection` currently implements `give`), then it works regardless of the optimization level:
```
$ sed -i 's/#define WITH_DICT 1/#define WITH_DICT 0/' Bug.hs
$ ~/Software/ghc-9.4.0.20220501/bin/ghc Bug.hs -O -fforce-recomp
[1 of 2] Compiling Main ( Bug.hs, Bug.o )
[2 of 2] Linking Bug [Objects changed]
$ ./Bug
All tests passed!
$ ~/Software/ghc-9.4.0.20220501/bin/ghc Bug.hs -O0 -fforce-recomp
[1 of 2] Compiling Main ( Bug.hs, Bug.o )
[2 of 2] Linking Bug [Objects changed]
$ ./Bug
All tests passed!
```9.4.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/20425complex number function errors (all platforms)2022-02-24T09:26:29Zdavjamcomplex number function errors (all platforms)## Summary
Several mathematical functions (e.g. sqrt) give incorrect values for some complex numbers.
## Steps to reproduce
Evaluate the following in GHCi:
````
> :m +Data.Complex
> sqrt $ (-4) :+ (-0)
0.0 :+ 2.0
````
## Expected be...## Summary
Several mathematical functions (e.g. sqrt) give incorrect values for some complex numbers.
## Steps to reproduce
Evaluate the following in GHCi:
````
> :m +Data.Complex
> sqrt $ (-4) :+ (-0)
0.0 :+ 2.0
````
## Expected behavior
````
> sqrt $ (-4) :+ (-0)
0.0 :+ (-2.0)
````
## Environment
* GHC version used: 8.10.7
Optional:
* Operating System: Windows and Linux
* System Architecture:
The above is one example but there are several more errors. I've coded some fixes [here](https://github.com/davjam/HaskellNumericsTestsFixes/blob/main/MyComplex.hs), though these are work in progress.
The github repo also includes some tests (and I'm trying to develop more and may uncover additional issues). I'd like to include a fuller set of tests in GHC.
(I've also just raised #20424 for related issues on real numbers in Windows. Some of the fixes for complex numbers depend on these working correctly).9.4.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22033slow validate failure: IntegerToFloat different result optllvm2022-08-16T12:54:38ZMatthew Pickeringslow validate failure: IntegerToFloat different result optllvmReproduce with
```
hadrian/build test --freeze1 --docs=none --flavour=slow-validate --test-speed=slow --only="IntegerToFloat"
```
```
+++ "/run/user/1000/ghctest-derda1up/test spaces/testsuite/tests/numeric/should_run/IntegerToFloat...Reproduce with
```
hadrian/build test --freeze1 --docs=none --flavour=slow-validate --test-speed=slow --only="IntegerToFloat"
```
```
+++ "/run/user/1000/ghctest-derda1up/test spaces/testsuite/tests/numeric/should_run/IntegerToFloat.run/IntegerToFloat.run.stdout.normalised" 2022-08-05 18:05:17.563600812 +0100
@@ -17,7 +17,7 @@
0x1p36
0x1.fffffcp59
0x1p60
-0x1.fffffep59
+0x1p60
0x1p60
0x1.fffffcp63
0x1p64
*** unexpected failure for IntegerToFloat(optllvm)
```9.4.3Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23899Nightly primops test failed on Darwin2023-09-07T09:41:40ZBryan Rbryan@haskell.foundationNightly primops test failed on DarwinJob [#1649852](https://gitlab.haskell.org/ghc/test-primops/-/jobs/1649852) failed for test-primops@e7d5ce0be2f2a56fc2103ae3d2267101fcfc8f7f
Via nightly pipeline https://gitlab.haskell.org/ghc/ghc/-/pipelines/83410Job [#1649852](https://gitlab.haskell.org/ghc/test-primops/-/jobs/1649852) failed for test-primops@e7d5ce0be2f2a56fc2103ae3d2267101fcfc8f7f
Via nightly pipeline https://gitlab.haskell.org/ghc/ghc/-/pipelines/834109.8.2Ben GamariBen Gamari