GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-04-12T21:07:34Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15462fixST for lazy ST is a bit wrong2022-04-12T21:07:34ZDavid FeuerfixST for lazy ST is a bit wrong#15349 exposed a problem with repeated computations in invocations of `fixST` that should fail but can instead produce answers or even subvert safe Haskell. That has been fixed for strict `ST`, but not yet for lazy `ST`.
<details><summa...#15349 exposed a problem with repeated computations in invocations of `fixST` that should fail but can instead produce answers or even subvert safe Haskell. That has been fixed for strict `ST`, but not yet for lazy `ST`.
<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":"fixST for lazy ST is a bit wrong","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"#15349 exposed a problem with repeated computations in invocations of `fixST` that should fail but can instead produce answers or even subvert safe Haskell. That has been fixed for strict `ST`, but not yet for lazy `ST`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10975At program exit, finalizer runs while foreign function is running2022-04-25T18:50:30Ztakano-akioAt program exit, finalizer runs while foreign function is runningThe following code prints "finalized", which means the finalizer runs while the "call" function is still running.
Steps to reproduce:
```
% ghc finalizer.hs foreign.c -threaded
% ./finalizer
```
finalizer.hs:
```hs
import Control.Con...The following code prints "finalized", which means the finalizer runs while the "call" function is still running.
Steps to reproduce:
```
% ghc finalizer.hs foreign.c -threaded
% ./finalizer
```
finalizer.hs:
```hs
import Control.Concurrent
import Control.Monad
import Foreign.C.Types
import Foreign.ForeignPtr
import Foreign.Ptr
main :: IO ()
main = do
_ <- forkIO $ do
fptr <- newForeignPtr finalizer nullPtr
forever $ withForeignPtr fptr call
threadDelay 1000000
foreign import ccall "&finalizer" finalizer :: FunPtr (Ptr CInt -> IO ())
foreign import ccall "call" call :: Ptr CInt -> IO ()
```
foreign.c
```c
#include <stdio.h>
int finalized = 0;
void finalizer(int *a)
{
finalized = 1;
puts("finalizer");
}
void call(int *a)
{
int i;
unsigned w = 0;
puts("begin call");
for(i = 0; i < 100000000; i++)
{
if(finalized)
puts("finalized");
w += i;
}
printf("end call: %u\n", w);
}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| 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":"At program exit, finalizer runs while foreign function is running","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code prints \"finalized\", which means the finalizer runs while the \"call\" function is still running.\r\n\r\nSteps to reproduce:\r\n{{{\r\n% ghc finalizer.hs foreign.c -threaded\r\n% ./finalizer\r\n}}}\r\n\r\nfinalizer.hs:\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport Foreign.C.Types\r\nimport Foreign.ForeignPtr\r\nimport Foreign.Ptr\r\n\r\nmain :: IO ()\r\nmain = do\r\n _ <- forkIO $ do\r\n fptr <- newForeignPtr finalizer nullPtr\r\n forever $ withForeignPtr fptr call\r\n threadDelay 1000000\r\n\r\nforeign import ccall \"&finalizer\" finalizer :: FunPtr (Ptr CInt -> IO ())\r\nforeign import ccall \"call\" call :: Ptr CInt -> IO ()\r\n}}}\r\n\r\nforeign.c\r\n{{{#!c\r\n#include <stdio.h>\r\n\r\nint finalized = 0;\r\n\r\nvoid finalizer(int *a)\r\n{\r\n finalized = 1;\r\n puts(\"finalizer\");\r\n}\r\n\r\nvoid call(int *a)\r\n{\r\n int i;\r\n unsigned w = 0;\r\n puts(\"begin call\");\r\n for(i = 0; i < 100000000; i++)\r\n {\r\n if(finalized)\r\n puts(\"finalized\");\r\n w += i;\r\n }\r\n printf(\"end call: %u\\n\", w);\r\n}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20529Instances become invisible across a component boundary2022-04-30T21:28:22ZparsonsmattInstances become invisible across a component boundary## Summary
Reproduction repository: https://github.com/parsonsmatt/visibility
It seems like instances which are considered `visible` in the library component are no longer considered visible when reifying them in the `test` component.
...## Summary
Reproduction repository: https://github.com/parsonsmatt/visibility
It seems like instances which are considered `visible` in the library component are no longer considered visible when reifying them in the `test` component.
The example repo essentially defines:
```haskell
module C where
class C a
module A where
import C
data A = A
instance C A
module B where
import C
import A
data B = B A
instance C B
module T where
import C
import B ()
data T = T
instance C T
```
Based on what I've read on visible type class instances, I would expect that `import T()` would bring into visibility the instances for `B` and `A` as well. This is confirmed - in the library, I can write:
```haskell
module Lib where
import C
import T ()
import Language.Haskell.TH
do
instances <- reifyInstances ''C [VarP (mkName "a")]
print instances
```
and it prints out instance declarations matching `A`, `B`, and `T`.
However, if I run the same code in the *test suite* for this package, then it only shows the instance `C T` - it only shows an instance if it was defined *in the module* that is being imported, not all the transitively imported instances.
## Steps to reproduce
Reproduction repository: https://github.com/parsonsmatt/visibility
`stack build` or `cabal build` should both work. I've tested with GHC 8.10.3, 8.10.7, and 9.0.1.
## Expected behavior
I would expect the instances to be visible just the same in a test-suite or library component.
## Environment
* GHC version used: 8.10.3, 8.10.7, 9.0.1
Optional:
* Operating System: UBuntu
* System Architecture: x86parsonsmattparsonsmatthttps://gitlab.haskell.org/ghc/ghc/-/issues/21429Cost centres seem to cause invalid demand analysis results.2022-05-03T09:29:28ZAndreas KlebingerCost centres seem to cause invalid demand analysis results.With the lateCC pass we now add cost centres in some places where we didn't before and this seems to cause issues with demand analysis/core lint.
We simplify this function (taken from after float out)
```
-- RHS size: {terms: 5, types:...With the lateCC pass we now add cost centres in some places where we didn't before and this seems to cause issues with demand analysis/core lint.
We simplify this function (taken from after float out)
```
-- RHS size: {terms: 5, types: 4, coercions: 8, joins: 0/0}
fail_s9my :: (# #) -> IO ExitCode
[LclId, Arity=2, Str=<L><L>b, Cpr=b]
fail_s9my
= (\ _ [Occ=Dead, OS=OneShot]
(eta_B0 :: ghc-prim:GHC.Prim.State# ghc-prim:GHC.Prim.RealWorld) ->
((GHC.Base.failIO @ExitCode lvl_s9mw)
`cast` (ghc-prim:GHC.Types.N:IO[0] <ExitCode>_R
:: IO ExitCode
~R# (ghc-prim:GHC.Prim.State# ghc-prim:GHC.Prim.RealWorld
-> (# ghc-prim:GHC.Prim.State# ghc-prim:GHC.Prim.RealWorld,
ExitCode #))))
eta_B0)
`cast` (Sym (<(# #)>_R
%<'Many>_N ->_R ghc-prim:GHC.Types.N:IO[0] <ExitCode>_R)
:: ((# #)
-> ghc-prim:GHC.Prim.State# ghc-prim:GHC.Prim.RealWorld
-> (# ghc-prim:GHC.Prim.State# ghc-prim:GHC.Prim.RealWorld,
ExitCode #))
~R# ((# #) -> IO ExitCode))
-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0}
lvl_s9mz :: IO ExitCode
[LclId, Str=b, Cpr=b]
lvl_s9mz = scc<bindIO> scc<bindIO> fail_s9my ghc-prim:GHC.Prim.(##)
```
into this one (after one iteration of the simplifier)
```
lvl_s9Jy :: State# RealWorld -> (# State# RealWorld, ExitCode #)
[LclId,
Arity=1,
Str=b,
Cpr=b,
Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True,
WorkFree=True, Expandable=True,
Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}]
lvl_s9Jy
= \ (eta_B0 :: State# RealWorld) ->
scc<bindIO>
scc<bindIO>
((failIO @ExitCode (scc<bindIO> scc<bindIO> build @Char lvl_s9mv))
`cast` (N:IO[0] <ExitCode>_R
:: IO ExitCode
~R# (State# RealWorld -> (# State# RealWorld, ExitCode #))))
eta_B0
```
But the later one results in this core lint error:
```
*** Core Linted result of Simplifier:
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
idArity 1 exceeds arity imposed by the strictness signature b: lvl_s9Jw
In the RHS of lvl_s9Jw :: State# RealWorld
-> (# State# RealWorld, ExitCode #)
Substitution: [TCvSubst
In scope: InScope {}
Type env: []
Co env: []]
*** Offending Program ***
```
The core issue seems to be that we infer `Str=b` for
```
-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0}
lvl_s9mz :: IO ExitCode
[LclId, Str=b, Cpr=b]
lvl_s9mz = scc<bindIO> scc<bindIO> fail_s9my ghc-prim:GHC.Prim.(##)
```
If we expand IO/unwrap the IO newtype this function is of type:
`State# RealWorld -> (# State# RealWorld, ExitCode #)` so I don't think this should get a Str of `b` as we have to provide the RealWorld argument for it to bottom out.
I assume the cost centre annotations on the RHS somehow interfere with demand analysis in this case.
@sgraf812 Maybe you have an idea?Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/21082rts stats show negative productivity2022-05-09T08:14:56ZDouglas Wilsondouglas@well-typed.comrts stats show negative productivityThe following program and options show the issue. I have reproduced this on head.
```
{-
ghc -O2 -package async Main.hs -rtsopts -threaded
./Main +RTS -N8 -s -qn1
Productivity -195.4% of total user, 25.3% of total elapsed
-}
import ...The following program and options show the issue. I have reproduced this on head.
```
{-
ghc -O2 -package async Main.hs -rtsopts -threaded
./Main +RTS -N8 -s -qn1
Productivity -195.4% of total user, 25.3% of total elapsed
-}
import Control.Concurrent.Async
import Control.Monad (replicateM, forM)
import Data.List (transpose)
main = do
as <- replicateM 10 $ async $ do
let w = 5000
m = replicate w $ replicate w ()
return $! m == transpose m
print =<< forM as wait
```9.4.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/21465128-bit Callee-saved registers (Windows x64) are not saved and restored corre...2022-05-30T17:12:27ZThomas Dinsdale-Young128-bit Callee-saved registers (Windows x64) are not saved and restored correctly## Summary
The Windows x64 calling convention requires that the 128-bit registers XMM6-XMM15 be [saved (and restored) by the callee](https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#callercallee-saved-regi...## Summary
The Windows x64 calling convention requires that the 128-bit registers XMM6-XMM15 be [saved (and restored) by the callee](https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#callercallee-saved-registers).
`StgRunIsImplementedInAssembler`, which handles this in the runtime, does not correctly save and restore these registers, as it uses `movq` to do so, treating them as 64-bits only.
Consequently, when the registers are restored, the high-order 64-bits are zeroed.
Instead, `movaps` should probably be used, and 16 bytes reserved for each XMM register.
The consequence of this is that FFI calls to Haskell code on Windows may violate the calling convention and lead to undefined behaviour.
## Steps to reproduce
The attached files can be compiled on Windows with `ghc Main.hs reg.c`.
[Main.hs](/uploads/625555a8de865f7114397d3d81823ef6/Main.hs)
[reg.c](/uploads/1646814458605a7f87cde873b7dbd13a/reg.c)
The Haskell main function invokes a C function `test_c`, which uses inline assembly to set a value to the XMM6 register, invoke a Haskell function `helper`, and then read out the resulting value of the XMM6 register, comparing each byte to the expected (original) value.
The output of executing `Main.exe` is:
```
This is the helper function
0: 01 01
1: 02 02
2: 03 03
3: 04 04
4: 05 05
5: 06 06
6: 07 07
7: 08 08
8: 09 00
9: 0a 00
10: 0b 00
11: 0c 00
12: 0d 00
13: 0e 00
14: 0f 00
15: 10 00
Done.
```
This indicates that the lower-order 8 bytes of the register are correctly restored after the call to `helper`, but the high-order 8 bytes are not.
This is consistent with the use of `movq` instead of `movaps` (or `movups`).
## Expected behavior
The expected output is:
```
This is the helper function
0: 01 01
1: 02 02
2: 03 03
3: 04 04
4: 05 05
5: 06 06
6: 07 07
7: 08 08
8: 09 09
9: 0a 0a
10: 0b 0b
11: 0c 0c
12: 0d 0d
13: 0e 0e
14: 0f 0f
15: 10 10
Done.
```
## Environment
* GHC version used: 9.0.2, 8.10.2
Optional:
* Operating System: Windows 8.1
* System Architecture: x86-64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15338ghc-pkg misbehaves after possible miscompilation on m68k and sh42022-07-04T20:58:26Zglaubitzghc-pkg misbehaves after possible miscompilation on m68k and sh4We have observed in Debian that GHC can produce a erratically behaving version of ghc-pkg which causes issues when piping it's output to another program.
Example:
```
make_setup_recipe
Running ghc --make Setup.hs -o debian/hlibrary.set...We have observed in Debian that GHC can produce a erratically behaving version of ghc-pkg which causes issues when piping it's output to another program.
Example:
```
make_setup_recipe
Running ghc --make Setup.hs -o debian/hlibrary.setup
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking debian/hlibrary.setup ...
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
configure_recipe
Running debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/base-prelude-/ --datasubdir=base-prelude --htmldir=/usr/share/doc/libghc-base-prelude-doc/html/ --enable-library-profiling
Configuring base-prelude-1.2.1...
Warning: cannot determine version of /usr/bin/ghc-pkg :
""
hlibrary.setup: The program 'ghc-pkg' is required but the version of
/usr/bin/ghc-pkg could not be determined.
```
(Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-base-prelude&arch=m68k&ver=1.2.1-1&stamp=1530588494&raw=0)
Examining the behavior of the affected ghc-pkg binary on m68k shows what's going on:
```
root@pacman:~# uname -a
Linux pacman 4.16.0-2-m68k #1 Debian 4.16.16-1 (2018-06-19) m68k GNU/Linux
root@pacman:~# ghc-pkg --version
GHC package manager version 8.2.2
root@pacman:~# ghc-pkg --version | cat
root@pacman:~#
```
Comparing that to an x86_64 machine shows that piping to cat should actually output something:
```
glaubitz@epyc:~$ uname -a
Linux epyc 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 GNU/Linux
glaubitz@epyc:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.2
glaubitz@epyc:~$ ghc --version | cat
The Glorious Glasgow Haskell Compilation System, version 8.2.2
glaubitz@epyc:~$
```
Further investigation shows that the problem is partially resolved when building GHC with reduced optimization:
```
echo "SRC_HC_OPTS += -O0 -H64m" >> mk/build.mk
echo "GhcStage1HcOpts = -O" >> mk/build.mk
echo "GhcStage2HcOpts = -O0" >> mk/build.mk
echo "GhcLibHcOpts = -O" >> mk/build.mk
```
The above issue goes away, but ghc-pkg itself still shows some strange behavior:
```
make_setup_recipe
Running ghc --make Setup.hs -o debian/hlibrary.setup
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking debian/hlibrary.setup ...
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
configure_recipe
Running debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/microlens-ghc-0.4.8.0/ --datasubdir=microlens-ghc --htmldir=/usr/share/doc/libghc-microlens-ghc-doc/html/ --enable-library-profiling
Configuring microlens-ghc-0.4.8.0...
hlibrary.setup: ghc-pkg dump failed: dieVerbatim: user error (hlibrary.setup:
'/usr/bin/ghc-pkg' exited with an error:
ghc-pkg: <stdout>: commitBuffer: invalid argument (invalid character)
)
```
(Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-microlens-ghc&arch=m68k&ver=0.4.8.0-2&stamp=1529960552&raw=0)
To reproduce the issue, GHC can be tested using QEMU which has pretty good support for the m68k target these days.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.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":"ghc-pkg misbehaves after possible miscompilation on m68k and sh4","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We have observed in Debian that GHC can produce a erratically behaving version of ghc-pkg which causes issues when piping it's output to another program.\r\n\r\nExample:\r\n\r\n{{{\r\nmake_setup_recipe\r\nRunning ghc --make Setup.hs -o debian/hlibrary.setup\r\n[1 of 1] Compiling Main ( Setup.hs, Setup.o )\r\nLinking debian/hlibrary.setup ...\r\n. /usr/share/haskell-devscripts/Dh_Haskell.sh && \\\r\nconfigure_recipe\r\nRunning debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\\,-z\\,relro --haddockdir=/usr/lib/ghc-doc/haddock/base-prelude-/ --datasubdir=base-prelude --htmldir=/usr/share/doc/libghc-base-prelude-doc/html/ --enable-library-profiling\r\nConfiguring base-prelude-1.2.1...\r\nWarning: cannot determine version of /usr/bin/ghc-pkg :\r\n\"\"\r\nhlibrary.setup: The program 'ghc-pkg' is required but the version of\r\n/usr/bin/ghc-pkg could not be determined.\r\n}}}\r\n\r\n(Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-base-prelude&arch=m68k&ver=1.2.1-1&stamp=1530588494&raw=0)\r\n\r\nExamining the behavior of the affected ghc-pkg binary on m68k shows what's going on:\r\n\r\n{{{\r\nroot@pacman:~# uname -a\r\nLinux pacman 4.16.0-2-m68k #1 Debian 4.16.16-1 (2018-06-19) m68k GNU/Linux\r\nroot@pacman:~# ghc-pkg --version\r\nGHC package manager version 8.2.2\r\nroot@pacman:~# ghc-pkg --version | cat\r\nroot@pacman:~#\r\n}}}\r\n\r\nComparing that to an x86_64 machine shows that piping to cat should actually output something:\r\n\r\n{{{\r\nglaubitz@epyc:~$ uname -a\r\nLinux epyc 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 GNU/Linux\r\nglaubitz@epyc:~$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.2.2\r\nglaubitz@epyc:~$ ghc --version | cat\r\nThe Glorious Glasgow Haskell Compilation System, version 8.2.2\r\nglaubitz@epyc:~$\r\n}}}\r\n\r\nFurther investigation shows that the problem is partially resolved when building GHC with reduced optimization:\r\n\r\n{{{\r\n echo \"SRC_HC_OPTS += -O0 -H64m\" >> mk/build.mk\r\n echo \"GhcStage1HcOpts = -O\" >> mk/build.mk\r\n echo \"GhcStage2HcOpts = -O0\" >> mk/build.mk\r\n echo \"GhcLibHcOpts = -O\" >> mk/build.mk\r\n}}}\r\n\r\nThe above issue goes away, but ghc-pkg itself still shows some strange behavior:\r\n\r\n{{{\r\nmake_setup_recipe\r\nRunning ghc --make Setup.hs -o debian/hlibrary.setup\r\n[1 of 1] Compiling Main ( Setup.hs, Setup.o )\r\nLinking debian/hlibrary.setup ...\r\n. /usr/share/haskell-devscripts/Dh_Haskell.sh && \\\r\nconfigure_recipe\r\nRunning debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\\,-z\\,relro --haddockdir=/usr/lib/ghc-doc/haddock/microlens-ghc-0.4.8.0/ --datasubdir=microlens-ghc --htmldir=/usr/share/doc/libghc-microlens-ghc-doc/html/ --enable-library-profiling\r\nConfiguring microlens-ghc-0.4.8.0...\r\nhlibrary.setup: ghc-pkg dump failed: dieVerbatim: user error (hlibrary.setup:\r\n'/usr/bin/ghc-pkg' exited with an error:\r\nghc-pkg: <stdout>: commitBuffer: invalid argument (invalid character)\r\n)\r\n}}}\r\n\r\n(Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-microlens-ghc&arch=m68k&ver=0.4.8.0-2&stamp=1529960552&raw=0)\r\n\r\nTo reproduce the issue, GHC can be tested using QEMU which has pretty good support for the m68k target these days.","type_of_failure":"OtherFailure","blocking":[]} -->https://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/21141Nondeterministic segfault on simple hspec program with GHC 9.0 only2022-07-12T13:55:43ZRyan ScottNondeterministic segfault on simple hspec program with GHC 9.0 only_(Originally reported at https://github.com/ekmett/reflection/issues/51.)_
The [`reflection-2.1.6`](https://hackage.haskell.org/package/reflection-2.1.6) test suite nondeterministically segfaults on Linux and macOS when compiled with GH..._(Originally reported at https://github.com/ekmett/reflection/issues/51.)_
The [`reflection-2.1.6`](https://hackage.haskell.org/package/reflection-2.1.6) test suite nondeterministically segfaults on Linux and macOS when compiled with GHC 9.0.1 or 9.0.2. The furthest I've managed to minimize the issue is:
```hs
{-# LANGUAGE PackageImports #-}
{-# LANGUAGE ScopedTypeVariables #-}
module Main (main) where
import Control.Exception (ArithException(..), evaluate)
import Numeric.Natural (Natural)
import "hspec" Test.Hspec
import "hspec" Test.Hspec.QuickCheck
import "QuickCheck" Test.QuickCheck (Negative(..), NonNegative(..))
main :: IO ()
main = hspec spec
spec :: Spec
spec =
describe "A" $ do
describe "B" $ do
prop "identity" $
\(NonNegative (i :: Integer)) -> i `shouldBe` i
prop "should throw an Underflow exception on negative inputs" $
\(Negative (i :: Integer)) ->
evaluate (fromInteger i :: Natural) `shouldThrow` (== Underflow)
```
With GHC 8.10.7 or 9.2.1, this works as expected:
```
$ ghc-8.10.7 Bug.hs && ./Bug
Loaded package environment from /home/ryanglscott/Documents/Hacking/Haskell/ci-maintenance/checkout/ekmett/reflection/.ghc.environment.x86_64-linux-8.10.7
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
A
B
identity [✔]
+++ OK, passed 100 tests.
should throw an Underflow exception on negative inputs [✔]
+++ OK, passed 100 tests.
Finished in 0.0009 seconds
2 examples, 0 failures
$ ghc-9.2.1 Bug.hs && ./Bug
Loaded package environment from /home/ryanglscott/Documents/Hacking/Haskell/ci-maintenance/checkout/ekmett/reflection/.ghc.environment.x86_64-linux-9.2.1
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
A
B
identity [✔]
+++ OK, passed 100 tests.
should throw an Underflow exception on negative inputs [✔]
+++ OK, passed 100 tests.
Finished in 0.0013 seconds
2 examples, 0 failures
```
With GHC 9.0.2, however, this can segfault:
```
$ ghc-9.0.2 Bug.hs && ./Bug
Loaded package environment from /home/ryanglscott/Documents/Hacking/Haskell/ci-maintenance/checkout/ekmett/reflection/.ghc.environment.x86_64-linux-9.0.2
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
Linking Bug ...
A
B
identity [✔]
+++ OK, passed 100 tests.
should throw an Underflow exception on negative inputs [ ]Segmentation fault (core dumped)
```
This is somewhat nondeterministic. In situations where it doesn't segfault, an incorrect runtime result will be observed:
```
$ ./Bug
A
B
identity [✔]
+++ OK, passed 100 tests.
should throw an Underflow exception on negative inputs [✘]
Failures:
Bug.hs:22:47:
1) A.B should throw an Underflow exception on negative inputs
Falsifiable (after 54 tests and 2 shrinks):
Negative {getNegative = -1}
did not get expected exception: ArithException
To rerun use: --match "/A/B/should throw an Underflow exception on negative inputs/"
Randomized with seed 1065015581
Finished in 0.0028 seconds
2 examples, 1 failure
```
This example proves remarkably resistant to minimization, as attempting to delete code in various places seemingly makes the bug disappear.9.0.3Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/12377getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS...2022-07-24T07:02:04ZoherralagetExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also)System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv\[0\] to determine path and argv\[0\] might not be absolute path.
My environment:
```
$ uname -...System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv\[0\] to determine path and argv\[0\] might not be absolute path.
My environment:
```
$ uname -a
OpenBSD fizbuz.pilkki.ciz.fi 6.0 GENERIC.MP#2274 amd64
$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 7.10.3
```
This test program in OpenBSD:
```hs
module Main where
import System.Environment
main = getExecutablePath >>= print
```
returns
```
$ ./test
"./test"
```
For example in OS X the call returns absolute path:
```
$ ./test
"/Users/oherrala/tmp/test"
```
OpenBSD is one of the operating systems which gets fall back to using argv\[0\] to determine exec's location:
https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/System/Environment/ExecutablePath.hsc\#l152
Maybe the argv\[0\] result should be wrapped with realpath(3) to get absolute path?
This bug is also present in cabal-install and reported here: https://github.com/haskell/cabal/issues/3512\#issuecomment-231604356
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.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":"getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also)","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv[0] to determine path and argv[0] might not be absolute path.\r\n\r\nMy environment:\r\n\r\n{{{\r\n$ uname -a\r\nOpenBSD fizbuz.pilkki.ciz.fi 6.0 GENERIC.MP#2274 amd64\r\n$ ghc -V\r\nThe Glorious Glasgow Haskell Compilation System, version 7.10.3\r\n}}}\r\n\r\nThis test program in OpenBSD:\r\n\r\n{{{#!hs\r\nmodule Main where\r\nimport System.Environment\r\nmain = getExecutablePath >>= print\r\n}}}\r\n\r\nreturns\r\n\r\n{{{\r\n$ ./test\r\n\"./test\"\r\n}}}\r\n\r\nFor example in OS X the call returns absolute path:\r\n\r\n{{{\r\n$ ./test\r\n\"/Users/oherrala/tmp/test\"\r\n}}}\r\n\r\nOpenBSD is one of the operating systems which gets fall back to using argv[0] to determine exec's location:\r\n\r\nhttps://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/System/Environment/ExecutablePath.hsc#l152\r\n\r\nMaybe the argv[0] result should be wrapped with realpath(3) to get absolute path?\r\n\r\n\r\nThis bug is also present in cabal-install and reported here: https://github.com/haskell/cabal/issues/3512#issuecomment-231604356\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14150Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2)2022-07-27T10:30:03ZRyan ScottCtrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2)On Windows, the situation regarding Ctrl+C in GHCi has always been a little flaky in the sense that some shells (e.g., `mintty`-based ones) don't intercept Ctrl+C properly, causing GHCi to exit prematurely. However, up until 8.0.2, Ctrl+...On Windows, the situation regarding Ctrl+C in GHCi has always been a little flaky in the sense that some shells (e.g., `mintty`-based ones) don't intercept Ctrl+C properly, causing GHCi to exit prematurely. However, up until 8.0.2, Ctrl+C was being intercepted correctly on `cmd.exe` and PowerShell.
In GHC 8.2.1, however, this has changed. If you hit Ctrl+C in GHCi on PowerShell, then GHCi will appear to "exit" (in the sense that the prompt will go back to the PowerShell one). However, if you try typing and entering commands, there's a 50-50 chance it will be interpreted by PowerShell or a lingering GHCi process (indicating that GHCi wasn't really killed!).
(Apologies for the rather crude description, but I'm not sure of a better way to report what is going on here.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Ctrl+C causes GHCi 8.2.1 to \"exit\" in Windows (which didn't happen in 8.0.2)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx"],"type":"Bug","description":"On Windows, the situation regarding Ctrl+C in GHCi has always been a little flaky in the sense that some shells (e.g., `mintty`-based ones) don't intercept Ctrl+C properly, causing GHCi to exit prematurely. However, up until 8.0.2, Ctrl+C was being intercepted correctly on `cmd.exe` and PowerShell.\r\n\r\nIn GHC 8.2.1, however, this has changed. If you hit Ctrl+C in GHCi on PowerShell, then GHCi will appear to \"exit\" (in the sense that the prompt will go back to the PowerShell one). However, if you try typing and entering commands, there's a 50-50 chance it will be interpreted by PowerShell or a lingering GHCi process (indicating that GHCi wasn't really killed!). \r\n\r\n(Apologies for the rather crude description, but I'm not sure of a better way to report what is going on here.)","type_of_failure":"OtherFailure","blocking":[]} -->8.2.2https://gitlab.haskell.org/ghc/ghc/-/issues/21773LLVM backend should sign extend foreign function arguments and results as nec...2022-07-28T10:07:47ZBen GamariLLVM backend should sign extend foreign function arguments and results as necessaryIn https://gitlab.haskell.org/ghc/ghc/-/issues/20735#note_393658 we noticed that when asked to compile:
```c
short int func(short int targetType);
int main() {
func(-2);
return 0;
}
```
`clang` will emit the following IR:
```
define...In https://gitlab.haskell.org/ghc/ghc/-/issues/20735#note_393658 we noticed that when asked to compile:
```c
short int func(short int targetType);
int main() {
func(-2);
return 0;
}
```
`clang` will emit the following IR:
```
define i32 @main() #0 {
%1 = alloca i32, align 4
store i32 0, i32* %1, align 4
%2 = call signext i16 @func(i16 signext -2)
ret i32 0
}
```
Specifically, note the use of the `signext` [parameter attribute](https://llvm.org/docs/LangRef.html#parameter-attributes), which is necessary on platforms like AArch64/Darwin where the caller is responsible for sign extending (see Apple's [ABI documentation](https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms) for details).
We should be emulating this.
This caused #20735 with the LLVM backend.9.2.4Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20594tf-random's documentation fails to build with GHC 9.2.1's haddock on aarch64-...2022-08-04T15:22:18Zsternitf-random's documentation fails to build with GHC 9.2.1's haddock on aarch64-linux## Summary
haddock shipped with GHC 9.2.1 fails to build `tf-random`'s documentation due to `haddock: internal error: dist/doc/html/tf-random/haddock-prologue1387-0.txt: hGetContents: invalid argument (invalid byte sequence)`.
This see...## Summary
haddock shipped with GHC 9.2.1 fails to build `tf-random`'s documentation due to `haddock: internal error: dist/doc/html/tf-random/haddock-prologue1387-0.txt: hGetContents: invalid argument (invalid byte sequence)`.
This seems to be due to some decoding problem that is architecture-specific as I've only have been able to reproduce it on `aarch64-linux`. Additionally, the issue doesn't seem to be limited to `haddock`, since also `Cabal` reports while building: `Warning: tf-random.cabal:0:0: UTF8 encoding problem at byte offset 1083`.
With this hint taken into account, it seems the Problem is decoding the “ł” in “Michał Pałka”.
<details>
<summary>Full build log</summary>
```
setupCompilerEnvironmentPhase
Build with /nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1.
unpacking sources
unpacking source archive /nix/store/1nr84gxykdayb34wqhyhzapplwj6hj2x-tf-random-0.5.tar.gz
source root is tf-random-0.5
setting SOURCE_DATE_EPOCH to timestamp 1397051832 of file tf-random-0.5/tf-random.cabal
patching sources
compileBuildDriverPhase
setupCompileFlags: -package-db=/build/setup-package.conf.d -j4 +RTS -A64M -RTS -threaded -rtsopts
[1 of 1] Compiling Main ( Setup.hs, /build/Main.o )
Linking Setup ...
updateAutotoolsGnuConfigScriptsPhase
configuring
configureFlags: --verbose --prefix=/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5 --libdir=$prefix/lib/$compiler --libsubdir=$abi/$libname --docdir=/nix/store/pdia0inbjhx12hhyfpvavkmdnizxxbny-tf-random-0.5-doc/share/doc/tf-random-0.5 --with-gcc=gcc --package-db=/build/package.conf.d --ghc-options=-j4 +RTS -A64M -RTS --disable-split-objs --disable-library-profiling --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --enable-tests --disable-benchmarks --enable-library-vanilla --disable-library-for-ghci --ghc-option=-split-sections --extra-lib-dirs=/nix/store/iz9f5fjbk906c9j8zvr83skisy8mlbx7-ncurses-6.2/lib --extra-lib-dirs=/nix/store/wz31pppvk0ij3ykyafkw4xhp631b2i9m-libffi-3.4.2/lib --extra-lib-dirs=/nix/store/xwflzk66nkh7s45cqbjfmrc62qqncz3c-gmp-6.2.1/lib
Using Parsec parser
Warning: tf-random.cabal:0:0: UTF8 encoding problem at byte offset 1083
Configuring tf-random-0.5...
Dependency base >=4.2 && <5: using base-4.16.0.0
Dependency primitive >=0.3: using primitive-0.7.2.0
Dependency random: using random-1.2.1
Dependency time: using time-1.11.1.1
Source component graph: component lib
Configured component graph:
component tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9
include base-4.16.0.0
include primitive-0.7.2.0-26FrVImOeSRFMFxEAgiBFt
include random-1.2.1-4qyYj6P88hEL41FyrmzJfp
include time-1.11.1.1
Linked component graph:
unit tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9
include base-4.16.0.0
include primitive-0.7.2.0-26FrVImOeSRFMFxEAgiBFt
include random-1.2.1-4qyYj6P88hEL41FyrmzJfp
include time-1.11.1.1
System.Random.TF=tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9:System.Random.TF,System.Random.TF.Gen=tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9:System.Random.TF.Gen,System.Random.TF.Init=tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9:System.Random.TF.Init,System.Random.TF.Instances=tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9:System.Random.TF.Instances
Ready component graph:
definite tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9
depends base-4.16.0.0
depends primitive-0.7.2.0-26FrVImOeSRFMFxEAgiBFt
depends random-1.2.1-4qyYj6P88hEL41FyrmzJfp
depends time-1.11.1.1
Using Cabal-3.6.0.0 compiled by ghc-9.2
Using compiler: ghc-9.2.1
Using install prefix:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5
Executables installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/bin
Libraries installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/lib/ghc-9.2.1/aarch64-linux-ghc-9.2.1/tf-random-0.5-KP9k5IPcUYpGRNnHT8fvB9
Dynamic Libraries installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/lib/ghc-9.2.1/aarch64-linux-ghc-9.2.1
Private executables installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/libexec/aarch64-linux-ghc-9.2.1/tf-random-0.5
Data files installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/share/aarch64-linux-ghc-9.2.1/tf-random-0.5
Documentation installed in:
/nix/store/pdia0inbjhx12hhyfpvavkmdnizxxbny-tf-random-0.5-doc/share/doc/tf-random-0.5
Configuration files installed in:
/nix/store/m4c39knb9yw2c49xph4fdmm1xcggpp96-tf-random-0.5/etc
No alex found
Using ar found on system at:
/nix/store/10avvfvwvzj4y0z6zxij2qnz5pgqprg5-binutils-2.35.1/bin/ar
No c2hs found
No cpphs found
No doctest found
Using gcc version 9.3.0 given by user at:
/nix/store/1q1mif7h3lgxdaxg6j39hli5azikrfla-gcc-wrapper-9.3.0/bin/gcc
Using ghc version 9.2.1 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/ghc
Using ghc-pkg version 9.2.1 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/ghc-pkg
No ghcjs found
No ghcjs-pkg found
No greencard found
Using haddock version 2.26.0 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/haddock
No happy found
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.68 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/hpc
Using hsc2hs version 0.68.8 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/hsc2hs
Using hscolour version 1.24 found on system at:
/nix/store/cknsx4nddzjdm0g7vg9d9vpc9lvslscq-hscolour-1.24.4/bin/HsColour
No jhc found
Using ld found on system at:
/nix/store/579l1jpqmwjfghmlh9mnj6ykx06q2g38-binutils-wrapper-2.35.1/bin/ld.gold
No pkg-config found
Using runghc version 9.2.1 found on system at:
/nix/store/z4wznwpkzr5swfzkmyi14nnj5rqhxzwn-ghc-9.2.1/bin/runghc
Using strip version 2.35 found on system at:
/nix/store/10avvfvwvzj4y0z6zxij2qnz5pgqprg5-binutils-2.35.1/bin/strip
Using tar found on system at:
/nix/store/zfcd6sdfsfddhf5ybkarj4q241bsymn1-gnutar-1.34/bin/tar
No uhc found
building
Preprocessing library for tf-random-0.5..
Building library for tf-random-0.5..
[1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, dist/build/System/Random/TF/Gen.o, dist/build/System/Random/TF/Gen.dyn_o )
[2 of 4] Compiling System.Random.TF.Init ( src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o, dist/build/System/Random/TF/Init.dyn_o )
src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations]
In the use of `bitSize'
(imported from Data.Bits, but defined in GHC.Bits):
Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead"
|
94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 not implemented"
| ^^^^^^^
[3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, dist/build/System/Random/TF.o, dist/build/System/Random/TF.dyn_o )
[4 of 4] Compiling System.Random.TF.Instances ( src/System/Random/TF/Instances.hs, dist/build/System/Random/TF/Instances.o, dist/build/System/Random/TF/Instances.dyn_o )
running tests
Package has no test suites.
haddockPhase
Preprocessing library for tf-random-0.5..
Running Haddock on library for tf-random-0.5..
Warning: --source-* options are ignored when --hyperlinked-source is enabled.
100% ( 4 / 4) in 'System.Random.TF.Gen'
83% ( 5 / 6) in 'System.Random.TF.Init'
Missing documentation for:
Module header
src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations]
In the use of `bitSize'
(imported from Data.Bits, but defined in GHC.Bits):
Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead"
|
94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 not implemented"
| ^^^^^^^
100% ( 7 / 7) in 'System.Random.TF'
33% ( 1 / 3) in 'System.Random.TF.Instances'
Missing documentation for:
Random (src/System/Random/TF/Instances.hs:37)
randomEnum (src/System/Random/TF/Instances.hs:205)
haddock: internal error: dist/doc/html/tf-random/haddock-prologue1387-0.txt: hGetContents: invalid argument (invalid byte sequence)
builder for '/nix/store/jcfgav90wdc628xmnwy468dn5p57nj57-tf-random-0.5.drv' failed with exit code 1
```
</details>
## Steps to reproduce
Since this did not happen with GHC 9.2.1's release candidate, I've not investigated if this may have been caused by nixpkgs' build environment. To reproduce:
* Checkout nixpkgs at `a50888dc73b88ab344853c806ab63a3674728fc6`
* Run `nix-build -A haskell.packages.ghc921.tf-random` on `aarch64-linux`
## Expected behavior
Build `tf-random` successfully including its documentation and display no warnings about incorrect enconding.
## Environment
* GHC version used: 9.2.1
Optional:
* Operating System: NixOS
* System Architecture: aarch64-linux9.2.3Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/12433GHCi produces incorrect results when evaluating with compiled code2022-08-05T10:27:28ZIavor S. DiatchkiGHCi produces incorrect results when evaluating with compiled codeWhen GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem:
```hs
import Lex
num = 100000
txt1 = "aaa,aaa"
main :: IO (...When GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem:
```hs
import Lex
num = 100000
txt1 = "aaa,aaa"
main :: IO ()
main = print $ sum $ map (length . haskellLex) $ replicate num txt1
```
This program lexes the same string 100000 times, and prints the total number of tokens. Since we are lexing the same string, we'd expect to always get the same result, but due to this bug, this is not the case! We repeat the process 100000 times so that we can encounter the bug somewhat reliably---the problem does not occur every time.
To reproduce the problem, we need to load `Lex` in compiled form, not interpreted and with some optimizations:
```
ghc -c -O1 -dynamic Lex.hs
```
The source code for the "lexer" is as follows:
```haskell
module Lex (haskellLex) where
cclass :: Char -> Int
cclass c =
case c of
'a' -> 10
',' -> 11
'A' -> 0
'B' -> 0
'C' -> 0
'D' -> 0
'E' -> 0
'F' -> 0
haskellLex :: String -> [()]
haskellLex [] = []
haskellLex (i:is) =
case cclass i of
10 -> haskellLex62 is
11 -> () : haskellLex is
haskellLex62 :: String -> [()]
haskellLex62 [] = [()]
haskellLex62 (i:is) =
case cclass i of
0 -> [()]
1 -> [()]
2 -> [()]
3 -> [()]
4 -> [()]
10 -> haskellLex62 is
11 -> () : haskellLex (i:is)
x -> error ("[GHC BUG] cclass returned: " ++ show (i,x)
```
This is a minimized version from a full lexer. As odd as it looks, removing pretty much anything seems to cause the bug to go away. This is what happens when we run the program:
```
runhaskell test.hs
test.hs: [GHC BUG] cclass returned: (',',-556)
CallStack (from HasCallStack):
error, called at Lex.hs:36:12 in main:Lex
```
The problem is that after many evaluations, the function `cclass` returned `-556` for character `,`, when it should have returned `11`.
I've been able to reproduce this on two Linux machines, both running 64-bit Ubuntu (16.04). The issue does not seem to happen on Mac OS.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"GHCi produces incorrect results when evaluating with compiled code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["code","compiled","dynamic","ghci,","linking,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem:\r\n{{{#!hs\r\nimport Lex\r\n\r\nnum = 100000\r\ntxt1 = \"aaa,aaa\"\r\n\r\nmain :: IO ()\r\nmain = print $ sum $ map (length . haskellLex) $ replicate num txt1\r\n}}}\r\n\r\nThis program lexes the same string 100000 times, and prints the total number of tokens. Since we are lexing the same string, we'd expect to always get the same result, but due to this bug, this is not the case! We repeat the process 100000 times so that we can encounter the bug somewhat reliably---the problem does not occur every time.\r\n\r\nTo reproduce the problem, we need to load `Lex` in compiled form, not interpreted and with some optimizations:\r\n{{{\r\nghc -c -O1 -dynamic Lex.hs\r\n}}}\r\n\r\nThe source code for the \"lexer\" is as follows:\r\n{{{#!haskell\r\nmodule Lex (haskellLex) where\r\n\r\ncclass :: Char -> Int\r\ncclass c =\r\n case c of\r\n 'a' -> 10\r\n ',' -> 11\r\n\r\n 'A' -> 0\r\n 'B' -> 0\r\n 'C' -> 0\r\n 'D' -> 0\r\n 'E' -> 0\r\n 'F' -> 0\r\n\r\nhaskellLex :: String -> [()]\r\nhaskellLex [] = []\r\nhaskellLex (i:is) =\r\n case cclass i of\r\n 10 -> haskellLex62 is\r\n 11 -> () : haskellLex is\r\n\r\nhaskellLex62 :: String -> [()]\r\nhaskellLex62 [] = [()]\r\nhaskellLex62 (i:is) =\r\n case cclass i of\r\n 0 -> [()]\r\n 1 -> [()]\r\n 2 -> [()]\r\n 3 -> [()]\r\n 4 -> [()]\r\n\r\n 10 -> haskellLex62 is\r\n 11 -> () : haskellLex (i:is)\r\n\r\n x -> error (\"[GHC BUG] cclass returned: \" ++ show (i,x)\r\n}}}\r\n\r\nThis is a minimized version from a full lexer. As odd as it looks, removing pretty much anything seems to cause the bug to go away. This is what happens when we run the program:\r\n{{{\r\nrunhaskell test.hs\r\ntest.hs: [GHC BUG] cclass returned: (',',-556)\r\nCallStack (from HasCallStack):\r\n error, called at Lex.hs:36:12 in main:Lex\r\n}}}\r\n\r\nThe problem is that after many evaluations, the function `cclass` returned `-556` for character `,`, when it should have returned `11`.\r\n\r\nI've been able to reproduce this on two Linux machines, both running 64-bit Ubuntu (16.04). The issue does not seem to happen on Mac OS.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/21624"IntMulMayOfloOp" primop compiles to wrong Aarch64 assembly2022-08-05T14:46:34ZNatsu Kagami"IntMulMayOfloOp" primop compiles to wrong Aarch64 assembly## Summary
The primop `IntMulMayOfloOp` is being translated to a `MUL` instruction followed by a `CSET` (conditional set, with overflow flag) instruction on Aarch64 (see https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmT...## Summary
The primop `IntMulMayOfloOp` is being translated to a `MUL` instruction followed by a `CSET` (conditional set, with overflow flag) instruction on Aarch64 (see https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmToAsm/AArch64/CodeGen.hs#L894).
However, this is not correct: the overflow flag is never set on a `MUL` instruction. According to [A64 documentation](https://developer.arm.com/documentation/100076/0100/A64-Instruction-Set-Reference/Condition-Codes/Condition-flags?lang=en),
> Overflow occurs if the result of a signed add, subtract, or compare is greater than or equal to 2^31, or less than -2^31.
This means that the current primop will most likely return 0 all the time, which is wrong and potentially dangerous.
## Steps to reproduce
The following code always prints 0 in ghc 9.2.2 on Apple M1, but not in ghc 8.10.7 (which uses LLVM backend):
```hs
{-# LANGUAGE MagicHash #-}
module Main where
import GHC.Exts
import Data.Bits
unpack (I# a#) = a#
k :: Int
k = 134534534134534000 -- obviously does not fit in an int32, and so will overflow when squared.
bakaVariable = I# (mulIntMayOflo# (unpack k) (unpack k))
main = do
print bakaVariable
```
## Expected behavior
Should not print 0 at all.
## Environment
* GHC version used: 9.2.2
Optional:
* Operating System: Mac OS Monterey 12.3.1
* System Architecture: Aarch64 (Apple M1 Macbook Air)9.2.4Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17151Optimizer produces Core with an infinite <<loop>> v22022-08-06T23:27:36ZAlexey KuleshevichOptimizer produces Core with an infinite <<loop>> v2## Summary
I am not quite sure what it is? Is it coincidence, my coding style or just luck. Two years later after I reported a bug #13429 about optimizer generating an infinite loop, I stumble upon exactly the same bug, while implementi...## Summary
I am not quite sure what it is? Is it coincidence, my coding style or just luck. Two years later after I reported a bug #13429 about optimizer generating an infinite loop, I stumble upon exactly the same bug, while implementing the same algorithm (convolution), but in a completely different library and using a totally different approach. There are some similarities in types, but I can't draw a concrete comparison.
Unlike previous bug #13429, which was applicable to ghc-8.0 and was supposably fixed in ghc-8.2, this one is triggered in ghc-8.2 and up, but not for the prior version.
It is way too easy not not trigger the bug, in fact I initially noticed my tests failing for ghc-8.4.4 only, but once I reduced it to a smaller example, my tests started failing for ghc-8.6.5 as well as ghc-8.8.1
I apologize for the size of the uploaded module, but it took me a while to reduce it even to that level.
## Steps to reproduce
Uploaded are the two files needed to reproduce the bug:
* [Main.hs](/uploads/336cf55e11fb30f34178d2d0cd1d4ffe/Main.hs)
* [Array.hs](/uploads/0680b1bdd353b7632f6d3d96e6d95f8b/Array.hs)
Those modules only depend on `primitive` package, but this is only for convenience, since this bug could equally well be reproduced using either `ForeignPtr` or by dropping down to `ByteArray#` or `MutableByteArray#` prims.
Compiling with optimizations is necessary to trigger the bug:
```shell
$ ghc Main.hs Array.hs -O1 -fforce-recomp && ./Main
[1 of 2] Compiling Array ( Array.hs, Array.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
Main: <<loop>>
```
When inspecting Core we can see where the loop occurs right away:
```
Rec {
-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}
$s$fConstructPixe1 :: Index Int
$s$fConstructPixe1 = $s$fConstructPixe1
end Rec }
```
I found something peculiar, which could be useful for debugging this issue, is that the `Construct` instance for `P` representation is not used anywhere directly in the source code.
## Expected behavior
No infinite loop in the produced binary.
## Environment
* GHC version used: 8.2.2 - 8.8.1
Optional:
* Operating System: Ubuntu 18.04 LTS
* System Architecture: x86_648.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/13429Optimizer produces Core with an infinite <<loop>>2022-08-06T23:27:36ZAlexey KuleshevichOptimizer produces Core with an infinite <<loop>>While using vector package to implement convolution and supplying `-O1` or `-02` to ghc compilation results in core with an infinite loop. In order to trigger this behavior at least two modules is required. Attached is the minimal setup ...While using vector package to implement convolution and supplying `-O1` or `-02` to ghc compilation results in core with an infinite loop. In order to trigger this behavior at least two modules is required. Attached is the minimal setup that I could come up with, that demonstrates the issue. Here is the stack trace:
```
$ stack --install-ghc --resolver lts-8.3 exec -- ghc -O1 -prof -fprof-auto main.hs && ./main +RTS -xc
[1 of 2] Compiling Loop ( Loop.hs, Loop.o )
[2 of 2] Compiling Main ( main.hs, main.o )
Linking main ...
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.CAF
--> evaluated by: Main.main,
called from Main.CAF
--> evaluated by: Loop.toKernel.\,
called from Data.Vector.Fusion.Util.>>=,
called from Loop.toKernel,
called from Main.main,
called from Main.CAF
--> evaluated by: Data.Vector.Fusion.Util.>>=,
called from Loop.toKernel,
called from Main.main,
called from Main.CAF
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.CAF
main: <<loop>>
```
At first I though that it might be a bug in a vector package, which is still a possibility, but since I was not able to observe that issue with ghc-7.8.4, I decided to open an ticket here. I tested attached code with all of subsequent released ghc versions (7.10.1 - 8.0.2), which resulted in the infinite loop.
Worth noting that sometimes, when recompilation of only the `main.hs` file is enforced, program starts to work as expected. Here is an example:
```
$ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main
[1 of 2] Compiling Loop ( Loop.hs, Loop.o )
[2 of 2] Compiling Main ( main.hs, main.o )
Linking main ...
main: <<loop>>
$ touch main.hs
$ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main
[2 of 2] Compiling Main ( main.hs, main.o )
Linking main ...
<Image 1x1>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 8.0.2 |
| 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":"Optimizer produces Core with an infinite <<loop>>","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While using vector package to implement convolution and supplying `-O1` or `-02` to ghc compilation results in core with an infinite loop. In order to trigger this behavior at least two modules is required. Attached is the minimal setup that I could come up with, that demonstrates the issue. Here is the stack trace:\r\n\r\n{{{\r\n$ stack --install-ghc --resolver lts-8.3 exec -- ghc -O1 -prof -fprof-auto main.hs && ./main +RTS -xc\r\n[1 of 2] Compiling Loop ( Loop.hs, Loop.o )\r\n[2 of 2] Compiling Main ( main.hs, main.o )\r\nLinking main ...\r\n*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n Main.CAF\r\n --> evaluated by: Main.main,\r\n called from Main.CAF\r\n --> evaluated by: Loop.toKernel.\\,\r\n called from Data.Vector.Fusion.Util.>>=,\r\n called from Loop.toKernel,\r\n called from Main.main,\r\n called from Main.CAF\r\n --> evaluated by: Data.Vector.Fusion.Util.>>=,\r\n called from Loop.toKernel,\r\n called from Main.main,\r\n called from Main.CAF\r\n*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n Main.CAF\r\nmain: <<loop>>\r\n}}}\r\n\r\n\r\nAt first I though that it might be a bug in a vector package, which is still a possibility, but since I was not able to observe that issue with ghc-7.8.4, I decided to open an ticket here. I tested attached code with all of subsequent released ghc versions (7.10.1 - 8.0.2), which resulted in the infinite loop.\r\n\r\nWorth noting that sometimes, when recompilation of only the `main.hs` file is enforced, program starts to work as expected. Here is an example:\r\n\r\n\r\n{{{\r\n$ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main\r\n[1 of 2] Compiling Loop ( Loop.hs, Loop.o )\r\n[2 of 2] Compiling Main ( main.hs, main.o )\r\nLinking main ...\r\nmain: <<loop>>\r\n$ touch main.hs\r\n$ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main\r\n[2 of 2] Compiling Main ( main.hs, main.o )\r\nLinking main ...\r\n<Image 1x1>\r\n}}}\r\n","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->8.2.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/21968Regression of T124332022-08-09T19:21:42ZBenjamin MaurerRegression of T12433While trying to find a bug in my branch, I found that there seems to be a regression of test case T12433 (#12433):
Expected output of T12433: `8`
Compiling with GHC 9.2.2, using _no optimizations_ or _any opt. level_ works:
e.g.: `ghc -...While trying to find a bug in my branch, I found that there seems to be a regression of test case T12433 (#12433):
Expected output of T12433: `8`
Compiling with GHC 9.2.2, using _no optimizations_ or _any opt. level_ works:
e.g.: `ghc -O1 testsuite/tests/codeGen/should_run/T12433.hs && ./T12433` prints 8
Using GHC main HEAD (eb425eef418), flavour devel2:
`/path/ghcmain/ghc/_build/stage1/bin/ghc T12433.hs && ./T12433` -- prints 8 **works**
Using **any optimization level** fails:
`/path/ghcmain/ghc/_build/stage1/bin/ghc -O1 T12433.hs && ./T12433` -- prints 4229782
* Operating System: Ubuntu 20.04
* System Architecture: x86_64
#### Compiled with GHC 9.2.2:
[T12433.ghc922-noopt.cmm](/uploads/b275f417c01c26bdf8f4c9ab24294fca/T12433.ghc922-noopt.cmm)
[T12433.ghc922-opt.cmm](/uploads/c8c79dc6ddf798ae084e9629fbf68f3a/T12433.ghc922-opt.cmm)
#### Compiled with HEAD:
[T12433.noopt.cmm](/uploads/8038be665d896ccde009612c261ae02c/T12433.noopt.cmm)
[T12433.opt.cmm](/uploads/54b3d1678e2d407e64a3b99f76b9f640/T12433.opt.cmm)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/18370`BlockedIndefinitelyOnMVar` is thrown to non-blocked threads2022-09-12T00:31:00ZOle`BlockedIndefinitelyOnMVar` is thrown to non-blocked threads## Summary
`BlockedIndefinitelyOnMVar` is thrown to other threads that weren't blocked.
## Steps to reproduce
```haskell
-- Test.hs
{-# LANGUAGE TypeApplications #-}
module Main (main) where
import Control.Concurrent
import Control...## Summary
`BlockedIndefinitelyOnMVar` is thrown to other threads that weren't blocked.
## Steps to reproduce
```haskell
-- Test.hs
{-# LANGUAGE TypeApplications #-}
module Main (main) where
import Control.Concurrent
import Control.Exception
main :: IO ()
main = do
emptyVar <- newEmptyMVar @()
resultVar <- newEmptyMVar
_ <- forkIO $ do
caught <- try @SomeException (readMVar emptyVar)
putMVar resultVar caught
print ("thread", caught)
result <- readMVar resultVar
print ("main", result)
```
```
$ ghc -Wall -Wextra -threaded Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test
("thread",Left thread blocked indefinitely in an MVar operation)
Test: thread blocked indefinitely in an MVar operation
$ ./Test +RTS -N
Test: thread blocked indefinitely in an MVar operation
("thread",Left thread blocked indefinitely in an MVar operation)
```
It appears the main thread is being thrown a `BlockedIndefinitelyOnMVar` as well.
This can be decoupled from the empty MVar read:
```haskell
-- Test.hs
{-# LANGUAGE TypeApplications #-}
module Main (main) where
import Control.Concurrent
import Control.Concurrent.STM
import Control.Exception
main :: IO ()
main = do
emptyVar <- newEmptyTMVarIO @()
resultVar <- newEmptyMVar
_ <- forkIO $ do
caught <- try @SomeException (atomically (readTMVar emptyVar))
putMVar resultVar caught
print ("thread", caught)
result <- readMVar resultVar
print ("main", result)
```
```
$ ghc -Wall -Wextra -threaded Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test
("thread",Left thread blocked indefinitely in an STM transaction)
Test: thread blocked indefinitely in an MVar operation
$ ./Test +RTS -N
Test: thread blocked indefinitely in an MVar operation
("thread",Left thread blocked indefinitely in an STM transaction)
```
## Expected behavior
I expect both threads to print the result of `try` in unspecified order.
```
λ ./Test +RTS -N
("thread",Left thread blocked indefinitely in an MVar operation)
("main",Left thread blocked indefinitely in an MVar operation)
```
## Environment
* GHC version used:
- 8.10.1
- 8.8.3
Optional:
* Operating System: NixOS, Linux 5.4.31 x86_64