GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-08-02T17:29:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/19158ghci's :type still ignores ill-kinded type application with -fdefer-type-errors2021-08-02T17:29:55ZJakob Brünkerghci's :type still ignores ill-kinded type application with -fdefer-type-errors## Summary
#16376 was fixed in 8.10, but the same problem is still there if -fdefer-type-errors is enabled.
## Steps to reproduce
Write `:set -fdefer-type-errors` followed by `:t id @Maybe` in ghci. It produces no ouput, neither an er...## Summary
#16376 was fixed in 8.10, but the same problem is still there if -fdefer-type-errors is enabled.
## Steps to reproduce
Write `:set -fdefer-type-errors` followed by `:t id @Maybe` in ghci. It produces no ouput, neither an error nor anything else.
## Expected output
```
<interactive>:1:5: warning: [-Wdeferred-type-errors]:
• Expecting one more argument to ‘Maybe’
Expected a type, but ‘Maybe’ has kind ‘* -> *’
• In the type ‘Maybe’
In the expression: id @Maybe
id @Maybe :: t
```
## Environment
* GHC version used: 9.1.20201223
Optional:
* Operating System: Ubuntu inside WSL2 inside Windows 10
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/18871Fix Alternative instance for IO2021-07-09T19:32:10ZIsaac BergerFix Alternative instance for IO
The Alternative instance for IO is currently defined in GHC.Base, using
```
(<|>) = mplusIO
```
Hunting further, mplusIO is defined in GHC.IO as
```
mplusIO :: IO a -> IO a -> IO a
mplusIO m n = m `catchException` \ (_ :: IOError) -> n...
The Alternative instance for IO is currently defined in GHC.Base, using
```
(<|>) = mplusIO
```
Hunting further, mplusIO is defined in GHC.IO as
```
mplusIO :: IO a -> IO a -> IO a
mplusIO m n = m `catchException` \ (_ :: IOError) -> n
```
## Why this is (possibly) wrong
Quoting documentation in Control.Exception
> Applying mask to an exception handler
>
> There's an implied mask around every exception handler in a call to one of the catch family of functions. This is because that is what you want most of the time - it eliminates a common race condition in starting an exception handler, because there may be no exception handler on the stack to handle another exception if one arrives immediately. If asynchronous exceptions are masked on entering the handler, though, we have time to install a new exception handler before being interrupted. If this weren't the default, one would have to write something like
>
> mask $ \restore ->
> catch (restore (...))
> (\e -> handler)
> If you need to unmask asynchronous exceptions again in the exception handler, restore can be used there too.
>
> Note that try and friends do not have a similar default, because there is no exception handler in this case. Don't use try for recovering from an asynchronous exception.
Being that `mplusIO` only catches exceptions of type `IOError`, it is not suited for cleanup work. It is more likely useful for running a fallback action should the first one fail. In this case, one would not want to prevent asynchronous exceptions from being able to interrupt the application in the alternative branch.
So I would suggest a better implementation for `mplusIO` should be based on `try` rather than `catch`
Something like:
```
mplusIO :: IO a -> IO a -> IO a
mplusIO m n = do
res <- catchException (m >>= \ v -> return (Right v)) (\e -> return (Left e))
case res of
Right a -> return a
Left (e :: IOError) -> n
```https://gitlab.haskell.org/ghc/ghc/-/issues/10957getExecutablePath adds " (deleted)" suffix if executable was deleted under linux2021-07-06T18:59:24ZaslpavelgetExecutablePath adds " (deleted)" suffix if executable was deleted under linuxIf we remove current executable or update it with a new one, getExecutablePath returns path with added " (deleted)" suffix. I think it is incorrect behavior
, for example if you updated binary and want to exec a new one, the obvious way ...If we remove current executable or update it with a new one, getExecutablePath returns path with added " (deleted)" suffix. I think it is incorrect behavior
, for example if you updated binary and want to exec a new one, the obvious way to go is to call getExecutablePath and use it. Moreover it is inconsistent between platforms. Problem stems from the fact the getExecutablePath is implemented as readlink on /proc/self/exe and it contains gibberish once file has been deleted.
Example:
```hs
module Main (main) where
import System.Environment (getExecutablePath)
import System.Directory (removeFile)
main :: IO ()
main = do
before <- getExecutablePath
putStrLn $ "Before: " ++ before
removeFile before
after <- getExecutablePath
putStrLn $ "After: " ++ after
```
Output:
```
$ ./getExecutablePath
Before: /mnt/data/Maggot/getExecutablePath
After: /mnt/data/Maggot/getExecutablePath (deleted)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | aslpavel, ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getExecutablePath adds \" (deleted)\" suffix if executable was deleted under linux","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["aslpavel","ekmett"],"type":"Bug","description":"If we remove current executable or update it with a new one, getExecutablePath returns path with added \" (deleted)\" suffix. I think it is incorrect behavior \r\n, for example if you updated binary and want to exec a new one, the obvious way to go is to call getExecutablePath and use it. Moreover it is inconsistent between platforms. Problem stems from the fact the getExecutablePath is implemented as readlink on /proc/self/exe and it contains gibberish once file has been deleted.\r\n\r\nExample:\r\n{{{#!hs\r\nmodule Main (main) where\r\n\r\nimport System.Environment (getExecutablePath)\r\nimport System.Directory (removeFile)\r\n\r\nmain :: IO ()\r\nmain = do\r\n before <- getExecutablePath\r\n putStrLn $ \"Before: \" ++ before\r\n removeFile before\r\n after <- getExecutablePath\r\n putStrLn $ \"After: \" ++ after\r\n}}}\r\n\r\nOutput:\r\n{{{\r\n$ ./getExecutablePath \r\nBefore: /mnt/data/Maggot/getExecutablePath\r\nAfter: /mnt/data/Maggot/getExecutablePath (deleted)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/6098debugger does not know the correct type for a newtype field2021-06-28T18:58:02Zphercekdebugger does not know the correct type for a newtype fieldThis bug is in 7.4.1. I think it was also in 7.0.3. It is also in the current head:\[\[BR\]\]
commit 921530b477867edb5158e4ad5bbbdb5c7c531c97\[\[BR\]\]
Date: Tue May 15 10:32:58 2012 +0100
Here is the console log. Notice that the type o...This bug is in 7.4.1. I think it was also in 7.0.3. It is also in the current head:\[\[BR\]\]
commit 921530b477867edb5158e4ad5bbbdb5c7c531c97\[\[BR\]\]
Date: Tue May 15 10:32:58 2012 +0100
Here is the console log. Notice that the type of allItems is resolved as TWrapper but it should be \[Int\]. Expressions in conditional breakpoints are failing because of this.
```
18:06 tm=3:2 st=0 peter@phnm ~/haskell/ghc-working/inplace/lib
1035> cat bindings-bug.hs
newtype TWrapper = Wrapper
{ mItems :: [Int]
} deriving Show
main = print $ test $ Wrapper [1]
test Wrapper{ mItems = allItems } = id $
let headItem = head allItems in
headItem
18:06 tm=0 st=0 peter@phnm ~/haskell/ghc-working/inplace/lib
1036> ../../ghc/stage2/build/tmp/ghc-stage2 -B. --interactive bindings-bug.hs
GHCi, version 7.5.20120515: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( bindings-bug.hs, interpreted )
Ok, modules loaded: Main.
*Main> :break 7 37
Breakpoint 0 activated at bindings-bug.hs:(7,37)-(9,10)
*Main> :main
Stopped at bindings-bug.hs:(7,37)-(9,10)
_result :: Int = _
allItems :: TWrapper = _
[bindings-bug.hs:(7,37)-(9,10)] *Main> :list
6
vv
7 test Wrapper{ mItems = allItems } = id $
8 let headItem = head allItems in
9 headItem
^^
10
[bindings-bug.hs:(7,37)-(9,10)] *Main> head allItems
<interactive>:5:6:
Couldn't match expected type `[a0]' with actual type `TWrapper'
In the first argument of `head', namely `allItems'
In the expression: head allItems
In an equation for `it': it = head allItems
[bindings-bug.hs:(7,37)-(9,10)] *Main> :continue
1
*Main> :quit
Leaving GHCi.
18:06 tm=42 st=0 peter@phnm ~/haskell/ghc-working/inplace/lib
1037>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.5 |
| 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":"debugger does not know the correct type for a newtype field","status":"New","operating_system":"Linux","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":["bindings","debugger"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"This bug is in 7.4.1. I think it was also in 7.0.3. It is also in the current head:[[BR]]\r\ncommit 921530b477867edb5158e4ad5bbbdb5c7c531c97[[BR]]\r\nDate: Tue May 15 10:32:58 2012 +0100\r\n\r\nHere is the console log. Notice that the type of allItems is resolved as TWrapper but it should be [Int]. Expressions in conditional breakpoints are failing because of this.\r\n\r\n\r\n{{{\r\n18:06 tm=3:2 st=0 peter@phnm ~/haskell/ghc-working/inplace/lib\r\n1035> cat bindings-bug.hs\r\nnewtype TWrapper = Wrapper\r\n { mItems :: [Int]\r\n } deriving Show\r\n\r\nmain = print $ test $ Wrapper [1]\r\n\r\ntest Wrapper{ mItems = allItems } = id $\r\n let headItem = head allItems in\r\n headItem\r\n\r\n18:06 tm=0 st=0 peter@phnm ~/haskell/ghc-working/inplace/lib\r\n1036> ../../ghc/stage2/build/tmp/ghc-stage2 -B. --interactive bindings-bug.hs\r\nGHCi, version 7.5.20120515: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( bindings-bug.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> :break 7 37\r\nBreakpoint 0 activated at bindings-bug.hs:(7,37)-(9,10)\r\n*Main> :main \r\nStopped at bindings-bug.hs:(7,37)-(9,10)\r\n_result :: Int = _\r\nallItems :: TWrapper = _\r\n[bindings-bug.hs:(7,37)-(9,10)] *Main> :list\r\n6 \r\n vv\r\n7 test Wrapper{ mItems = allItems } = id $\r\n8 let headItem = head allItems in\r\n9 headItem\r\n ^^\r\n10 \r\n[bindings-bug.hs:(7,37)-(9,10)] *Main> head allItems\r\n\r\n<interactive>:5:6:\r\n Couldn't match expected type `[a0]' with actual type `TWrapper'\r\n In the first argument of `head', namely `allItems'\r\n In the expression: head allItems\r\n In an equation for `it': it = head allItems\r\n[bindings-bug.hs:(7,37)-(9,10)] *Main> :continue \r\n1\r\n*Main> :quit \r\nLeaving GHCi.\r\n18:06 tm=42 st=0 peter@phnm ~/haskell/ghc-working/inplace/lib\r\n1037> \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4471Incorrect Unicode output on Windows Console2021-06-24T22:08:45ZcamioIncorrect Unicode output on Windows ConsoleTo reproduce,
- start a windows console
- Change the console's font to a ttf unicode font, like "Lucida Console".
- Type "chcp 65001" to set it to the UTF-8 code page.
test.hs
```
main = putStrLn "∷⇒∀→←⋯⊢"
```
Output to the console i...To reproduce,
- start a windows console
- Change the console's font to a ttf unicode font, like "Lucida Console".
- Type "chcp 65001" to set it to the UTF-8 code page.
test.hs
```
main = putStrLn "∷⇒∀→←⋯⊢"
```
Output to the console is garbled. `runghc test.hs`:
```
∷⇒∀→←⋯⊢
→←⋯⊢
⋯⊢
∷⇒∀→←⋯⊢→←⋯⊢←⋯⊢⋯⊢⊢⊢⊢<stdout>: hFlush: permission denied (Permission denied)
```
Piping works correctly. `runghc test.hs > output && type output`:
```
∷⇒∀→←⋯⊢
```
ghci fails. `ghci test.hs`
```
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
∷*** Exception: <stdout>: hPutChar: permission denied (Permission denied)
*Main>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect Unicode output on Windows Console","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To reproduce,\r\n\r\n * start a windows console\r\n * Change the console's font to a ttf unicode font, like \"Lucida Console\".\r\n * Type \"chcp 65001\" to set it to the UTF-8 code page.\r\n\r\ntest.hs\r\n{{{\r\nmain = putStrLn \"∷⇒∀→←⋯⊢\"\r\n}}}\r\n\r\nOutput to the console is garbled. `runghc test.hs`:\r\n{{{\r\n∷⇒∀→←⋯⊢\r\n→←⋯⊢\r\n⋯⊢\r\n∷⇒∀→←⋯⊢→←⋯⊢←⋯⊢⋯⊢⊢⊢⊢<stdout>: hFlush: permission denied (Permission denied)\r\n}}}\r\n\r\nPiping works correctly. `runghc test.hs > output && type output`:\r\n{{{\r\n∷⇒∀→←⋯⊢\r\n}}}\r\n\r\nghci fails. `ghci test.hs`\r\n{{{\r\nGHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n[1 of 1] Compiling Main ( test.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\n∷*** Exception: <stdout>: hPutChar: permission denied (Permission denied)\r\n*Main>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/7277Recompilation check fails for TH unless functions are inlined2021-06-08T19:30:58ZorenbenkikiRecompilation check fails for TH unless functions are inlinedEven though [Issue 481](http://hackage.haskell.org/trac/ghc/ticket/481) is marked as closed, the fix is only partial. If a function inside $( ... ) is not inlined, then the dependency check fails. Attached is a full example, built around...Even though [Issue 481](http://hackage.haskell.org/trac/ghc/ticket/481) is marked as closed, the fix is only partial. If a function inside $( ... ) is not inlined, then the dependency check fails. Attached is a full example, built around the following code:
```
#ifdef NO_INLINE
{-# NOINLINE libraryFunction #-}
#endif
libraryFunction :: Q Exp
libraryFunction = [e| "Return X" |]
```
And the test:
```
case_library_function = $( libraryFunction ) @?= "Return A"
```
Here is are the relevant parts of RUNME.LOG:
```
+ rm -rf dist
+ cabal configure --enable-tests
Resolving dependencies...
Configuring dependency-bug-0.0.1...
+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Main:
library function: [Failed]
expected: "Return A"
but got: "Return B"
Test Cases Total
Passed 0 0
Failed 1 1
Total 1 1
Test suite Test: FAIL
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
0 of 1 test suites (0 of 1 test cases) passed.
```
This is as expected; we changed the source to "Return B" but the test expects the library to "Return A" so it fails. So far, so good. However:
```
+ rm -rf dist
+ cabal configure --enable-tests -fwithout-inline
Resolving dependencies...
Configuring dependency-bug-0.0.1...
+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package dependency-bug-0.0.1 ... linking ... done.
Loading package filepath-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package old-time-1.1.0.0 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package unix-2.5.1.1 ... linking ... done.
Loading package directory-1.1.0.2 ... linking ... done.
Loading package cpphs-1.14 ... linking ... done.
Loading package haskell-src-exts-1.13.5 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package regex-base-0.93.2 ... linking ... done.
Loading package regex-posix-0.95.2 ... linking ... done.
Loading package language-haskell-extract-0.2.1 ... linking ... done.
Loading package ansi-terminal-0.5.5 ... linking ... done.
Loading package ansi-wl-pprint-0.6.4 ... linking ... done.
Loading package extensible-exceptions-0.1.1.4 ... linking ... done.
Loading package hostname-1.0 ... linking ... done.
Loading package time-1.4 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package text-0.11.2.3 ... linking ... done.
Loading package xml-1.3.12 ... linking ... done.
Loading package test-framework-0.6.1 ... linking ... done.
Loading package test-framework-th-0.2.2 ... linking ... done.
Loading package HUnit-1.2.5.1 ... linking ... done.
Loading package test-framework-hunit-0.2.7 ... linking ... done.
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
```
As you can see, without-inline the 2nd build did not recompile the test, even though it should have. It only re-linked the test, so it kept seeing "Return A" even though the library actually does "Return B".
In my real code, there are no NO/INLINE pragmas; however, the TH code is complex enough that it is not inlined, which causes the same problem. I had to use the pragma to keep the example short.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Recompilation check fails for TH unless functions are inlined","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Even though [http://hackage.haskell.org/trac/ghc/ticket/481 Issue 481] is marked as closed, the fix is only partial. If a function inside $( ... ) is not inlined, then the dependency check fails. Attached is a full example, built around the following code:\r\n\r\n{{{\r\n#ifdef NO_INLINE\r\n{-# NOINLINE libraryFunction #-}\r\n#endif\r\n\r\nlibraryFunction :: Q Exp\r\nlibraryFunction = [e| \"Return X\" |]\r\n}}}\r\n\r\nAnd the test:\r\n\r\n{{{\r\ncase_library_function = $( libraryFunction ) @?= \"Return A\"\r\n}}}\r\n\r\nHere is are the relevant parts of RUNME.LOG:\r\n\r\n{{{\r\n+ rm -rf dist\r\n+ cabal configure --enable-tests\r\nResolving dependencies...\r\nConfiguring dependency-bug-0.0.1...\r\n+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs\r\n+ cabal build\r\nBuilding dependency-bug-0.0.1...\r\nPreprocessing library dependency-bug-0.0.1...\r\n[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )\r\n[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )\r\nRegistering dependency-bug-0.0.1...\r\nPreprocessing test suite 'Test' for dependency-bug-0.0.1...\r\n[1 of 1] Compiling Main ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )\r\nLinking dist/build/Test/Test ...\r\n+ cabal test\r\nRunning 1 test suites...\r\nTest suite Test: RUNNING...\r\nTest suite Test: PASS\r\nTest suite logged to: dist/test/dependency-bug-0.0.1-Test.log\r\n1 of 1 test suites (1 of 1 test cases) passed.\r\n+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs\r\n+ cabal build\r\nBuilding dependency-bug-0.0.1...\r\nPreprocessing library dependency-bug-0.0.1...\r\n[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )\r\n[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )\r\nRegistering dependency-bug-0.0.1...\r\nPreprocessing test suite 'Test' for dependency-bug-0.0.1...\r\n[1 of 1] Compiling Main ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )\r\nLinking dist/build/Test/Test ...\r\n+ cabal test\r\nRunning 1 test suites...\r\nTest suite Test: RUNNING...\r\nMain:\r\n library function: [Failed]\r\nexpected: \"Return A\"\r\n but got: \"Return B\"\r\n\r\n Test Cases Total\r\n Passed 0 0\r\n Failed 1 1\r\n Total 1 1\r\nTest suite Test: FAIL\r\nTest suite logged to: dist/test/dependency-bug-0.0.1-Test.log\r\n0 of 1 test suites (0 of 1 test cases) passed.\r\n\r\n}}}\r\n\r\nThis is as expected; we changed the source to \"Return B\" but the test expects the library to \"Return A\" so it fails. So far, so good. However:\r\n\r\n{{{\r\n+ rm -rf dist\r\n+ cabal configure --enable-tests -fwithout-inline\r\nResolving dependencies...\r\nConfiguring dependency-bug-0.0.1...\r\n+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs\r\n+ cabal build\r\nBuilding dependency-bug-0.0.1...\r\nPreprocessing library dependency-bug-0.0.1...\r\n[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )\r\n[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )\r\nRegistering dependency-bug-0.0.1...\r\nPreprocessing test suite 'Test' for dependency-bug-0.0.1...\r\n[1 of 1] Compiling Main ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package array-0.4.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.0 ... linking ... done.\r\nLoading package containers-0.4.2.1 ... linking ... done.\r\nLoading package pretty-1.1.1.0 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package dependency-bug-0.0.1 ... linking ... done.\r\nLoading package filepath-1.3.0.0 ... linking ... done.\r\nLoading package old-locale-1.0.0.4 ... linking ... done.\r\nLoading package old-time-1.1.0.0 ... linking ... done.\r\nLoading package bytestring-0.9.2.1 ... linking ... done.\r\nLoading package unix-2.5.1.1 ... linking ... done.\r\nLoading package directory-1.1.0.2 ... linking ... done.\r\nLoading package cpphs-1.14 ... linking ... done.\r\nLoading package haskell-src-exts-1.13.5 ... linking ... done.\r\nLoading package transformers-0.3.0.0 ... linking ... done.\r\nLoading package mtl-2.1.2 ... linking ... done.\r\nLoading package regex-base-0.93.2 ... linking ... done.\r\nLoading package regex-posix-0.95.2 ... linking ... done.\r\nLoading package language-haskell-extract-0.2.1 ... linking ... done.\r\nLoading package ansi-terminal-0.5.5 ... linking ... done.\r\nLoading package ansi-wl-pprint-0.6.4 ... linking ... done.\r\nLoading package extensible-exceptions-0.1.1.4 ... linking ... done.\r\nLoading package hostname-1.0 ... linking ... done.\r\nLoading package time-1.4 ... linking ... done.\r\nLoading package random-1.0.1.1 ... linking ... done.\r\nLoading package text-0.11.2.3 ... linking ... done.\r\nLoading package xml-1.3.12 ... linking ... done.\r\nLoading package test-framework-0.6.1 ... linking ... done.\r\nLoading package test-framework-th-0.2.2 ... linking ... done.\r\nLoading package HUnit-1.2.5.1 ... linking ... done.\r\nLoading package test-framework-hunit-0.2.7 ... linking ... done.\r\nLinking dist/build/Test/Test ...\r\n+ cabal test\r\nRunning 1 test suites...\r\nTest suite Test: RUNNING...\r\nTest suite Test: PASS\r\nTest suite logged to: dist/test/dependency-bug-0.0.1-Test.log\r\n1 of 1 test suites (1 of 1 test cases) passed.\r\n+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs\r\n+ cabal build\r\nBuilding dependency-bug-0.0.1...\r\nPreprocessing library dependency-bug-0.0.1...\r\n[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )\r\n[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )\r\nRegistering dependency-bug-0.0.1...\r\nPreprocessing test suite 'Test' for dependency-bug-0.0.1...\r\nLinking dist/build/Test/Test ...\r\n+ cabal test\r\nRunning 1 test suites...\r\nTest suite Test: RUNNING...\r\nTest suite Test: PASS\r\nTest suite logged to: dist/test/dependency-bug-0.0.1-Test.log\r\n1 of 1 test suites (1 of 1 test cases) passed.\r\n}}}\r\n\r\nAs you can see, without-inline the 2nd build did not recompile the test, even though it should have. It only re-linked the test, so it kept seeing \"Return A\" even though the library actually does \"Return B\".\r\n\r\nIn my real code, there are no NO/INLINE pragmas; however, the TH code is complex enough that it is not inlined, which causes the same problem. I had to use the pragma to keep the example short.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/19771TH recompilation check is defeated by packages2021-06-08T19:30:57ZMatthew PickeringTH recompilation check is defeated by packagesIt's possible to defeat the recompilation checker by using and then modifying a TH definition from another package.
Reproducer: https://github.com/mpickering/special-fiesta
In the example there are two packages. Package `p` defines a l...It's possible to defeat the recompilation checker by using and then modifying a TH definition from another package.
Reproducer: https://github.com/mpickering/special-fiesta
In the example there are two packages. Package `p` defines a library
```
module Lib where
{-# NOINLINE p #-}
p = [| 0 |]
```
which is then used in package `q`:
```
module Main where
import Lib
main = print $(p)
```
Running the executable prints `0` initially.
Then modifying the library `p`,
```
module Lib where
p = [| 1 |]
```
when the executable is rerun the result should be printing `1`, but it still prints `0`.
The recompilation check fails because the ABI for `Lib` didn't change, and so GHC concluded that it didn't need to recompile `Main` again.
The logic for computing stable modules only considers stability for home package modules when it should also consider whether the object files for dependencies have changed.
A correct fix is to take the hash of all the object files in the transitive dependencies of a module (such as is already done for plugins)Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/19935getExecutablePath returns ld loader path2021-06-04T09:44:29ZDaneel S. YaitskovgetExecutablePath returns ld loader pathif Haskell program is launched through ld linkder then
System.Environment.getExecutablePath returns path to the linker not to the program, meanwhile getArgs works correctly and first argument is not a path to the Haskell program, the la...if Haskell program is launched through ld linkder then
System.Environment.getExecutablePath returns path to the linker not to the program, meanwhile getArgs works correctly and first argument is not a path to the Haskell program, the last fact makes hard to implement workaround.
```
module Main where
import System.Environment
main :: IO ()
main = do
p <- getExecutablePath
print p
x <- getArgs
print x
```
```
ghc --make -o print-args Main.hs
```
```
readelf -a print-args | grep Requesting
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
/lib64/ld-linux-x86-64.so.2 $PWD/print-args a b c
"/usr/lib/x86_64-linux-gnu/ld-2.28.so"
["a","b","c"]
```
```
ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.4
uname -a
Linux diehard 5.9.13 #1 SMP Wed Dec 9 14:12:51 MSK 2020 x86_64 GNU/Linux
```
workaround:
```
getFullProgName :: IO String
getFullProgName =
alloca $ \ p_argc ->
alloca $ \ p_argv -> do
getFullProgArgv p_argc p_argv
peek p_argv >>= peek >>= peekCString
foreign import ccall unsafe "getFullProgArgv"
getFullProgArgv :: Ptr CInt -> Ptr (Ptr CString) -> IO ()
main = getFullProgName >>= putStrLn
```https://gitlab.haskell.org/ghc/ghc/-/issues/19680case over signum of Integer is incorrect in GHC 9.22021-05-13T01:55:47ZBodigrimcase over signum of Integer is incorrect in GHC 9.2## Summary
`case` over `signum` of `Integer` returns an incorrect result.
## Steps to reproduce
```
GHCi, version 9.2.0.20210331: https://www.haskell.org/ghc/ :? for help
ghci> signum (-1 :: Integer)
-1
ghci> case signum (-1 :: Integ...## Summary
`case` over `signum` of `Integer` returns an incorrect result.
## Steps to reproduce
```
GHCi, version 9.2.0.20210331: https://www.haskell.org/ghc/ :? for help
ghci> signum (-1 :: Integer)
-1
ghci> case signum (-1 :: Integer) of 1 -> "FOO"; -1 -> "OK"; 0 -> "BAR"; _ -> "FAIL"
"FAIL"
```
## Expected behavior
I would expect the second line to return `"OK"`.
## Environment
* GHC version used: 9.2.0.202103319.2.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/17950OFD locking breaks on 32-bit glibc2021-05-04T23:17:40ZBen GamariOFD locking breaks on 32-bit glibcAs noted in #17941, some [glibc versions](https://sourceware.org/bugzilla/show_bug.cgi?id=20251) use the wrong `struct` layout for the open fd locking `fcntl` on 32-bit platforms. This results in GHC being broken on many 32-bit platforms...As noted in #17941, some [glibc versions](https://sourceware.org/bugzilla/show_bug.cgi?id=20251) use the wrong `struct` layout for the open fd locking `fcntl` on 32-bit platforms. This results in GHC being broken on many 32-bit platforms by default.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/19147Error in accounting for GC cpu time in sequential collections2021-05-04T23:17:39ZDouglas Wilsondouglas@well-typed.comError in accounting for GC cpu time in sequential collections## Summary
stat_endGC accounts for cpu time consumed by a garbage collection the following fragment:
```
for (unsigned int i=0; i < par_n_threads; i++) {
gc_thread *gct = gc_threads[i];
ASSERT(gct->gc_end...## Summary
stat_endGC accounts for cpu time consumed by a garbage collection the following fragment:
```
for (unsigned int i=0; i < par_n_threads; i++) {
gc_thread *gct = gc_threads[i];
ASSERT(gct->gc_end_cpu >= gct->gc_start_cpu);
stats.gc.cpu_ns += gct->gc_end_cpu - gct->gc_start_cpu;
}
```
however, this is incorrect when accounting for a sequential collection when n_capabilities > 1. In this case, par_n_threads will be set to 1. However the cpu stats will not necessarily be on capability 0(i.e. in gc_threads[0]) which the fragment above assumes. The stats will be on the capability of the gc leader.
EDIT:
I've also seen
```
for (i=0; i < n_gc_threads; i++) {
copied += RELAXED_LOAD(&gc_threads[i]->copied);
}
```
in GC.c seems to have the same problem. Holding off fixing this for now, since I now suspect I may be confused
## Steps to reproduce
I've not constructed a demonstration.
## Expected behavior
n/a
## Environment
* GHC version used: headhttps://gitlab.haskell.org/ghc/ghc/-/issues/11126Entered absent arg in a Repa program2021-04-29T21:20:00ZtuplanollaEntered absent arg in a Repa programConsider the following program.
```hs
module Main where
import Data.Array.Repa
data Stuff = !(Array U DIM1 Double) `With` !Double deriving Show
through :: Maybe Double -> Stuff -> Stuff
m `through` (a `With` _) =
let b = a +^ (nega...Consider the following program.
```hs
module Main where
import Data.Array.Repa
data Stuff = !(Array U DIM1 Double) `With` !Double deriving Show
through :: Maybe Double -> Stuff -> Stuff
m `through` (a `With` _) =
let b = a +^ (negate `smap` sumS (extend (Z :. All :. (1 :: Int)) a))
c = maybe b (const (negate `smap` a)) m in
computeUnboxedS c `With` sumAllS b
main :: IO ()
main = print $ Just 1 `through` (fromListUnboxed (Z :. 1) [1] `With` 1)
```
It should produce the following result once run.
```hs
AUnboxed (Z :. 1) (fromList [-1.0]) `With` 0.0
```
However, when built using `repa-3.4.0.1` and compiled with the options
`-O3 -Wall -funfolding-keeness-factor1000 -funfolding-use-threshold1000`,
it crashes as follows.
```hs
Main: Oops! Entered absent arg arr2 Array D DIM1 Double
```
Adding `-fno-strictness` to the compiler options or
removing strictness annotations from the code makes the problem disappear, so
this looks like a strictness analyzer problem.
The libraries used were
- `QuickCheck-2.8.1`,
- `array-0.5.1.0`,
- `base-4.8.1.0`,
- `bytestring-0.10.6.0`,
- `containers-0.5.6.2`,
- `deepseq-1.4.1.1`,
- `ghc-prim-0.4.0.0`,
- `integer-gmp-1.0.0.0`,
- `pretty-1.1.2.0`,
- `primitive-0.6`,
- `random-1.1`,
- `repa-3.4.0.1`,
- `template-haskell-2.10.0.0`,
- `tf-random-0.5`,
- `time-1.5.0.1`,
- `transformers-0.4.2.0` and
- `vector-0.10.12.3`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Entered absent arg in a Repa program","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following program.\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport Data.Array.Repa\r\n\r\ndata Stuff = !(Array U DIM1 Double) `With` !Double deriving Show\r\n\r\nthrough :: Maybe Double -> Stuff -> Stuff\r\nm `through` (a `With` _) =\r\n let b = a +^ (negate `smap` sumS (extend (Z :. All :. (1 :: Int)) a))\r\n c = maybe b (const (negate `smap` a)) m in\r\n computeUnboxedS c `With` sumAllS b\r\n\r\nmain :: IO ()\r\nmain = print $ Just 1 `through` (fromListUnboxed (Z :. 1) [1] `With` 1)\r\n}}}\r\n\r\nIt should produce the following result once run.\r\n\r\n{{{#!hs\r\nAUnboxed (Z :. 1) (fromList [-1.0]) `With` 0.0\r\n}}}\r\n\r\nHowever, when built using `repa-3.4.0.1` and compiled with the options\r\n`-O3 -Wall -funfolding-keeness-factor1000 -funfolding-use-threshold1000`,\r\nit crashes as follows.\r\n\r\n{{{#!hs\r\nMain: Oops! Entered absent arg arr2 Array D DIM1 Double\r\n}}}\r\n\r\nAdding `-fno-strictness` to the compiler options or\r\nremoving strictness annotations from the code makes the problem disappear, so\r\nthis looks like a strictness analyzer problem.\r\n\r\nThe libraries used were\r\n\r\n* `QuickCheck-2.8.1`,\r\n* `array-0.5.1.0`,\r\n* `base-4.8.1.0`,\r\n* `bytestring-0.10.6.0`,\r\n* `containers-0.5.6.2`,\r\n* `deepseq-1.4.1.1`,\r\n* `ghc-prim-0.4.0.0`,\r\n* `integer-gmp-1.0.0.0`,\r\n* `pretty-1.1.2.0`,\r\n* `primitive-0.6`,\r\n* `random-1.1`,\r\n* `repa-3.4.0.1`,\r\n* `template-haskell-2.10.0.0`,\r\n* `tf-random-0.5`,\r\n* `time-1.5.0.1`,\r\n* `transformers-0.4.2.0` and\r\n* `vector-0.10.12.3`.","type_of_failure":"OtherFailure","blocking":[]} -->9.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/12656ghc floats out constant despite -fno-cse2021-04-24T22:31:54ZNiklas Hambüchenmail@nh2.meghc floats out constant despite -fno-cseConsider this program using `Data.Vector.unsafeThaw` and `-fno-cse`:
```
{-# OPTIONS_GHC -fno-cse #-}
import qualified Data.Vector as V
import qualified Data.Vector.Mutable as VM
main :: IO ()
main = do
foo 100000
foo 100000
le...Consider this program using `Data.Vector.unsafeThaw` and `-fno-cse`:
```
{-# OPTIONS_GHC -fno-cse #-}
import qualified Data.Vector as V
import qualified Data.Vector.Mutable as VM
main :: IO ()
main = do
foo 100000
foo 100000
let f = foo 100000 in f >> f
foo :: Int -> IO ()
foo n = do
indexVector <- V.unsafeThaw $ V.generate n id
x <- VM.read indexVector 5
VM.write indexVector 5 (x * x)
print x
-- In GHCI, we get:
--
-- > :set -fno-cse
--
-- > foo 100000
-- 5
-- > foo 100000
-- 5
--
-- > let f = foo 100000 in f >> f
-- 5
-- 25
```
I would expect that
```
> let f = foo 100000 in f >> f
5
5
```
Shouldn't `-fno-cse` fix this?
(Note: This also happens with `ghc` instead of `ghci`.)https://gitlab.haskell.org/ghc/ghc/-/issues/19724Non-reproducible failure in RestartEventLogging test in `threaded1` way.2021-04-22T01:01:31ZvdukhovniNon-reproducible failure in RestartEventLogging test in `threaded1` way.## Summary
Running `validate` by hand the test typically succeeds, but on one run I got:
```
...
--- tests/rts/RestartEventLogging.run/RestartEventLogging.stdout.normalised 2021-04-20 21:29:06.924934000 -0400
+++ tests/rts/RestartEventL...## Summary
Running `validate` by hand the test typically succeeds, but on one run I got:
```
...
--- tests/rts/RestartEventLogging.run/RestartEventLogging.stdout.normalised 2021-04-20 21:29:06.924934000 -0400
+++ tests/rts/RestartEventLogging.run/RestartEventLogging.run.stdout.normalised 2021-04-20 21:29:06.925062000 -0400
@@ -8,6 +8,11 @@
stop
init
Event log started with EVENT_HEADER_BEGIN
+ERROR: event does not start with EVENT_HEADER_BEGIN
+0x0 != 0x68
+0x12 != 0x64
+0x0 != 0x72
+0x0 != 0x62
stop
init
Event log started with EVENT_HEADER_BEGIN
...
tests/rts/RestartEventLogging.run RestartEventLogging [bad stdout] (threaded1)
```
The expected value is:
```
includes/rts/EventLogFormat.h:#define EVENT_HEADER_BEGIN 0x68647262 /* 'h' 'd' 'r' 'b' */
```
but we got '\0\x12\0\0'.
## Steps to reproduce
Not easily reproducible, could even be a hardware glitch, though that seems unlikely...
## Expected behavior
The test should ideally pass consistently
## Environment
* GHC version used: commit 4cfb6b89479d873f1091dce59f7fbed635d37d6a (HEAD -> freebsd-tlsgd, v/freebsd-tlsgd) of MR !5561. The merge-base with head is: commit 0619fb0fb14a98f04aac5f031f6566419fd27495 (origin/master, origin/HEAD, master)
Optional:
* Operating System: FreeBSD 12.2
* System Architecture: X86_64https://gitlab.haskell.org/ghc/ghc/-/issues/14768-O1 changes result at runtime, duplicating __DEFAULT case2021-04-06T12:46:41ZBodigrim-O1 changes result at runtime, duplicating __DEFAULT caseHere is a program, which works as expected in GHC 8.4.1-alpha3 with `-O0`, but changes it behaviour with `-O1`.
```hs
{-# LANGUAGE MagicHash #-}
import qualified Data.Vector.Unboxed as U
import GHC.Exts
vec :: U.Vector Moebius
vec = U...Here is a program, which works as expected in GHC 8.4.1-alpha3 with `-O0`, but changes it behaviour with `-O1`.
```hs
{-# LANGUAGE MagicHash #-}
import qualified Data.Vector.Unboxed as U
import GHC.Exts
vec :: U.Vector Moebius
vec = U.singleton Moebius0
main :: IO ()
main = print $ U.head vec == U.head vec
data Moebius = Moebius0 | Moebius1 | Moebius2
deriving (Eq)
fromMoebius :: Moebius -> Int
fromMoebius Moebius0 = 0
fromMoebius Moebius1 = 1
fromMoebius Moebius2 = 2
toMoebius :: Int -> Moebius
toMoebius (I# i#) = tagToEnum# i#
{- ...unboxed vector instances, see file attached... -}
```
It is expected that this program will print `True`. However, when compiled with `-O1` it prints `False`.
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180204
$ ghc -O0 Sieve.hs && ./Sieve
[1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed]
Linking Sieve ...
True
$ ghc -O1 Sieve.hs && ./Sieve
[1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed]
Linking Sieve ...
False
```
It reproduces on OS X and Ubuntu, but worked fine in GHC 8.2.
I looked into generated Core and found a suspicious function, having two `__DEFAULT` cases with different bodies.
```hs
main2 :: String
main2
= case vec `cast` <Co:3> of
{ Vector ipv_sb7L ipv1_sb7M ipv2_sb7N ->
case <# 0# ipv1_sb7M of {
__DEFAULT -> case main3 ipv1_sb7M of wild_00 { };
1# ->
case indexIntArray# ipv2_sb7N ipv_sb7L of {
__DEFAULT -> $fShowBool4;
__DEFAULT -> $fShowBool2;
1# -> $fShowBool2;
2# -> $fShowBool2
}
}
}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1-alpha3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-O1 changes result at runtime, duplicating __DEFAULT case","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1-alpha3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is a program, which works as expected in GHC 8.4.1-alpha3 with `-O0`, but changes it behaviour with `-O1`.\r\n\r\n{{{#!hs\r\n{-# LANGUAGE MagicHash #-}\r\n\r\nimport qualified Data.Vector.Unboxed as U\r\nimport GHC.Exts\r\n\r\nvec :: U.Vector Moebius\r\nvec = U.singleton Moebius0\r\n\r\nmain :: IO ()\r\nmain = print $ U.head vec == U.head vec\r\n\r\ndata Moebius = Moebius0 | Moebius1 | Moebius2\r\n deriving (Eq)\r\n\r\nfromMoebius :: Moebius -> Int\r\nfromMoebius Moebius0 = 0\r\nfromMoebius Moebius1 = 1\r\nfromMoebius Moebius2 = 2\r\n\r\ntoMoebius :: Int -> Moebius\r\ntoMoebius (I# i#) = tagToEnum# i#\r\n\r\n{- ...unboxed vector instances, see file attached... -}\r\n}}}\r\n\r\nIt is expected that this program will print `True`. However, when compiled with `-O1` it prints `False`.\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.4.0.20180204\r\n$ ghc -O0 Sieve.hs && ./Sieve\r\n[1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed]\r\nLinking Sieve ...\r\nTrue\r\n$ ghc -O1 Sieve.hs && ./Sieve\r\n[1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed]\r\nLinking Sieve ...\r\nFalse\r\n}}}\r\n\r\nIt reproduces on OS X and Ubuntu, but worked fine in GHC 8.2.\r\n\r\nI looked into generated Core and found a suspicious function, having two `__DEFAULT` cases with different bodies. \r\n\r\n{{{#!hs\r\nmain2 :: String\r\nmain2\r\n = case vec `cast` <Co:3> of\r\n { Vector ipv_sb7L ipv1_sb7M ipv2_sb7N ->\r\n case <# 0# ipv1_sb7M of {\r\n __DEFAULT -> case main3 ipv1_sb7M of wild_00 { };\r\n 1# ->\r\n case indexIntArray# ipv2_sb7N ipv_sb7L of {\r\n __DEFAULT -> $fShowBool4;\r\n __DEFAULT -> $fShowBool2;\r\n 1# -> $fShowBool2;\r\n 2# -> $fShowBool2\r\n }\r\n }\r\n }\r\n}}} ","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/19563PowerPC: IntegerToFloat test failure2021-03-23T12:40:34ZPeter Trommlerptrommler@acm.orgPowerPC: IntegerToFloat test failureHere is the result from IntegerTo Float on powerpc64 Linux:
```
0x1p36
0x1.fffffcp59
0x1p60
-0x1.fffffep59
+0x1p60
0x1p60
0x1.fffffcp63
0x1p64
```Here is the result from IntegerTo Float on powerpc64 Linux:
```
0x1p36
0x1.fffffcp59
0x1p60
-0x1.fffffep59
+0x1p60
0x1p60
0x1.fffffcp63
0x1p64
```Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/19345Optimisations cause incorrect runtime result in Integer calculation2021-03-10T21:27:06Zsheafsam.derbyshire@gmail.comOptimisations cause incorrect runtime result in Integer calculation## Summary
The following program
```haskell
module Main where
import Numeric.Natural
( Natural )
a, q :: Natural
a = fromIntegral ( 18446744073709551616 :: Integer )
q = 18446744073709551616
main :: IO ()
main = print ( fromIntegr...## Summary
The following program
```haskell
module Main where
import Numeric.Natural
( Natural )
a, q :: Natural
a = fromIntegral ( 18446744073709551616 :: Integer )
q = 18446744073709551616
main :: IO ()
main = print ( fromIntegral ( a `div` q ) :: Word )
```
runs into the following strange behaviour:
GHC 8.10 -O0
```
> main
1
```
GHC 8.10 -O1
```
> main
1
```
GHC 9.0 -O0
```
> main
1
```
GHC 9.0 -O1
```
> main
0
```
Tagging @hsyl20 as I expect him to know about what's going on.
## Steps to reproduce
Simply run the above program with either `ghc -O0` or `ghc -O1` to get the different results.
## Further remarks
Changing `fromIntegral` to `fromInteger` causes GHC 9.0 with optimisations to return the correct result, so it might be an incorrect rewrite rule involving `fromIntegral`?
## Environment
On GHC 9.0.1, Windows 10 x64.9.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/19078Restarting event log results in invalid output2021-03-05T21:33:31ZBen GamariRestarting event log results in invalid outputCurrently if one calls `endEventLogging()`, followed by `beginEventLogging()`, the eventlog that results has block markers before the header, rendering the output unreadable to `ghc-events`. The problem is that `endEventLogging()` calls ...Currently if one calls `endEventLogging()`, followed by `beginEventLogging()`, the eventlog that results has block markers before the header, rendering the output unreadable to `ghc-events`. The problem is that `endEventLogging()` calls `printAndClearEventsBuf(&eventBuf)`, which posts a marker after flushing the buffer. `postHeaderEvents()` then fails to clear this marker before posting the header.
The solution seems clear: call `resetEventsBuf()` in either `endEventLogging()` or `postHeaderEvents()`.https://gitlab.haskell.org/ghc/ghc/-/issues/10576REPL returns list of all imported names when operator completion requested2021-03-01T16:53:34ZGeraldusREPL returns list of all imported names when operator completion requestedWhen querying completions for operators GHCi returns a list containing all imported names rather than suitable completions.
For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base...When querying completions for operators GHCi returns a list containing all imported names rather than suitable completions.
For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base and Prelude. Then if you import something else, for example `:m +Data.Text`, the result of query will contain names from Data.Text also.
In case of projects (`cabal repl`) things are worst, because returned list contains all names imported project-wise and it could be really huge.
GHCi behaves similarly with following queries:
```
:complete repl "(>>"
:complete repl "Prelude.>>"
:complete repl "Prelude.(>>"
```
I only tested this on OS X 10.9, GHC 7.8.49.2.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/19436Eventlog flushing in non-threaded is broken2021-03-01T16:19:18ZMatthew PickeringEventlog flushing in non-threaded is broken`flushEventLog` in non-threaded way doesn't flush the `capEventBuf[0]` event buffer.`flushEventLog` in non-threaded way doesn't flush the `capEventBuf[0]` event buffer.Matthew PickeringMatthew Pickering