GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-05-11T16:19:25Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/6132Can't use both shebang line and #ifdef declarations in the same file.2021-05-11T16:19:25ZgfxmonkCan't use both shebang line and #ifdef declarations in the same file.I have an (admittedly awkward) script which can be compiled or interpreted.
If it's compiled, I want the full goodness. If it's interpreted, I want to run a "minimal" version (because if I don't have the compiled version, I probably don...I have an (admittedly awkward) script which can be compiled or interpreted.
If it's compiled, I want the full goodness. If it's interpreted, I want to run a "minimal" version (because if I don't have the compiled version, I probably don't have the required libraries either).
The following almost works:
```
module Main (main) where
#ifdef FANCY
import qualified System.Console.ANSI as Term
start = Term.setSGR [Term.SetColor Term.Foreground Term.Dull Term.Green]
end = Term.setSGR []
#else
start = return ()
end = return ()
#endif
main :: IO ()
main = do
start
putStrLn "hello world"
end
```
and then I can do:
```
$ runghc -cpp main.hs
hello world
^^ plain text
```
```
$ ghc -O -cpp -DFANCY main.hs
$ ./main
hello world
^^ green text (a.k.a "fancy")
```
I attempted to make this directly runnable by adding a shebang line of
{{{
\#!/usr/bin/runghc -cpp
}}}
But unfortunately that chokes with -cpp:
```
$ ghc -O -cpp -DFANCY main.hs
main.hs:1:0: error: invalid preprocessing directive #!
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't use both shebang line and #ifdef declarations in the same file.","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have an (admittedly awkward) script which can be compiled or interpreted.\r\n\r\nIf it's compiled, I want the full goodness. If it's interpreted, I want to run a \"minimal\" version (because if I don't have the compiled version, I probably don't have the required libraries either).\r\n\r\nThe following almost works:\r\n\r\n\r\n\r\n{{{\r\n\r\nmodule Main (main) where\r\n#ifdef FANCY\r\nimport qualified System.Console.ANSI as Term\r\nstart = Term.setSGR [Term.SetColor Term.Foreground Term.Dull Term.Green]\r\nend = Term.setSGR []\r\n#else\r\nstart = return ()\r\nend = return ()\r\n#endif\r\nmain :: IO ()\r\nmain = do\r\n\tstart\r\n\tputStrLn \"hello world\"\r\n\tend\r\n}}}\r\n\r\n\r\nand then I can do:\r\n\r\n\r\n{{{\r\n$ runghc -cpp main.hs\r\nhello world\r\n^^ plain text\r\n}}}\r\n\r\n\r\n\r\n{{{\r\n$ ghc -O -cpp -DFANCY main.hs\r\n$ ./main\r\nhello world\r\n^^ green text (a.k.a \"fancy\")\r\n}}}\r\n\r\n\r\nI attempted to make this directly runnable by adding a shebang line of\r\n\r\n{{{\r\n#!/usr/bin/runghc -cpp\r\n}}}\r\n\r\n\r\nBut unfortunately that chokes with -cpp:\r\n\r\n{{{\r\n\r\n$ ghc -O -cpp -DFANCY main.hs\r\n\r\nmain.hs:1:0: error: invalid preprocessing directive #!\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/7411Exceptions are optimized away in certain situations2020-05-27T16:04:30ZSimon Hengelsol@typeful.netExceptions are optimized away in certain situationsThe issue came up in [this thread on glasgow-haskell-users](http://www.haskell.org/pipermail/glasgow-haskell-users/2012-November/023027.html).
## Steps to reproduce:
```hs
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
...The issue came up in [this thread on glasgow-haskell-users](http://www.haskell.org/pipermail/glasgow-haskell-users/2012-November/023027.html).
## Steps to reproduce:
```hs
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq` return () :: IO ())
```
```
$ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs
```
### Expected result:
The program should fail with:
```
Foo: Prelude.undefined
```
### Actual result:
The program succeeds.
Compiling the program with `-fno-state-hack` helps.8.10.2Tobias Dammerstdammers@gmail.comTobias Dammerstdammers@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/10770Typeable solver has strange effects2021-08-18T15:47:36ZNeil MitchellTypeable solver has strange effectsGiven:
```hs
import Data.Typeable
main = print $ foo $ Just ()
foo :: Typeable (t a) => t a -> String
foo x = let k = show $ typeOf x in k
```
I get:
```
TypeableInfer.hs:7:24:
Could not deduce (Typeable t) arising from a use of...Given:
```hs
import Data.Typeable
main = print $ foo $ Just ()
foo :: Typeable (t a) => t a -> String
foo x = let k = show $ typeOf x in k
```
I get:
```
TypeableInfer.hs:7:24:
Could not deduce (Typeable t) arising from a use of `typeOf'
from the context (Typeable (t a))
bound by the type signature for
foo :: Typeable (t a) => t a -> String
at TypeableInfer.hs:6:8-38
In the second argument of `($)', namely `typeOf x'
In the expression: show $ typeOf x
In an equation for `k': k = show $ typeOf x
```
However, the error goes away with the minor modification of:
```hs
foo x = show $ typeOf x
```
<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 | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typeable solver has strange effects","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Given:\r\n\r\n{{{#!hs\r\nimport Data.Typeable\r\n\r\nmain = print $ foo $ Just ()\r\n\r\nfoo :: Typeable (t a) => t a -> String\r\nfoo x = let k = show $ typeOf x in k\r\n}}}\r\n\r\nI get:\r\n\r\n{{{\r\nTypeableInfer.hs:7:24:\r\n Could not deduce (Typeable t) arising from a use of `typeOf'\r\n from the context (Typeable (t a))\r\n bound by the type signature for\r\n foo :: Typeable (t a) => t a -> String\r\n at TypeableInfer.hs:6:8-38\r\n In the second argument of `($)', namely `typeOf x'\r\n In the expression: show $ typeOf x\r\n In an equation for `k': k = show $ typeOf x\r\n}}}\r\n\r\nHowever, the error goes away with the minor modification of:\r\n\r\n{{{#!hs\r\nfoo x = show $ typeOf x\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/12937String merging broken on Darwin2020-01-21T14:15:36ZBen GamariString merging broken on Darwin[D1290](https://phabricator.haskell.org/D1290) introduced logic to have the linker merge strings to resolve #9577. Unfortunately this logic does not appear to work as expected on OS X. This should be fixed.
<details><summary>Trac metada...[D1290](https://phabricator.haskell.org/D1290) introduced logic to have the linker merge strings to resolve #9577. Unfortunately this logic does not appear to work as expected on OS X. This should be fixed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"String merging broken on Darwin","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Phab:D1290 introduced logic to have the linker merge strings to resolve #9577. Unfortunately this logic does not appear to work as expected on OS X. This should be fixed.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/12965String merging broken on Windows2021-02-16T21:13:32ZBen GamariString merging broken on Windows#9577 introduced string literal merging via the linker. Unfortunately I haven't been able to get this to function on Windows, resulting in testsuite failures of #9577.
Even `gcc` appears to do the wrong thing here,
```
$ cat hi.c
#incl...#9577 introduced string literal merging via the linker. Unfortunately I haven't been able to get this to function on Windows, resulting in testsuite failures of #9577.
Even `gcc` appears to do the wrong thing here,
```
$ cat hi.c
#include <stdio.h>
const char *hi = "hello world";
extern const char *hi2;
void main() {
printf("%p %p", hi, hi2);
}
$ cat hi2.c
const char *hi2 = "hello world";
$ gcc -c hi.c; gcc -c hi2.c; gcc -fmerge-all-constants hi2.o hi.o
$ ./a.exe
0x100403040 0x100403030
$ gcc -s hi2.c
$ cat hi2.s
.file "hi2.c"
.globl hi
.section .rdata,"dr"
.LC0:
.ascii "hello world\0"
.data
.align 8
hi:
.quad .LC0
.ident "GCC: (GNU) 5.3.0"
```
<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 | Phyx- |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"String merging broken on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx-"],"type":"Bug","description":"#9577 introduced string literal merging via the linker. Unfortunately I haven't been able to get this to function on Windows, resulting in testsuite failures of #9577.\r\n\r\nEven `gcc` appears to do the wrong thing here,\r\n{{{\r\n$ cat hi.c\r\n#include <stdio.h>\r\nconst char *hi = \"hello world\";\r\nextern const char *hi2;\r\nvoid main() { \r\n printf(\"%p %p\", hi, hi2);\r\n}\r\n$ cat hi2.c\r\nconst char *hi2 = \"hello world\";\r\n$ gcc -c hi.c; gcc -c hi2.c; gcc -fmerge-all-constants hi2.o hi.o\r\n$ ./a.exe \r\n0x100403040 0x100403030\r\n$ gcc -s hi2.c\r\n$ cat hi2.s\r\n\t.file\t\"hi2.c\"\r\n\t.globl\thi\r\n\t.section .rdata,\"dr\"\r\n.LC0:\r\n\t.ascii \"hello world\\0\"\r\n\t.data\r\n\t.align 8\r\nhi:\r\n\t.quad\t.LC0\r\n\t.ident\t\"GCC: (GNU) 5.3.0\"\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/13515Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows2020-01-21T14:15:37ZBen GamariUnexpected failure of T11223_simple_duplicate_lib on 32-bit WindowsThe `T11223_simple_duplicate_lib` test seems to fail on 32-bit Windows with,
```patch
diff --git a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32 b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-min...The `T11223_simple_duplicate_lib` test seems to fail on 32-bit Windows with,
```patch
diff --git a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32 b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32
index 4d4656f..5fdd70f 100644
--- a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32
+++ b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32
@@ -1,15 +1,15 @@
GHC runtime linker: fatal error: I found a duplicate definition for symbol
- a
+ _a
whilst processing object file
- E:\ghc-dev\msys64\home\Tamar\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\libfoo_dup_lib.a
+ C:\msys64\home\ben\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\libfoo_dup_lib.a
The symbol was previously defined in
- E:\ghc-dev\msys64\home\Tamar\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\bar_dup_lib.o
+ C:\msys64\home\ben\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\bar_dup_lib.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
-ghc-stage2.exe: ^^ Could not load 'c', dependency unresolved. See top entry above.
+ghc-stage2.exe: ^^ Could not load '_c', dependency unresolved. See top entry above.
ByteCodeLink: can't find label
```
While this difference looks innocuous enough, I can't recall anything in recent history that would cause such a change so I want to make sure we have a record of it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx- |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx-"],"type":"Bug","description":"The `T11223_simple_duplicate_lib` test seems to fail on 32-bit Windows with,\r\n{{{#!patch\r\ndiff --git a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32 b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32\r\nindex 4d4656f..5fdd70f 100644\r\n--- a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32\r\n+++ b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32\r\n@@ -1,15 +1,15 @@\r\n GHC runtime linker: fatal error: I found a duplicate definition for symbol\r\n- a\r\n+ _a\r\n whilst processing object file\r\n- E:\\ghc-dev\\msys64\\home\\Tamar\\ghc\\testsuite\\tests\\rts\\T11223\\T11223_simple_duplicate_lib.run\\libfoo_dup_lib.a\r\n+ C:\\msys64\\home\\ben\\ghc\\testsuite\\tests\\rts\\T11223\\T11223_simple_duplicate_lib.run\\libfoo_dup_lib.a\r\n The symbol was previously defined in\r\n- E:\\ghc-dev\\msys64\\home\\Tamar\\ghc\\testsuite\\tests\\rts\\T11223\\T11223_simple_duplicate_lib.run\\bar_dup_lib.o\r\n+ C:\\msys64\\home\\ben\\ghc\\testsuite\\tests\\rts\\T11223\\T11223_simple_duplicate_lib.run\\bar_dup_lib.o\r\n This could be caused by:\r\n * Loading two different object files which export the same symbol\r\n * Specifying the same object file twice on the GHCi command line\r\n * An incorrect `package.conf' entry, causing some object to be\r\n loaded twice.\r\n-ghc-stage2.exe: ^^ Could not load 'c', dependency unresolved. See top entry above.\r\n+ghc-stage2.exe: ^^ Could not load '_c', dependency unresolved. See top entry above.\r\n \r\n \r\n ByteCodeLink: can't find label\r\n\r\n}}}\r\n\r\nWhile this difference looks innocuous enough, I can't recall anything in recent history that would cause such a change so I want to make sure we have a record of it.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/13624loadObj() does not respect alignment2021-02-10T08:21:58ZTrevor L. McDonellloadObj() does not respect alignmentThis is perhaps known, but I'll write it down here in case somebody else runs into this problem as well.
Since `loadObj()` just `mmap()`s the entire object file and decodes it *in place*, it does not respect the alignment requirements s...This is perhaps known, but I'll write it down here in case somebody else runs into this problem as well.
Since `loadObj()` just `mmap()`s the entire object file and decodes it *in place*, it does not respect the alignment requirements specified in the section headers. This is problematic for instructions which require alignment, e.g. SSE, AVX.
The attached `map.ll` program is `map (+1)` over an array of floating point numbers. In particular, the core loop is 8-way SIMD vectorised x 4-way unrolled, for 32-elements per loop iteration. A tail loop handles any remainder one-at-a-time.
You can compile it using `llc -filetype=obj -mcpu=native map.ll`. For a CPU with AVX instructions (sandy bridge or later) you should get the following:
```
$ objdump -d map.o
Disassembly of section .text:
0000000000000000 <map>:
0: 49 89 f3 mov %rsi,%r11
3: 49 29 fb sub %rdi,%r11
6: 0f 8e f9 00 00 00 jle 105 <map+0x105>
c: 49 83 fb 20 cmp $0x20,%r11
10: 0f 82 bd 00 00 00 jb d3 <map+0xd3>
16: 4d 89 da mov %r11,%r10
19: 49 83 e2 e0 and $0xffffffffffffffe0,%r10
1d: 4d 89 d9 mov %r11,%r9
20: 49 83 e1 e0 and $0xffffffffffffffe0,%r9
24: 0f 84 a9 00 00 00 je d3 <map+0xd3>
2a: 49 01 fa add %rdi,%r10
2d: 48 8d 44 ba 60 lea 0x60(%rdx,%rdi,4),%rax
32: 49 8d 7c b8 60 lea 0x60(%r8,%rdi,4),%rdi
37: c5 fc 28 05 00 00 00 vmovaps 0x0(%rip),%ymm0 # 3f <map+0x3f>
3e: 00
3f: 4c 89 c9 mov %r9,%rcx
42: 66 66 66 66 66 2e 0f data16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1)
49: 1f 84 00 00 00 00 00
50: c5 f8 10 4f a0 vmovups -0x60(%rdi),%xmm1
55: c5 f8 10 57 c0 vmovups -0x40(%rdi),%xmm2
5a: c5 f8 10 5f e0 vmovups -0x20(%rdi),%xmm3
5f: c5 f8 10 27 vmovups (%rdi),%xmm4
63: c4 e3 75 18 4f b0 01 vinsertf128 $0x1,-0x50(%rdi),%ymm1,%ymm1
6a: c4 e3 6d 18 57 d0 01 vinsertf128 $0x1,-0x30(%rdi),%ymm2,%ymm2
71: c4 e3 65 18 5f f0 01 vinsertf128 $0x1,-0x10(%rdi),%ymm3,%ymm3
78: c4 e3 5d 18 67 10 01 vinsertf128 $0x1,0x10(%rdi),%ymm4,%ymm4
7f: c5 f4 58 c8 vaddps %ymm0,%ymm1,%ymm1
83: c5 ec 58 d0 vaddps %ymm0,%ymm2,%ymm2
87: c5 e4 58 d8 vaddps %ymm0,%ymm3,%ymm3
8b: c5 dc 58 e0 vaddps %ymm0,%ymm4,%ymm4
8f: c4 e3 7d 19 48 b0 01 vextractf128 $0x1,%ymm1,-0x50(%rax)
96: c5 f8 11 48 a0 vmovups %xmm1,-0x60(%rax)
9b: c4 e3 7d 19 50 d0 01 vextractf128 $0x1,%ymm2,-0x30(%rax)
a2: c5 f8 11 50 c0 vmovups %xmm2,-0x40(%rax)
a7: c4 e3 7d 19 58 f0 01 vextractf128 $0x1,%ymm3,-0x10(%rax)
ae: c5 f8 11 58 e0 vmovups %xmm3,-0x20(%rax)
b3: c4 e3 7d 19 60 10 01 vextractf128 $0x1,%ymm4,0x10(%rax)
ba: c5 f8 11 20 vmovups %xmm4,(%rax)
be: 48 83 e8 80 sub $0xffffffffffffff80,%rax
c2: 48 83 ef 80 sub $0xffffffffffffff80,%rdi
c6: 48 83 c1 e0 add $0xffffffffffffffe0,%rcx
ca: 75 84 jne 50 <map+0x50>
cc: 4d 39 cb cmp %r9,%r11
cf: 75 05 jne d6 <map+0xd6>
d1: eb 32 jmp 105 <map+0x105>
d3: 49 89 fa mov %rdi,%r10
d6: 4c 29 d6 sub %r10,%rsi
d9: 4a 8d 04 92 lea (%rdx,%r10,4),%rax
dd: 4b 8d 0c 90 lea (%r8,%r10,4),%rcx
e1: c5 fa 10 05 00 00 00 vmovss 0x0(%rip),%xmm0 # e9 <map+0xe9>
e8: 00
e9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
f0: c5 fa 58 09 vaddss (%rcx),%xmm0,%xmm1
f4: c5 fa 11 08 vmovss %xmm1,(%rax)
f8: 48 83 c0 04 add $0x4,%rax
fc: 48 83 c1 04 add $0x4,%rcx
100: 48 ff ce dec %rsi
103: 75 eb jne f0 <map+0xf0>
105: c5 f8 77 vzeroupper
108: c3 req
```
The attached `test.c` will load the object file and try to execute it. The `#define N` on line 7 will change the size of the array. For fewer than 32 elements this works as expected (where the input array is \[0..N-1\]):
```
$ ./build.sh
+ llc-4.0 -filetype=obj -mcpu=native map.ll
+ ghc --make -no-hs-main test.c
$ ./a.out
array size is 31
calling function...
ok
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0
```
For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault.
```
$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) run
Process 7294 launched: '<snip>/a.out' (x86_64)
array size is 32
calling function...
Process 7294 stopped
* thread #1: tid = 0xc41676, 0x000000010019f207, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x000000010019f207
-> 0x10019f207: vmovaps 0xe1(%rip), %ymm0
0x10019f20f: movq %r9, %rcx
0x10019f212: nopw %cs:(%rax,%rax)
0x10019f220: vmovups -0x60(%rdi), %xmm1
```
The `VMOVAPS` instruction requires the source address to be 32-byte aligned. It is attempting to load 8 floats from one of the const sections (the ones for the +1), but since the section was not loaded at the required alignment, fails.
I've tested this on x86_64 macOS (Mach-O) and ubuntu (ELF). I don't have any other systems to test on.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"loadObj() does not respect alignment","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is perhaps known, but I'll write it down here in case somebody else runs into this problem as well.\r\n\r\nSince `loadObj()` just `mmap()`s the entire object file and decodes it ''in place'', it does not respect the alignment requirements specified in the section headers. This is problematic for instructions which require alignment, e.g. SSE, AVX.\r\n\r\nThe attached `map.ll` program is `map (+1)` over an array of floating point numbers. In particular, the core loop is 8-way SIMD vectorised x 4-way unrolled, for 32-elements per loop iteration. A tail loop handles any remainder one-at-a-time.\r\n\r\nYou can compile it using `llc -filetype=obj -mcpu=native map.ll`. For a CPU with AVX instructions (sandy bridge or later) you should get the following:\r\n\r\n{{{\r\n$ objdump -d map.o\r\nDisassembly of section .text:\r\n\r\n0000000000000000 <map>:\r\n 0:\t49 89 f3 \tmov %rsi,%r11\r\n 3:\t49 29 fb \tsub %rdi,%r11\r\n 6:\t0f 8e f9 00 00 00 \tjle 105 <map+0x105>\r\n c:\t49 83 fb 20 \tcmp $0x20,%r11\r\n 10:\t0f 82 bd 00 00 00 \tjb d3 <map+0xd3>\r\n 16:\t4d 89 da \tmov %r11,%r10\r\n 19:\t49 83 e2 e0 \tand $0xffffffffffffffe0,%r10\r\n 1d:\t4d 89 d9 \tmov %r11,%r9\r\n 20:\t49 83 e1 e0 \tand $0xffffffffffffffe0,%r9\r\n 24:\t0f 84 a9 00 00 00 \tje d3 <map+0xd3>\r\n 2a:\t49 01 fa \tadd %rdi,%r10\r\n 2d:\t48 8d 44 ba 60 \tlea 0x60(%rdx,%rdi,4),%rax\r\n 32:\t49 8d 7c b8 60 \tlea 0x60(%r8,%rdi,4),%rdi\r\n 37:\tc5 fc 28 05 00 00 00 \tvmovaps 0x0(%rip),%ymm0 # 3f <map+0x3f>\r\n 3e:\t00\r\n 3f:\t4c 89 c9 \tmov %r9,%rcx\r\n 42:\t66 66 66 66 66 2e 0f \tdata16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1)\r\n 49:\t1f 84 00 00 00 00 00\r\n 50:\tc5 f8 10 4f a0 \tvmovups -0x60(%rdi),%xmm1\r\n 55:\tc5 f8 10 57 c0 \tvmovups -0x40(%rdi),%xmm2\r\n 5a:\tc5 f8 10 5f e0 \tvmovups -0x20(%rdi),%xmm3\r\n 5f:\tc5 f8 10 27 \tvmovups (%rdi),%xmm4\r\n 63:\tc4 e3 75 18 4f b0 01 \tvinsertf128 $0x1,-0x50(%rdi),%ymm1,%ymm1\r\n 6a:\tc4 e3 6d 18 57 d0 01 \tvinsertf128 $0x1,-0x30(%rdi),%ymm2,%ymm2\r\n 71:\tc4 e3 65 18 5f f0 01 \tvinsertf128 $0x1,-0x10(%rdi),%ymm3,%ymm3\r\n 78:\tc4 e3 5d 18 67 10 01 \tvinsertf128 $0x1,0x10(%rdi),%ymm4,%ymm4\r\n 7f:\tc5 f4 58 c8 \tvaddps %ymm0,%ymm1,%ymm1\r\n 83:\tc5 ec 58 d0 \tvaddps %ymm0,%ymm2,%ymm2\r\n 87:\tc5 e4 58 d8 \tvaddps %ymm0,%ymm3,%ymm3\r\n 8b:\tc5 dc 58 e0 \tvaddps %ymm0,%ymm4,%ymm4\r\n 8f:\tc4 e3 7d 19 48 b0 01 \tvextractf128 $0x1,%ymm1,-0x50(%rax)\r\n 96:\tc5 f8 11 48 a0 \tvmovups %xmm1,-0x60(%rax)\r\n 9b:\tc4 e3 7d 19 50 d0 01 \tvextractf128 $0x1,%ymm2,-0x30(%rax)\r\n a2:\tc5 f8 11 50 c0 \tvmovups %xmm2,-0x40(%rax)\r\n a7:\tc4 e3 7d 19 58 f0 01 \tvextractf128 $0x1,%ymm3,-0x10(%rax)\r\n ae:\tc5 f8 11 58 e0 \tvmovups %xmm3,-0x20(%rax)\r\n b3:\tc4 e3 7d 19 60 10 01 \tvextractf128 $0x1,%ymm4,0x10(%rax)\r\n ba:\tc5 f8 11 20 \tvmovups %xmm4,(%rax)\r\n be:\t48 83 e8 80 \tsub $0xffffffffffffff80,%rax\r\n c2:\t48 83 ef 80 \tsub $0xffffffffffffff80,%rdi\r\n c6:\t48 83 c1 e0 \tadd $0xffffffffffffffe0,%rcx\r\n ca:\t75 84 \tjne 50 <map+0x50>\r\n cc:\t4d 39 cb \tcmp %r9,%r11\r\n cf:\t75 05 \tjne d6 <map+0xd6>\r\n d1:\teb 32 \tjmp 105 <map+0x105>\r\n d3:\t49 89 fa \tmov %rdi,%r10\r\n d6:\t4c 29 d6 \tsub %r10,%rsi\r\n d9:\t4a 8d 04 92 \tlea (%rdx,%r10,4),%rax\r\n dd:\t4b 8d 0c 90 \tlea (%r8,%r10,4),%rcx\r\n e1:\tc5 fa 10 05 00 00 00 \tvmovss 0x0(%rip),%xmm0 # e9 <map+0xe9>\r\n e8:\t00\r\n e9:\t0f 1f 80 00 00 00 00 \tnopl 0x0(%rax)\r\n f0:\tc5 fa 58 09 \tvaddss (%rcx),%xmm0,%xmm1\r\n f4:\tc5 fa 11 08 \tvmovss %xmm1,(%rax)\r\n f8:\t48 83 c0 04 \tadd $0x4,%rax\r\n fc:\t48 83 c1 04 \tadd $0x4,%rcx\r\n 100:\t48 ff ce \tdec %rsi\r\n 103:\t75 eb \tjne f0 <map+0xf0>\r\n 105:\tc5 f8 77 \tvzeroupper\r\n 108:\tc3 \treq\r\n}}}\r\n\r\nThe attached `test.c` will load the object file and try to execute it. The `#define N` on line 7 will change the size of the array. For fewer than 32 elements this works as expected (where the input array is [0..N-1]):\r\n\r\n{{{\r\n$ ./build.sh\r\n+ llc-4.0 -filetype=obj -mcpu=native map.ll\r\n+ ghc --make -no-hs-main test.c\r\n\r\n$ ./a.out\r\narray size is 31\r\ncalling function...\r\nok\r\n1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0\r\n}}}\r\n\r\nFor 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault.\r\n\r\n{{{\r\n$ lldb a.out\r\n(lldb) target create \"a.out\"\r\nCurrent executable set to 'a.out' (x86_64).\r\n(lldb) run\r\nProcess 7294 launched: '<snip>/a.out' (x86_64)\r\narray size is 32\r\ncalling function...\r\nProcess 7294 stopped\r\n* thread #1: tid = 0xc41676, 0x000000010019f207, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)\r\n frame #0: 0x000000010019f207\r\n-> 0x10019f207: vmovaps 0xe1(%rip), %ymm0\r\n 0x10019f20f: movq %r9, %rcx\r\n 0x10019f212: nopw %cs:(%rax,%rax)\r\n 0x10019f220: vmovups -0x60(%rdi), %xmm1\r\n}}}\r\n\r\nThe `VMOVAPS` instruction requires the source address to be 32-byte aligned. It is attempting to load 8 floats from one of the const sections (the ones for the +1), but since the section was not loaded at the required alignment, fails.\r\n\r\nI've tested this on x86_64 macOS (Mach-O) and ubuntu (ELF). I don't have any other systems to test on.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2Artem PyanykhArtem Pyanykhhttps://gitlab.haskell.org/ghc/ghc/-/issues/15184T4442 fails on i3862020-01-21T14:15:36ZÖmer Sinan AğacanT4442 fails on i386```
omer@i386-chroot:~/ghc/testsuite/tests/primops/should_run$ ~/ghc/inplace/bin/ghc-stage2 T4442.hs
[1 of 1] Compiling Main ( T4442.hs, T4442.o )
T4442.hs:135:14: error: Not in scope: data constructor `I64#'
|
135 | ...```
omer@i386-chroot:~/ghc/testsuite/tests/primops/should_run$ ~/ghc/inplace/bin/ghc-stage2 T4442.hs
[1 of 1] Compiling Main ( T4442.hs, T4442.o )
T4442.hs:135:14: error: Not in scope: data constructor `I64#'
|
135 | (\arr i (I64# a) s -> write arr i a s)
| ^^^^
```
Looking at the code, it uses `Int` on 64-bit, but `Int64` on i386, probably to use 64-bit integers on both platforms. I think we can just use `Int64` on both platforms and get rid of the CPP to avoid further breakage in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"T4442 fails on i386","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nomer@i386-chroot:~/ghc/testsuite/tests/primops/should_run$ ~/ghc/inplace/bin/ghc-stage2 T4442.hs\r\n[1 of 1] Compiling Main ( T4442.hs, T4442.o )\r\n\r\nT4442.hs:135:14: error: Not in scope: data constructor `I64#'\r\n |\r\n135 | (\\arr i (I64# a) s -> write arr i a s)\r\n | ^^^^\r\n}}}\r\n\r\nLooking at the code, it uses `Int` on 64-bit, but `Int64` on i386, probably to use 64-bit integers on both platforms. I think we can just use `Int64` on both platforms and get rid of the CPP to avoid further breakage in the future.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/15437Internal error when applying a scoped type variable inside a typed expression...2023-08-11T11:04:21ZdminuosoInternal error when applying a scoped type variable inside a typed expression quotation```hs
{-# LANGUAGE TemplateHaskell #-}
import TestMod
f :: Int
f = $$(foo)
main :: IO ()
main = main
```
```hs
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeApplications #-}
module TestMod wh...```hs
{-# LANGUAGE TemplateHaskell #-}
import TestMod
f :: Int
f = $$(foo)
main :: IO ()
main = main
```
```hs
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeApplications #-}
module TestMod where
import Language.Haskell.TH.Syntax (Q, TExp)
get :: forall a. Int
get = 1
foo :: forall a. Q (TExp Int)
foo = [|| get @a ||]
```
```
Test.hs:6:8: error:
• The exact Name ‘a’ is not in scope
Probable cause: you used a unique Template Haskell name (NameU),
perhaps via newName, but did not bind it
If that's it, then -ddump-splices might be useful
• In the result of the splice:
$foo
To see what the splice expanded to, use -ddump-splices
In the Template Haskell splice $$(foo)
In the expression: $$(foo)
|
6 | f = $$(foo)
| ^^^
Test.hs:6:8: error:
• GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [r3Kl :-> Identifier[f::Int, TopLevelLet [] True],
r3PI :-> Identifier[main::IO (), TopLevelLet [r3PI :-> main] True]]
• In the type ‘a’
In the expression: get @a
In the result of the splice:
$foo
To see what the splice expanded to, use -ddump-splices
|
6 | f = $$(foo)
|
```
<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":"Internal error when applying a scoped type variable inside a typed expression quotation","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":"{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nimport TestMod\r\n\r\nf :: Int\r\nf = $$(foo)\r\n\r\nmain :: IO ()\r\nmain = main\r\n}}}\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# LANGUAGE TypeApplications #-}\r\n\r\nmodule TestMod where\r\n\r\nimport Language.Haskell.TH.Syntax (Q, TExp)\r\n\r\nget :: forall a. Int\r\nget = 1\r\n\r\nfoo :: forall a. Q (TExp Int)\r\nfoo = [|| get @a ||]\r\n}}}\r\n\r\n{{{\r\nTest.hs:6:8: error:\r\n • The exact Name ‘a’ is not in scope\r\n Probable cause: you used a unique Template Haskell name (NameU),\r\n perhaps via newName, but did not bind it\r\n If that's it, then -ddump-splices might be useful\r\n • In the result of the splice:\r\n $foo\r\n To see what the splice expanded to, use -ddump-splices\r\n In the Template Haskell splice $$(foo)\r\n In the expression: $$(foo)\r\n |\r\n6 | f = $$(foo)\r\n | ^^^\r\n\r\nTest.hs:6:8: error:\r\n • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: [r3Kl :-> Identifier[f::Int, TopLevelLet [] True],\r\n r3PI :-> Identifier[main::IO (), TopLevelLet [r3PI :-> main] True]]\r\n • In the type ‘a’\r\n In the expression: get @a\r\n In the result of the splice:\r\n $foo\r\n To see what the splice expanded to, use -ddump-splices\r\n |\r\n6 | f = $$(foo)\r\n |\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/16087TH tests fail in ext-interp way when ghc-stage2 is built using LLVM2021-05-24T14:15:07ZBen GamariTH tests fail in ext-interp way when ghc-stage2 is built using LLVMThis is a continuation of #15274.
Currently the testsuite fails with around 40 test failures, all in `th/` in the `ext-interp` way when building GHC with `BUILD_FLAVOUR=perf-llvm`:
```
Unexpected results from:
TEST="ClosedFam1TH T10620...This is a continuation of #15274.
Currently the testsuite fails with around 40 test failures, all in `th/` in the `ext-interp` way when building GHC with `BUILD_FLAVOUR=perf-llvm`:
```
Unexpected results from:
TEST="ClosedFam1TH T10620 T10828 T11721_TH T11797 T12478_1 T12646 T13642 T14060 T15502 T15738 T15792 T15845 T1835 T3920 T4135 T4188 T5037 T5362 T7477 T8761 T8884 T8953 T9262 T9692 T9738 TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_implicitParams TH_reifyDecl1 TH_reifyExplicitForAllFams TH_reifyInstances TH_reifyMkName TH_repE2 TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples"
SUMMARY for test run started at Sun Dec 23 06:01:39 2018 UTC
0:10:09 spent to go through
6745 total tests, which gave rise to
26266 test cases, of which
19055 were skipped
42 had missing libraries
7040 expected passes
89 expected failures
0 caused framework failures
0 caused framework warnings
0 unexpected passes
40 unexpected failures
0 unexpected stat failures
Unexpected failures:
th/TH_repE2.run TH_repE2 [exit code non-0] (ext-interp)
th/TH_repPrim.run TH_repPrim [exit code non-0] (ext-interp)
th/TH_repPrim2.run TH_repPrim2 [exit code non-0] (ext-interp)
th/TH_repUnboxedTuples.run TH_repUnboxedTuples [exit code non-0] (ext-interp)
th/TH_repGuard.run TH_repGuard [exit code non-0] (ext-interp)
th/TH_reifyDecl1.run TH_reifyDecl1 [exit code non-0] (ext-interp)
th/TH_reifyMkName.run TH_reifyMkName [exit code non-0] (ext-interp)
th/TH_reifyInstances.run TH_reifyInstances [exit code non-0] (ext-interp)
th/TH_reifyExplicitForAllFams.run TH_reifyExplicitForAllFams [exit code non-0] (ext-interp)
th/T3920.run T3920 [exit code non-0] (ext-interp)
th/T4188.run T4188 [exit code non-0] (ext-interp)
th/T1835.run T1835 [exit code non-0] (ext-interp)
th/T5037.run T5037 [exit code non-0] (ext-interp)
th/T5362.run T5362 [exit code non-0] (ext-interp)
th/TH_RichKinds.run TH_RichKinds [exit code non-0] (ext-interp)
th/TH_RichKinds2.run TH_RichKinds2 [exit code non-0] (ext-interp)
th/T4135.run T4135 [exit code non-0] (ext-interp)
th/TH_TyInstWhere2.run TH_TyInstWhere2 [exit code non-0] (ext-interp)
th/ClosedFam1TH.run ClosedFam1TH [exit code non-0] (ext-interp)
th/TH_Roles3.run TH_Roles3 [exit code non-0] (ext-interp)
th/T7477.run T7477 [exit code non-0] (ext-interp)
th/T8884.run T8884 [exit code non-0] (ext-interp)
th/T9262.run T9262 [exit code non-0] (ext-interp)
th/T9692.run T9692 [exit code non-0] (ext-interp)
th/T8953.run T8953 [exit code non-0] (ext-interp)
th/T9738.run T9738 [exit code non-0] (ext-interp)
th/T10620.run T10620 [exit code non-0] (ext-interp)
th/T10828.run T10828 [exit code non-0] (ext-interp)
th/T11721_TH.run T11721_TH [exit code non-0] (ext-interp)
th/T11797.run T11797 [exit code non-0] (ext-interp)
th/T8761.run T8761 [exit code non-0] (ext-interp)
th/T12478_1.run T12478_1 [exit code non-0] (ext-interp)
th/T12646.run T12646 [exit code non-0] (ext-interp)
th/T13642.run T13642 [exit code non-0] (ext-interp)
th/T14060.run T14060 [exit code non-0] (ext-interp)
th/T15502.run T15502 [exit code non-0] (ext-interp)
th/TH_implicitParams.run TH_implicitParams [exit code non-0] (ext-interp)
th/T15738.run T15738 [exit code non-0] (ext-interp)
th/T15792.run T15792 [exit code non-0] (ext-interp)
th/T15845.run T15845 [exit code non-0] (ext-interp)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TH tests fail in ext-interp way when ghc-stage2 is built using LLVM","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a continuation of #15274.\r\n\r\nCurrently the testsuite fails with around 40 test failures, all in `th/` in the `ext-interp` way when building GHC with `BUILD_FLAVOUR=perf-llvm`:\r\n{{{\r\n\r\nUnexpected results from:\r\nTEST=\"ClosedFam1TH T10620 T10828 T11721_TH T11797 T12478_1 T12646 T13642 T14060 T15502 T15738 T15792 T15845 T1835 T3920 T4135 T4188 T5037 T5362 T7477 T8761 T8884 T8953 T9262 T9692 T9738 TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_implicitParams TH_reifyDecl1 TH_reifyExplicitForAllFams TH_reifyInstances TH_reifyMkName TH_repE2 TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples\"\r\n\r\nSUMMARY for test run started at Sun Dec 23 06:01:39 2018 UTC\r\n 0:10:09 spent to go through\r\n 6745 total tests, which gave rise to\r\n 26266 test cases, of which\r\n 19055 were skipped\r\n\r\n 42 had missing libraries\r\n 7040 expected passes\r\n 89 expected failures\r\n\r\n 0 caused framework failures\r\n 0 caused framework warnings\r\n 0 unexpected passes\r\n 40 unexpected failures\r\n 0 unexpected stat failures\r\n\r\nUnexpected failures:\r\n th/TH_repE2.run TH_repE2 [exit code non-0] (ext-interp)\r\n th/TH_repPrim.run TH_repPrim [exit code non-0] (ext-interp)\r\n th/TH_repPrim2.run TH_repPrim2 [exit code non-0] (ext-interp)\r\n th/TH_repUnboxedTuples.run TH_repUnboxedTuples [exit code non-0] (ext-interp)\r\n th/TH_repGuard.run TH_repGuard [exit code non-0] (ext-interp)\r\n th/TH_reifyDecl1.run TH_reifyDecl1 [exit code non-0] (ext-interp)\r\n th/TH_reifyMkName.run TH_reifyMkName [exit code non-0] (ext-interp)\r\n th/TH_reifyInstances.run TH_reifyInstances [exit code non-0] (ext-interp)\r\n th/TH_reifyExplicitForAllFams.run TH_reifyExplicitForAllFams [exit code non-0] (ext-interp)\r\n th/T3920.run T3920 [exit code non-0] (ext-interp)\r\n th/T4188.run T4188 [exit code non-0] (ext-interp)\r\n th/T1835.run T1835 [exit code non-0] (ext-interp)\r\n th/T5037.run T5037 [exit code non-0] (ext-interp)\r\n th/T5362.run T5362 [exit code non-0] (ext-interp)\r\n th/TH_RichKinds.run TH_RichKinds [exit code non-0] (ext-interp)\r\n th/TH_RichKinds2.run TH_RichKinds2 [exit code non-0] (ext-interp)\r\n th/T4135.run T4135 [exit code non-0] (ext-interp)\r\n th/TH_TyInstWhere2.run TH_TyInstWhere2 [exit code non-0] (ext-interp)\r\n th/ClosedFam1TH.run ClosedFam1TH [exit code non-0] (ext-interp)\r\n th/TH_Roles3.run TH_Roles3 [exit code non-0] (ext-interp)\r\n th/T7477.run T7477 [exit code non-0] (ext-interp)\r\n th/T8884.run T8884 [exit code non-0] (ext-interp)\r\n th/T9262.run T9262 [exit code non-0] (ext-interp)\r\n th/T9692.run T9692 [exit code non-0] (ext-interp)\r\n th/T8953.run T8953 [exit code non-0] (ext-interp)\r\n th/T9738.run T9738 [exit code non-0] (ext-interp)\r\n th/T10620.run T10620 [exit code non-0] (ext-interp)\r\n th/T10828.run T10828 [exit code non-0] (ext-interp)\r\n th/T11721_TH.run T11721_TH [exit code non-0] (ext-interp)\r\n th/T11797.run T11797 [exit code non-0] (ext-interp)\r\n th/T8761.run T8761 [exit code non-0] (ext-interp)\r\n th/T12478_1.run T12478_1 [exit code non-0] (ext-interp)\r\n th/T12646.run T12646 [exit code non-0] (ext-interp)\r\n th/T13642.run T13642 [exit code non-0] (ext-interp)\r\n th/T14060.run T14060 [exit code non-0] (ext-interp)\r\n th/T15502.run T15502 [exit code non-0] (ext-interp)\r\n th/TH_implicitParams.run TH_implicitParams [exit code non-0] (ext-interp)\r\n th/T15738.run T15738 [exit code non-0] (ext-interp)\r\n th/T15792.run T15792 [exit code non-0] (ext-interp)\r\n th/T15845.run T15845 [exit code non-0] (ext-interp)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/16386T16219 fails on Windows2020-01-21T14:15:36ZBen GamariT16219 fails on Windows```
=====> T16219(normal) 85 of 6839 [0, 0, 0]
cd "backpack/cabal/T16219/T16219.run" && $MAKE -s --no-print-directory T16219 CLEANUP=1
Wrong exit code for T16219()(expected 0 , actual 2 )
Stderr ( T16219 ):
C:\GitLabRunner\builds\8fc0e...```
=====> T16219(normal) 85 of 6839 [0, 0, 0]
cd "backpack/cabal/T16219/T16219.run" && $MAKE -s --no-print-directory T16219 CLEANUP=1
Wrong exit code for T16219()(expected 0 , actual 2 )
Stderr ( T16219 ):
C:\GitLabRunner\builds\8fc0e283\0\ghc\ghc\inplace\lib\../mingw/bin\ar.exe: dist\build\backpack-issue-0.1.0.0-60IHJZyC3G628wj7263Sr0-library-a+Dil0EMVFuE1Kv7vqZWLGcN\objs-3388\libHSbackpack-issue-0.1.0.0-60IHJZyC3G628wj7263Sr0-library-a+Dil0EMVFuE1Kv7vqZWLGcN.a: No such file or directory
make[2]: *** [Makefile:12: T16219] Error 1
*** unexpected failure for T16219(normal)
=====> bkpcabal03(normal) 88 of 6839 [0, 1, 0]
```
<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":"T16219 fails on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n=====> T16219(normal) 85 of 6839 [0, 0, 0]\r\ncd \"backpack/cabal/T16219/T16219.run\" && $MAKE -s --no-print-directory T16219 CLEANUP=1 \r\nWrong exit code for T16219()(expected 0 , actual 2 )\r\nStderr ( T16219 ):\r\nC:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\inplace\\lib\\../mingw/bin\\ar.exe: dist\\build\\backpack-issue-0.1.0.0-60IHJZyC3G628wj7263Sr0-library-a+Dil0EMVFuE1Kv7vqZWLGcN\\objs-3388\\libHSbackpack-issue-0.1.0.0-60IHJZyC3G628wj7263Sr0-library-a+Dil0EMVFuE1Kv7vqZWLGcN.a: No such file or directory\r\nmake[2]: *** [Makefile:12: T16219] Error 1\r\n*** unexpected failure for T16219(normal)\r\n=====> bkpcabal03(normal) 88 of 6839 [0, 1, 0]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/16388T15904 fails on Windows2020-01-21T14:15:37ZBen GamariT15904 fails on Windows```
=====> T15904(normal) 2036 of 6839 [0, 6, 0]
cd "hp2ps/T15904.run" && $MAKE -s --no-print-directory T15904
Wrong exit code for T15904()(expected 0 , actual 2 )
Stdout ( T15904 ):
[1 of 1] Compiling T15904 ( T15904.hs, T15...```
=====> T15904(normal) 2036 of 6839 [0, 6, 0]
cd "hp2ps/T15904.run" && $MAKE -s --no-print-directory T15904
Wrong exit code for T15904()(expected 0 , actual 2 )
Stdout ( T15904 ):
[1 of 1] Compiling T15904 ( T15904.hs, T15904.o )
Linking "T15904".exe ...
Stderr ( T15904 ):
"T15904".exe.manifest: openFile: invalid argument (Invalid argument)
make[2]: *** [Makefile:7: T15904] Error 1
*** unexpected failure for T15904(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx- |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T15904 fails on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx-"],"type":"Bug","description":"{{{\r\n=====> T15904(normal) 2036 of 6839 [0, 6, 0]\r\ncd \"hp2ps/T15904.run\" && $MAKE -s --no-print-directory T15904 \r\nWrong exit code for T15904()(expected 0 , actual 2 )\r\nStdout ( T15904 ):\r\n[1 of 1] Compiling T15904 ( T15904.hs, T15904.o )\r\nLinking \"T15904\".exe ...\r\nStderr ( T15904 ):\r\n\"T15904\".exe.manifest: openFile: invalid argument (Invalid argument)\r\nmake[2]: *** [Makefile:7: T15904] Error 1\r\n*** unexpected failure for T15904(normal)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/16390T10672 fails2020-01-21T14:15:37ZBen GamariT10672 failsThis test, which is only run on Windows, seems to be reliably timing out.
Marking as broken.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...This test, which is only run on Windows, seems to be reliably timing out.
Marking as broken.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"T10672 fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This test, which is only run on Windows, seems to be reliably timing out.\r\n\r\nMarking as broken.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/16813T15633b is fragile on Windows2021-06-21T09:36:49ZBen GamariT15633b is fragile on WindowsIn !1130 I saw one build where `T15633b` failed segfaulted on Windows:
```
Wrong exit code for T15633b(ghci)(expected 0 , actual 11 )
Stdout ( T15633b ):
True
Stderr ( T15633b ):
TcPluginGHCi
Access violation in generated code when rea...In !1130 I saw one build where `T15633b` failed segfaulted on Windows:
```
Wrong exit code for T15633b(ghci)(expected 0 , actual 11 )
Stdout ( T15633b ):
True
Stderr ( T15633b ):
TcPluginGHCi
Access violation in generated code when reading 0xfffffffffffffff8
Attempting to reconstruct a stack trace...
Frame Code address
* 0x54ffaf0 0x3001263 C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2c01263
* 0x54ffb70 0x2fd578c C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bd578c
* 0x54ffbe0 0x2fcacbf C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bcacbf
* 0x54ffd30 0x2fcb63f C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bcb63f
* 0x54ffe20 0x2fc0270 C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bc0270
* 0x54ffed0 0x2fc11c7 C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bc11c7
* 0x54fff10 0x2fc1a4f C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bc1a4f
* 0x54fff50 0x2fe92f8 C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2be92f8
* 0x54fff80 0x7ffef5d284d4 C:\Windows\System32\KERNEL32.DLL+0x84d4
* 0x54fffd0 0x7ffef86be851 C:\Windows\SYSTEM32\ntdll.dll+0x6e851
*** unexpected failure for T15633b(ghci)
```
I suspect this means that either plugins or GHCi (or the combination of the two) are fragile on Windows. I'm going to mark both `T15633b` and `T15633a` as fragile on Windows.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/16845T5611 is broken in GHCi way2020-01-21T14:15:37ZBen GamariT5611 is broken in GHCi way!1221 seems to have revealed that `T5611` fails in the `ghci` testsuite way:
```patch
--- concurrent/should_run/T5611.run/T5611.stdout.normalised 2019-06-18 14:23:24.913214129 +0000
+++ concurrent/should_run/T5611.run/T5611.run.stdout.no...!1221 seems to have revealed that `T5611` fails in the `ghci` testsuite way:
```patch
--- concurrent/should_run/T5611.run/T5611.stdout.normalised 2019-06-18 14:23:24.913214129 +0000
+++ concurrent/should_run/T5611.run/T5611.run.stdout.normalised 2019-06-18 14:23:24.913214129 +0000
@@ -1,2 +1,3 @@
child: Sleeping
+child: Done waiting
parent: Done throwing exception
```
Moreover, the test itself appears to be wrong; it's using an `unsafe` foreign call whereas the #5611 is concerning `safe` calls.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16907hpc_fork test is broken2020-01-21T14:15:37ZBen Gamarihpc_fork test is brokenThe `hpc_fork` test appears to be broken in the `profasm` way.:
```
cd "libraries/hpc/tests/fork/hpc_fork.run" && "/builds/ghc/ghc/inplace/bin/hp2ps" hpc_fork<
hp2ps error when processing heap profile for hpc_fork
*** unexpected failure...The `hpc_fork` test appears to be broken in the `profasm` way.:
```
cd "libraries/hpc/tests/fork/hpc_fork.run" && "/builds/ghc/ghc/inplace/bin/hp2ps" hpc_fork<
hp2ps error when processing heap profile for hpc_fork
*** unexpected failure for hpc_fork(profasm)
```8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17034T16511 fails on Windows2020-01-21T14:15:36ZBen GamariT16511 fails on WindowsI have no idea why:
```diff
--- /dev/null 2019-08-05 02:16:38.000000000 +0000
+++ driver/T16511/T16511.run/T16511.run.stderr.normalised 2019-08-05 02:16:37.880233100 +0000
@@ -0,0 +1,3 @@
+The system cannot find the path specified.
+The ...I have no idea why:
```diff
--- /dev/null 2019-08-05 02:16:38.000000000 +0000
+++ driver/T16511/T16511.run/T16511.run.stderr.normalised 2019-08-05 02:16:37.880233100 +0000
@@ -0,0 +1,3 @@
+The system cannot find the path specified.
+The system cannot find the path specified.
+The system cannot find the path specified.
```8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17133Performance regression in bsb-http-chunked from GHC-8.6.5 to GHC-8.8.12020-01-23T18:06:53ZSimon JakobiPerformance regression in bsb-http-chunked from GHC-8.6.5 to GHC-8.8.1Some benchmarks in the [`bsb-http-chunked` package](https://github.com/sjakobi/bsb-http-chunked) are [up to ~13% slower](https://github.com/sjakobi/bsb-http-chunked/issues/26) with GHC-8.8.1 when compared with GHC-8.6.5.
A diff of the C...Some benchmarks in the [`bsb-http-chunked` package](https://github.com/sjakobi/bsb-http-chunked) are [up to ~13% slower](https://github.com/sjakobi/bsb-http-chunked/issues/26) with GHC-8.8.1 when compared with GHC-8.6.5.
A diff of the Core of the relevant module can be viewed [here](https://github.com/sjakobi/bsb-http-chunked/commit/653179c18adcd3d08ce8f19e1f3d97d0cc993b6e). Virtually all changes are in the demand analysis annotations, so I suspect that this is the cause of the slowdown. [The module](https://github.com/sjakobi/bsb-http-chunked/blob/17f74814be7adeb60b09e6a52ff1aca9032e0f56/Data/ByteString/Builder/HTTP/Chunked.hs) depends only on `base` and `bytestring`, and `bytestring` didn't have any relevant code changes from v0.10.8.2 to v0.10.9.0.
I don't really understand demand analysis, but one questions that popped up was, why multiple let-bindings lost their `[Dmd=<S,U>]` annotation although they are used in case analyses right after their definitions. For example `outRemaining`:
```
let {
outRemaining :: ghc-prim-0.5.3:GHC.Prim.Int#
[LclId]
outRemaining = ghc-prim-0.5.3:GHC.Prim.minusAddr# ww1 ww } in
case ghc-prim-0.5.3:GHC.Prim.<# outRemaining 23# of {
```
Another question is why a join point binding previously called `exit`, was renamed to `w$j` and gained the annotation `InlPrag=NOUSERINLINE[2]`.
```
join {
$w$j [InlPrag=NOUSERINLINE[2], Dmd=<C(S),C(U(U,U))>]
:: ghc-prim-0.5.3:GHC.Prim.State# ghc-prim-0.5.3:GHC.Prim.RealWorld
-> (# ghc-prim-0.5.3:GHC.Prim.State#
ghc-prim-0.5.3:GHC.Prim.RealWorld,
BuildSignal r #)
[LclId[JoinId(1)], Arity=1, Str=<L,U>]
```8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17144Is `threadstatus-9333` a fragile test?2020-01-21T14:15:36ZAndreas KlebingerIs `threadstatus-9333` a fragile test?I think I have seen that one fail a few times now when changing unrelated things.
Last one being in https://gitlab.haskell.org/AndreasK/ghc/-/jobs/148860
Is this a fragile test? Is there something broken? Anybode else noticed that?I think I have seen that one fail a few times now when changing unrelated things.
Last one being in https://gitlab.haskell.org/AndreasK/ghc/-/jobs/148860
Is this a fragile test? Is there something broken? Anybode else noticed that?8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17237Consider CmmFloat - Code motion to move shared subexpressions into the common...2020-01-21T14:17:18ZAndreas KlebingerConsider CmmFloat - Code motion to move shared subexpressions into the common path.Consider this motivating code snippet:
```haskell
maybeFlipCond :: Cond -> Maybe Cond
maybeFlipCond cond = case cond of
EQQ -> Just EQQ
NE -> Just NE
...
LE -> Just GE
GE -> Just LE
...Consider this motivating code snippet:
```haskell
maybeFlipCond :: Cond -> Maybe Cond
maybeFlipCond cond = case cond of
EQQ -> Just EQQ
NE -> Just NE
...
LE -> Just GE
GE -> Just LE
_other -> Nothing
```
This results in the following Cmm code, with some unrelated parts removed:
```C
c2uc: // global
I64[Sp - 8] = c2tU;
R1 = R2;
Sp = Sp - 8;
if (R1 & 7 != 0) goto c2tU; else goto c2tV;
c2tV: // global
call (I64[R1])(R1) returns to c2tU, args: 8, res: 8, upd: 8;
c2tU: // global
_c2u9::I64 = %MO_UU_Conv_W32_W64(I32[I64[R1 - 1] - 4]);
if (_c2u9::I64 >= 11) goto c2tY; else goto u2uK;
u2uK: // global
if (_c2u9::I64 < 1) goto c2tY; else goto u2uL;
c2tY: // global
R1 = Nothing_closure+1;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
u2uL: // global
switch [1 .. 10] _c2u9::I64 {
case 1 : goto c2tZ;
case 2 : goto c2u0;
case 3 : goto c2u1;
case 4 : goto c2u2;
case 5 : goto c2u3;
case 6 : goto c2u4;
case 7 : goto c2u5;
case 8 : goto c2u6;
case 9 : goto c2u7;
case 10 : goto c2u8;
}
c2u8: // global
R1 = maybeFlipCond1_closure+2;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
c2u7: // global
R1 = maybeFlipCond2_closure+2;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
...: // global
repeat for maybeFlipCond [3..9] _closure
c2tZ: // global
R1 = maybeFlipCond10_closure+2;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
}
```
In this case there is no reason why the SP modification couldn't be pulled out into the common path.
In this case this would have the benefits of:
* Reducing code size
* It might improve latency and therefore performance between the SP modification and the indirect jump to SP (the call).
As a knock-on effect we could also transform the jumptable into a lookup table improving performance further. (See #17238)
Now the prime use case for this would be SP modifications as this pattern is somewhat common. But it could easily be generalized into a CmmFloat pass which does this with arbitrary shared expressions.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17241Replace useages of con2tag_* in the deriving code with data2tag#2021-02-09T20:13:52ZAndreas KlebingerReplace useages of con2tag_* in the deriving code with data2tag### Motivation
As I understand it we generate(ed?) con2tag_Con bindings in the deriving code well before data2Tag was a thing.
## Proposal
Now that we have data2Tag we should replace useages of con2tag with it.## Motivation
As I understand it we generate(ed?) con2tag_Con bindings in the deriving code well before data2Tag was a thing.
## Proposal
Now that we have data2Tag we should replace useages of con2tag with it.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17247cgrun071 is broken on i3862020-01-21T14:15:37ZBen Gamaricgrun071 is broken on i386It looks like `cgrun071`, which tests the `popcnt` primops, is broken on i386. In `optasm` the failure takes the form of ill-formed assembler output:
```
=====> cgrun071(optasm) 369 of 7138 [0, 0, 0]
cd "codeGen/should_run/cgrun071.run" ...It looks like `cgrun071`, which tests the `popcnt` primops, is broken on i386. In `optasm` the failure takes the form of ill-formed assembler output:
```
=====> cgrun071(optasm) 369 of 7138 [0, 0, 0]
cd "codeGen/should_run/cgrun071.run" && "/builds/ghc/ghc/inplace/bin/ghc-stage2" -o cgrun071 cgrun071.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -msse4.2 -O -fasm <
Compile failed (exit code 1) errors were:
[1 of 1] Compiling Main ( cgrun071.hs, cgrun071.o )
cgrun071.hs:42:24: warning: [-Wdeprecations (in -Wdefault)]
In the use of ‘bitSize’ (imported from Data.Bits):
Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead"
/tmp/ghc2523_0/ghc_4.s: Assembler messages:
/tmp/ghc2523_0/ghc_4.s:4116:0: error:
Error: unsupported instruction `movq'
/tmp/ghc2523_0/ghc_4.s:4230:0: error:
Error: unsupported instruction `movq'
...
/tmp/ghc2523_0/ghc_4.s:6003:0: error:
Error: unsupported instruction `movq'
`cc' failed in phase `Assembler'. (Exit code: 1)
*** unexpected failure for cgrun071(optasm)
```
Whereas in the `profasm` way it triggers assertions in the NCG:
```
=====> cgrun070(profasm) 369 of 7138 [0, 1, 0]
cd "codeGen/should_run/cgrun070.run" && "/builds/ghc/ghc/inplace/bin/ghc-stage2" -o cgrun070 cgrun070.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto <
Compile failed (exit code 1) errors were:
[1 of 1] Compiling Main ( cgrun071.hs, cgrun071.o )
cgrun071.hs:42:24: warning: [-Wdeprecations (in -Wdefault)]
In the use of ‘bitSize’ (imported from Data.Bits):
Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead"
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.9.0.20190925:
getRegister(x86)
I64[R1 + 11]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1179:37 in ghc:Outputable
pprPanic, called at compiler/nativeGen/X86/CodeGen.hs:1054:26 in ghc:X86.CodeGen
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
*** unexpected failure for cgrun071(profasm)
```8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17252Mangled reified GADT record selector2020-07-01T14:36:13ZRichard Eisenbergrae@richarde.devMangled reified GADT record selectorFrom @RyanGlScott (originally https://gitlab.haskell.org/ghc/ghc/issues/16980#note_222424, but unrelated to that ticket):
Consider this program:
```haskell
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TemplateHaskell #-}
module Main where
impo...From @RyanGlScott (originally https://gitlab.haskell.org/ghc/ghc/issues/16980#note_222424, but unrelated to that ticket):
Consider this program:
```haskell
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TemplateHaskell #-}
module Main where
import Language.Haskell.TH
$([d| data T b where
MkT :: { unT :: a } -> T a
|])
$(return [])
main :: IO ()
main = putStrLn $(reify 'unT >>= stringE . pprint)
```
If you run this, you'll get a surprising answer:
```
$ /opt/ghc/8.8.1/bin/runghc Bug.hs
Main.unT :: forall (a_0 :: *) . Main.T b_1 -> b_1
```
The reported type is `forall a. T b -> b`, which is completely bogus! Even stranger is that if I load this module into GHCi and *then* reify it:
```
$ /opt/ghc/8.8.1/bin/ghci Bug.hs -XTemplateHaskell
GHCi, version 8.8.1: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Main ( Bug.hs, interpreted )
Ok, one module loaded.
λ> import Language.Haskell.TH
λ> putStrLn $(reify 'unT >>= stringE . pprint)
Main.unT :: forall (a_0 :: *) . Main.T a_0 -> a_0
```
Then the reported type is `forall a. T a -> a`, as expected. I can't help but wonder if this is another case of metavariables leaking through when they shouldn't.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17253compact_gc is fragile in ghci way2020-01-21T14:15:36ZBen Gamaricompact_gc is fragile in ghci wayTwice over the past two months the test has failed with a timeout in the `ghci` way in the `validate-x86_64-linux-deb9-debug` job. I suspect this is due to the slowness of the interpreter although this is slightly surprising given that t...Twice over the past two months the test has failed with a timeout in the `ghci` way in the `validate-x86_64-linux-deb9-debug` job. I suspect this is due to the slowness of the interpreter although this is slightly surprising given that the test doesn't appear to build a terribly large heap.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17256T3389 broken in nightly-i386-linux-deb92020-01-21T14:15:37ZBen GamariT3389 broken in nightly-i386-linux-deb9In the `nightly-i386-linux-deb9` job the `hpc`, `profasm`, and `profthreaded` ways all fail with:
```
=====> T3389(profasm) 1176 of 7141 [0, 6, 0]
cd "driver/T3389.run" && "/builds/ghc/ghc/inplace/bin/ghc-stage2" -o T3389 T3389.hs -dco...In the `nightly-i386-linux-deb9` job the `hpc`, `profasm`, and `profthreaded` ways all fail with:
```
=====> T3389(profasm) 1176 of 7141 [0, 6, 0]
cd "driver/T3389.run" && "/builds/ghc/ghc/inplace/bin/ghc-stage2" -o T3389 T3389.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto <
Compile failed (exit code 1) errors were:
[1 of 1] Compiling Main ( T3389.hs, T3389.o )
In file included from /usr/include/math.h:472:0: error:
0,
from /builds/ghc/ghc/includes/Stg.h:77,
from /builds/ghc/ghc/includes/Rts.h:29,
from /tmp/ghc21915_0/ghc_5.c:2:
/usr/include/i386-linux-gnu/bits/mathinline.h: In function ‘floor’:
/usr/include/i386-linux-gnu/bits/mathinline.h:746:1: error:
error: expected ‘:’ or ‘)’ before string constant
__inline_mathcodeNP (floor, __x, \
^
/usr/include/i386-linux-gnu/bits/mathinline.h: In function ‘floorf’:
/usr/include/i386-linux-gnu/bits/mathinline.h:746:1: error:
error: expected ‘:’ or ‘)’ before string constant
__inline_mathcodeNP (floor, __x, \
^
/usr/include/i386-linux-gnu/bits/mathinline.h: In function ‘floorl’:
/usr/include/i386-linux-gnu/bits/mathinline.h:746:1: error:
error: expected ‘:’ or ‘)’ before string constant
__inline_mathcodeNP (floor, __x, \
^
/usr/include/i386-linux-gnu/bits/mathinline.h: In function ‘ceil’:
/usr/include/i386-linux-gnu/bits/mathinline.h:764:1: error:
error: expected ‘:’ or ‘)’ before string constant
__inline_mathcodeNP (ceil, __x, \
^
/usr/include/i386-linux-gnu/bits/mathinline.h: In function ‘ceilf’:
/usr/include/i386-linux-gnu/bits/mathinline.h:764:1: error:
error: expected ‘:’ or ‘)’ before string constant
__inline_mathcodeNP (ceil, __x, \
^
/usr/include/i386-linux-gnu/bits/mathinline.h: In function ‘ceill’:
/usr/include/i386-linux-gnu/bits/mathinline.h:764:1: error:
error: expected ‘:’ or ‘)’ before string constant
__inline_mathcodeNP (ceil, __x, \
^
`cc' failed in phase `C Compiler'. (Exit code: 1)
*** unexpected failure for T3389(profasm)
```8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17257Program gets stuck at 100% CPU usage on a Mac2020-01-21T14:17:17ZAlex DProgram gets stuck at 100% CPU usage on a Mac## Summary
This program gets stuck at 100% CPU even when idling after it finished its work.
The program is just posting messages to the queue. (You need to have RabbitMQ running).
The problem seems to arise when you have a sufficiently ...## Summary
This program gets stuck at 100% CPU even when idling after it finished its work.
The program is just posting messages to the queue. (You need to have RabbitMQ running).
The problem seems to arise when you have a sufficiently large message payload. It seems to always be good with 1 MB, and always bad with 2 MB. In between (such as 1.5 MB) it is sometimes good and sometimes bad -- so there isn't a simple byte threshold where the problem starts.
```
module Lib
( someFunc
) where
import Data.Monoid ((<>))
import Data.Word (Word8)
-- import qualified MyNetwork.AMQP as AMQP <-- a copy of the AMQP code with tracing added
import qualified Network.AMQP as AMQP
import qualified Data.ByteString.Lazy as LBS
someFunc :: IO ()
someFunc = do
putText "Starting"
conn <- AMQP.openConnection''
AMQP.defaultConnectionOpts
{ AMQP.coServers = [("queue.service", 5672)]
, AMQP.coVHost = "/"
, AMQP.coAuth = [AMQP.plain "indicee" "indicee"]
, AMQP.coHeartbeatDelay = Just 10
}
putText "RabbitMP Connection established"
chan <- AMQP.openChannel conn
putText "Channel opened"
let msgContent =
AMQP.newMsg { AMQP.msgBody =
-- LBS.replicate (1024 * 1) (fromIntegral 55) -- <-- This is Ok
LBS.replicate (1024 * 1024 * 5) (55 :: Word8) -- <-- This causes CPU to get stuck at 100%
, AMQP.msgDeliveryMode = Just AMQP.Persistent
}
let routingKey = "Test.Test"
putText "Starting publish"
res <- AMQP.publishMsg chan "workResultExchange" routingKey msgContent
putText $ "Finished publish: result = " <> show res
putText "<press Enter to finish>"
_ <- getLine -- wait for keypress
AMQP.closeConnection conn
putText "connection closed"
putText "DONE"
putText = putStrLn
```
**Note that this issue is only reproducible on Mac systems. You will also need to have RabbitMQ running**
I also attached process snapshot.
[largemsgtest_process_snap](/uploads/2e45cd26c6196d0614fe4d7df90b39ad/largemsgtest_process_snap)
## Steps to reproduce
You need `stack` (sorry!)
1. `git clone https://github.com/nineonine/large_msg_test`
2. `stack build`
3. `stack exec largemsgtest-exe `
4. Observe that the program gets stuck at 100% CPU
## Expected behavior
CPU usage is reasonable.
## Environment
* GHC version used: 8.4.4
Optional:
* Operating System: Mac OS X 10.14.3 (18D109)
* System Architecture:8.10.2Alex DAlex Dhttps://gitlab.haskell.org/ghc/ghc/-/issues/17259Investigations into FastString interning2023-08-02T14:04:10ZMatthew PickeringInvestigations into FastString interning@DanielG and myself were wondering how much interning actually mattered when it came to `FastString`. In order to achieve that I instrumented the compiler to print out a `FastString` every time there was a cache hit in the `FastStringTab...@DanielG and myself were wondering how much interning actually mattered when it came to `FastString`. In order to achieve that I instrumented the compiler to print out a `FastString` every time there was a cache hit in the `FastStringTable`.
Then I compiled `Cabal` and discovered the following:8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17269T13615 fails in unrelated MRs2020-01-21T14:15:36ZSebastian GrafT13615 fails in unrelated MRsCurrently, `T13615` consistently fails for both !1828 (which fixes a bug in the rule matcher) and !1830 (which just adds some test cases and doesn't touch the compiler *at all*). [Example job 1](https://gitlab.haskell.org/ghc/ghc/-/jobs/...Currently, `T13615` consistently fails for both !1828 (which fixes a bug in the rule matcher) and !1830 (which just adds some test cases and doesn't touch the compiler *at all*). [Example job 1](https://gitlab.haskell.org/ghc/ghc/-/jobs/166384), [Example job 2](https://gitlab.haskell.org/ghc/ghc/-/jobs/166305).
- It only affects validate-x86_64-linux-deb9-debug, probably because the particular configuration isn't run in the other CI flavors
- In both cases the error is
```
Wrong exit code for T13615(threaded1)(expected 0 , actual 139 )
Stderr ( T13615 ):
Segmentation fault (core dumped)
```
Not sure what's happening there.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17274Fuse "reverse"2020-01-21T14:17:18ZTobias DeckingFuse "reverse"Going through `GHC/List.hs` in `base`, I've noticed that `reverse` does not have any fusion rules at all.
Although the version of the language report is a good consumer, it is currently unused, AFAIK because of previous versions of ghc h...Going through `GHC/List.hs` in `base`, I've noticed that `reverse` does not have any fusion rules at all.
Although the version of the language report is a good consumer, it is currently unused, AFAIK because of previous versions of ghc having
difficulities optimizing `foldl`. This changed however, and it was trivial to make it a good producer aswell.
Before i submit a patch however, I want to have this issue recorded and give everyone a chance to voice anything related.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17277Inconsistent behaviour of StandaloneKindSignatures with type families which a...2020-04-15T15:28:19Zsheafsam.derbyshire@gmail.comInconsistent behaviour of StandaloneKindSignatures with type families which are not given standalone kind signaturesTurning on `StandaloneKindSignatures` stops the following program from typechecking:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE S...Turning on `StandaloneKindSignatures` stops the following program from typechecking:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE StandaloneKindSignatures #-}
{-# LANGUAGE TypeFamilies #-}
data AB = A | B
data SAB (ab :: AB) where
SA :: SAB 'A
SB :: SAB 'B
--type SingAB :: forall (ab :: AB) -> SAB ab
type family SingAB (ab :: AB) :: SAB ab where
SingAB A = 'SA
SingAB B = 'SB
```
```
saks.hs:15:12: error:
* Expected kind `SAB ab', but 'SA has kind `SAB 'A'
* In the type 'SA
In the type family declaration for `SingAB'
|
15 | SingAB A = 'SA
|
```
Uncommenting the standalone kind signature allows the program to typecheck.
When removing the equations for the type family `SingAB`, with or without the standalone kind signature, one has:
```haskell
> :set -fprint-explicit-foralls -fprint-explicit-kinds
> :kind! SingAB
SingAB :: forall (ab :: AB) -> SAB ab
= SingAB
```
So I'm not sure why the equations fail to typecheck without the standalone kind signature.
Similar behaviour also happens for the invisible equivalent:
```haskell
--type SingAB2 :: forall (ab :: AB). SAB ab
type family SingAB2 :: SAB ab where
SingAB2 = ( 'SA :: SAB 'A )
SingAB2 = ( 'SB :: SAB 'B )
```
```
saks.hs:21:15: error:
* Expected kind `SAB ab', but 'SA :: SAB 'A has kind `SAB 'A'
* In the type `('SA :: SAB 'A)'
In the type family declaration for `SingAB2'
|
21 | SingAB2 = ( 'SA :: SAB 'A )
| ^^^
```
Ditto for passing the type explicitly:
```haskell
--type SingAB3 :: forall (ab :: AB). Proxy ab -> SAB ab
type family SingAB3 ( px :: Proxy ab ) :: SAB ab where
SingAB3 ( _ :: Proxy 'A ) = 'SA
SingAB3 ( _ :: Proxy 'B ) = 'SB
```
With `StandaloneKindSignatures` enabled, this causes the following error:
```
saks.hs:28:13: error:
* Expected kind `Proxy @{AB} ab',
but `_ :: Proxy 'A' has kind `Proxy @{AB} 'A'
* In the first argument of `SingAB3', namely `(_ :: Proxy 'A)'
In the type family declaration for `SingAB3'
|
28 | SingAB3 ( _ :: Proxy 'A ) = 'SA
| ^^^^^^^
```
Either turning off `StandaloneKindSignatures`, or uncommenting the standalone kind signature, allows the program to typecheck.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17280Compact normal form block allocation can race with GC initialization2020-01-21T14:17:17ZBen GamariCompact normal form block allocation can race with GC initializationWhile looking at !1603 I stumbled upon the following data race:
```
==================
WARNING: ThreadSanitizer: data race (pid=9105)
Atomic read of size 8 at 0x7b5800000048 by thread T6:
#0 __tsan_atomic64_load <null> (libtsan.so....While looking at !1603 I stumbled upon the following data race:
```
==================
WARNING: ThreadSanitizer: data race (pid=9105)
Atomic read of size 8 at 0x7b5800000048 by thread T6:
#0 __tsan_atomic64_load <null> (libtsan.so.0+0x00000006130c)
#1 calcNeeded rts/sm/Storage.c:1294 (compact_mutable+0x00000075c945)
#2 scheduleDoGC rts/Schedule.c:1549 (compact_mutable+0x00000072f361)
#3 schedule rts/Schedule.c:255 (compact_mutable+0x000000731722)
#4 scheduleWorker rts/Schedule.c:2576 (compact_mutable+0x000000733dce)
#5 workerStart rts/Task.c:445 (compact_mutable+0x00000073a9e5)
#6 <null> <null> (libtsan.so.0+0x000000028d5b)
Previous write of size 8 at 0x7b5800000048 by main thread (mutexes: write M16):
#0 compactAllocateBlockInternal rts/sm/CNF.c:209 (compact_mutable+0x000000780661)
#1 compactNew rts/sm/CNF.c:372 (compact_mutable+0x000000780965)
#2 stg_compactNewzh <null> (compact_mutable+0x000000761ceb)
#3 scheduleWaitThread rts/Schedule.c:2559 (compact_mutable+0x000000733d5d)
#4 rts_evalLazyIO rts/RtsAPI.c:530 (compact_mutable+0x00000077b681)
#5 hs_main rts/RtsMain.c:72 (compact_mutable+0x00000072b3e5)
#6 main <null> (compact_mutable+0x000000412da5)
Location is heap block of size 768 at 0x7b5800000000 allocated by main thread:
#0 malloc <null> (libtsan.so.0+0x00000002b251)
#1 stgMallocBytes rts/RtsUtils.c:64 (compact_mutable+0x00000072c63b)
#2 initStorage rts/sm/Storage.c:154 (compact_mutable+0x000000759b40)
#3 hs_init_ghc rts/RtsStartup.c:245 (compact_mutable+0x00000072c210)
#4 hs_main rts/RtsMain.c:57 (compact_mutable+0x00000072b3bb)
#5 main <null> (compact_mutable+0x000000412da5)
Mutex M16 (0x0000009127c0) created at:
#0 pthread_mutex_init <null> (libtsan.so.0+0x00000002c81e)
#1 initMutex rts/posix/OSThreads.c:170 (compact_mutable+0x00000075f937)
#2 initStorage rts/sm/Storage.c:148 (compact_mutable+0x000000759b0b)
#3 hs_init_ghc rts/RtsStartup.c:245 (compact_mutable+0x00000072c210)
#4 hs_main rts/RtsMain.c:57 (compact_mutable+0x00000072b3bb)
#5 main <null> (compact_mutable+0x000000412da5)
Thread T6 (tid=9112, running) created by thread T5 at:
#0 pthread_create <null> (libtsan.so.0+0x00000002c010)
#1 createOSThread rts/posix/OSThreads.c:137 (compact_mutable+0x00000075f8af)
#2 startWorkerTask rts/Task.c:497 (compact_mutable+0x00000073b3fa)
#3 releaseCapability_ rts/Capability.c:567 (compact_mutable+0x000000725367)
#4 suspendThread rts/Schedule.c:2424 (compact_mutable+0x0000007335b4)
#5 <null> <null> (compact_mutable+0x00000068e541)
#6 scheduleWorker rts/Schedule.c:2576 (compact_mutable+0x000000733dce)
#7 workerStart rts/Task.c:445 (compact_mutable+0x00000073a9e5)
#8 <null> <null> (libtsan.so.0+0x000000028d5b)
SUMMARY: ThreadSanitizer: data race (/nix/store/c7hj2bk4aqgpb3q0h5xhq7lag0lq3jm7-gcc-7.4.0-lib/lib/libtsan.so.0+0x6130c) in __tsan_atomic64_load
```
`compactAllocateBlockInternal` updates `generation->n_compact_blocks` while holding `SM_LOCK` yet `calcNeeded` doesn't bother to take `SM_LOCK` itself.
Arguably this isn't the end of the world resulting in only a slight change in GC timing.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17282Data race in compact_gc2020-01-21T14:17:18ZBen GamariData race in compact_gcWhile looking at !1603 I found the following data race triggered by the `compact_gc` test in the `threaded2` way:
```
==================
WARNING: ThreadSanitizer: data race (pid=29004)
Atomic read of size 2 at 0x7ee5c5700168 by main th...While looking at !1603 I found the following data race triggered by the `compact_gc` test in the `threaded2` way:
```
==================
WARNING: ThreadSanitizer: data race (pid=29004)
Atomic read of size 2 at 0x7ee5c5700168 by main thread (mutexes: write M16, write M28):
#0 __tsan_atomic16_load <null> (libtsan.so.0+0x000000060eec)
#1 evacuate rts/sm/Evac.c:637 (compact_gc+0x000000411982)
#2 evacuate_hash_entry rts/sm/Scav.c:165 (compact_gc+0x00000087453e)
#3 mapHashTable rts/Hash.c:394 (compact_gc+0x000000845e27)
#4 scavenge_compact rts/sm/Scav.c:182 (compact_gc+0x000000875037)
#5 scavenge_one rts/sm/Scav.c:1551 (compact_gc+0x000000875037)
#6 scavenge_large rts/sm/Scav.c:2008 (compact_gc+0x000000876afa)
#7 scavenge_find_work rts/sm/Scav.c:2068 (compact_gc+0x000000876afa)
#8 scavenge_loop rts/sm/Scav.c:2137 (compact_gc+0x000000876afa)
#9 scavenge_until_all_done rts/sm/GC.c:1112 (compact_gc+0x00000086a4fb)
#10 GarbageCollect rts/sm/GC.c:438 (compact_gc+0x00000086bc31)
#11 scheduleDoGC rts/Schedule.c:1814 (compact_gc+0x00000084db15)
#12 schedule rts/Schedule.c:552 (compact_gc+0x00000084eea7)
#13 scheduleWaitThread rts/Schedule.c:2559 (compact_gc+0x000000851b8d)
#14 rts_evalLazyIO rts/RtsAPI.c:530 (compact_gc+0x0000008991d1)
#15 hs_main rts/RtsMain.c:72 (compact_gc+0x000000849215)
#16 main <null> (compact_gc+0x000000414a41)
Previous write of size 8 at 0x7ee5c5700168 by thread T6:
#0 mmap <null> (libtsan.so.0+0x00000005d920)
#1 my_mmap rts/posix/OSMem.c:240 (compact_gc+0x00000087cae2)
#2 osCommitMemory rts/posix/OSMem.c:599 (compact_gc+0x00000087d345)
#3 getFreshMBlocks rts/sm/MBlock.c:205 (compact_gc+0x00000086fef3)
#4 getCommittedMBlocks rts/sm/MBlock.c:216 (compact_gc+0x00000086fef3)
#5 getMBlocks rts/sm/MBlock.c:580 (compact_gc+0x000000870218)
#6 alloc_mega_group rts/sm/BlockAlloc.c:378 (compact_gc+0x000000868be1)
#7 allocGroupOnNode rts/sm/BlockAlloc.c:429 (compact_gc+0x00000086970d)
#8 allocLargeChunkOnNode rts/sm/BlockAlloc.c:506 (compact_gc+0x000000869e32)
#9 allocBlocks_sync rts/sm/GCUtils.c:59 (compact_gc+0x00000086f8ee)
#10 alloc_todo_block rts/sm/GCUtils.c:329 (compact_gc+0x00000086f8ee)
#11 todo_block_full rts/sm/GCUtils.c:298 (compact_gc+0x00000086fc5d)
#12 alloc_for_copy rts/sm/Evac.c:80 (compact_gc+0x00000040e3f5)
#13 copy_tag_nolock rts/sm/Evac.c:157 (compact_gc+0x00000040e3f5)
#14 evacuate rts/sm/Evac.c:706 (compact_gc+0x00000040e3f5)
#15 scavenge_block rts/sm/Scav.c:496 (compact_gc+0x000000409024)
#16 scavenge_find_work rts/sm/Scav.c:2061 (compact_gc+0x0000008768e7)
#17 scavenge_loop rts/sm/Scav.c:2137 (compact_gc+0x0000008768e7)
#18 scavenge_until_all_done rts/sm/GC.c:1112 (compact_gc+0x00000086a4fb)
#19 gcWorkerThread rts/sm/GC.c:1185 (compact_gc+0x00000086e368)
#20 yieldCapability rts/Capability.c:904 (compact_gc+0x000000843a65)
#21 scheduleYield rts/Schedule.c:681 (compact_gc+0x00000084f452)
#22 schedule rts/Schedule.c:295 (compact_gc+0x00000084f452)
#23 scheduleWorker rts/Schedule.c:2576 (compact_gc+0x000000851bfe)
#24 workerStart rts/Task.c:445 (compact_gc+0x000000858815)
#25 <null> <null> (libtsan.so.0+0x000000028d5b)
Mutex M16 (0x000000a530c0) created at:
#0 pthread_mutex_init <null> (libtsan.so.0+0x00000002c81e)
#1 initMutex rts/posix/OSThreads.c:170 (compact_gc+0x00000087d777)
#2 initStorage rts/sm/Storage.c:148 (compact_gc+0x00000087791b)
#3 hs_init_ghc rts/RtsStartup.c:245 (compact_gc+0x00000084a040)
#4 hs_main rts/RtsMain.c:57 (compact_gc+0x0000008491eb)
#5 main <null> (compact_gc+0x000000414a41)
Mutex M28 (0x000000a52320) created at:
#0 pthread_mutex_init <null> (libtsan.so.0+0x00000002c81e)
#1 initMutex rts/posix/OSThreads.c:170 (compact_gc+0x00000087d777)
#2 initStablePtrTable rts/StablePtr.c:162 (compact_gc+0x0000008538c1)
#3 initStablePtrTable rts/StablePtr.c:155 (compact_gc+0x0000008539b4)
#4 hs_init_ghc rts/RtsStartup.c:248 (compact_gc+0x00000084a045)
#5 hs_main rts/RtsMain.c:57 (compact_gc+0x0000008491eb)
#6 main <null> (compact_gc+0x000000414a41)
Thread T6 (tid=29011, running) created by thread T4 at:
#0 pthread_create <null> (libtsan.so.0+0x00000002c010)
#1 createOSThread rts/posix/OSThreads.c:137 (compact_gc+0x00000087d6ef)
#2 startWorkerTask rts/Task.c:497 (compact_gc+0x00000085922a)
#3 releaseCapability_ rts/Capability.c:567 (compact_gc+0x000000843197)
#4 suspendThread rts/Schedule.c:2424 (compact_gc+0x0000008513e4)
#5 <null> <null> (compact_gc+0x0000007ad139)
#6 scheduleWorker rts/Schedule.c:2576 (compact_gc+0x000000851bfe)
#7 workerStart rts/Task.c:445 (compact_gc+0x000000858815)
#8 <null> <null> (libtsan.so.0+0x000000028d5b)
SUMMARY: ThreadSanitizer: data race (/nix/store/c7hj2bk4aqgpb3q0h5xhq7lag0lq3jm7-gcc-7.4.0-lib/lib/libtsan.so.0+0x60eec) in __tsan_atomic16_load
```
The load in question in `evacuate` is:
```c
StgClosure *e = (StgClosure*)UN_FORWARDING_PTR(info);
RELAXED_STORE(p, TAG_CLOSURE(tag,e));
if (gen_no < gct->evac_gen_no) { // optimisation
if (RELAXED_LOAD(&Bdescr((P_)e)->gen_no) // <===== this, I think
< gct->evac_gen_no) {
gct->failed_to_evac = true;
TICK_GC_FAILED_PROMOTION();
}
}
return;
```
Given that I only see this in `compact_gc`, I suspect this is a bug in the CNF compactor which fails to initialize block descriptors correctly.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17287Hadrian rebuilds all RTS dependency files when even a single file is changed2020-01-21T14:58:51ZBen GamariHadrian rebuilds all RTS dependency files when even a single file is changedRunning `hadrian/build.cabal.sh`, then touching a RTS source file (e.g. `rts/sm/GC.c`), then running `hadrian/build.cabal.sh` again results in the `FindCDependencies` jobs being rebuilt for all RTS source files. This is unnecessary.Running `hadrian/build.cabal.sh`, then touching a RTS source file (e.g. `rts/sm/GC.c`), then running `hadrian/build.cabal.sh` again results in the `FindCDependencies` jobs being rebuilt for all RTS source files. This is unnecessary.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17288Data race during RTS shutdown2020-01-21T14:17:18ZBen GamariData race during RTS shutdownWhile looking at !1603:
```
==================
==================
WARNING: ThreadSanitizer: data race (pid=4596)
Write of size 8 at 0x00000090d6e8 by thread T6 (mutexes: write M16):
#0 stat_endGC rts/Stats.c:400 (T10296b+0x0000007...While looking at !1603:
```
==================
==================
WARNING: ThreadSanitizer: data race (pid=4596)
Write of size 8 at 0x00000090d6e8 by thread T6 (mutexes: write M16):
#0 stat_endGC rts/Stats.c:400 (T10296b+0x000000734e22)
#1 GarbageCollect rts/sm/GC.c:883 (T10296b+0x00000074cacb)
#2 scheduleDoGC rts/Schedule.c:1810 (T10296b+0x00000072d5e5)
#3 schedule rts/Schedule.c:552 (T10296b+0x00000072e977)
#4 scheduleWorker rts/Schedule.c:2572 (T10296b+0x0000007316be)
#5 workerStart rts/Task.c:445 (T10296b+0x0000007382d5)
#6 <null> <null> (libtsan.so.0+0x000000028d5b)
Previous read of size 8 at 0x00000090d6e8 by main thread:
#0 stat_startExit rts/Stats.c:273 (T10296b+0x000000734663)
#1 hs_exit_ rts/RtsStartup.c:380 (T10296b+0x000000729719)
#2 shutdownHaskellAndExit rts/RtsStartup.c:562 (T10296b+0x000000729f65)
#3 hs_main rts/RtsMain.c:99 (T10296b+0x000000728d7c)
#4 main <null> (T10296b+0x000000412f71)
Location is global 'stats' of size 320 at 0x00000090d660 (T10296b+0x00000090d6e8)
Mutex M16 (0x0000009103c0) created at:
#0 pthread_mutex_init <null> (libtsan.so.0+0x00000002c81e)
#1 initMutex rts/posix/OSThreads.c:170 (T10296b+0x00000075d2b7)
#2 initStorage rts/sm/Storage.c:148 (T10296b+0x0000007573fb)
#3 hs_init_ghc rts/RtsStartup.c:245 (T10296b+0x000000729b60)
#4 hs_main rts/RtsMain.c:57 (T10296b+0x000000728d0b)
#5 main <null> (T10296b+0x000000412f71)
Thread T6 (tid=4603, running) created by thread T4 at:
#0 pthread_create <null> (libtsan.so.0+0x00000002c010)
#1 createOSThread rts/posix/OSThreads.c:137 (T10296b+0x00000075d22f)
#2 startWorkerTask rts/Task.c:497 (T10296b+0x000000738cea)
#3 releaseCapability_ rts/Capability.c:568 (T10296b+0x000000722cf7)
#4 suspendThread rts/Schedule.c:2420 (T10296b+0x000000730ea4)
#5 <null> <null> (T10296b+0x00000068bf11)
#6 scheduleWorker rts/Schedule.c:2572 (T10296b+0x0000007316be)
#7 workerStart rts/Task.c:445 (T10296b+0x0000007382d5)
#8 <null> <null> (libtsan.so.0+0x000000028d5b)
SUMMARY: ThreadSanitizer: data race rts/Stats.c:400 in stat_endGC
```8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17290`ForeignPtr` should be strict in `ForeignPtrContents`2020-09-11T16:58:46Zedsko@edsko.net`ForeignPtr` should be strict in `ForeignPtrContents`Right now `ForeignPtr` is defined as
```haskell
data ForeignPtr a = ForeignPtr Addr# ForeignPtrContents
data ForeignPtrContents
= PlainForeignPtr !(IORef Finalizers)
| MallocPtr (MutableByteArray# RealWorld) !(IORef Finalizers...Right now `ForeignPtr` is defined as
```haskell
data ForeignPtr a = ForeignPtr Addr# ForeignPtrContents
data ForeignPtrContents
= PlainForeignPtr !(IORef Finalizers)
| MallocPtr (MutableByteArray# RealWorld) !(IORef Finalizers)
| PlainPtr (MutableByteArray# RealWorld)
```
`ForeignPtrContents` is strict in all its fields, but `ForeignPtr` is lazy in the `ForeignPtrContents`. That should probably not be the case (or, if it should, we should document why).8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17305Data family instances aren't eta-reduced correctly2020-12-14T13:50:30ZRyan ScottData family instances aren't eta-reduced correctly(I originally discovered this when debugging #17296/!1877, but this doesn't rely on !1877 to reproduce.)
Take this code:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
impo...(I originally discovered this when debugging #17296/!1877, but this doesn't rely on !1877 to reproduce.)
Take this code:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Kind
import Language.Haskell.TH hiding (Type)
import System.IO
data family Foo a
data instance Foo :: Type -> Type where
MkFoo :: Foo a
$(do i <- reify ''Foo
runIO $ hPutStrLn stderr $ pprint i
pure [])
```
And compile it with a `devel2`-flavoured compiler. (I'm on commit d0924b153b093a925c9e721f2540f3dfd6c278ae.) You'll get the following panic:
```
$ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o, Bug.dyn_o )
Bug.hs:1:1: error:
Exception when trying to run compile-time code:
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.9.0.20191003:
zipEqual: unequal lists:zipTyEnv
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Code: do i <- reify ''Foo
runIO $ hPutStrLn stderr $ pprint i
pure []
|
1 | {-# LANGUAGE GADTs #-}
| ^
```8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17317Compiling Network.AWS.SWF.Types.Product in amazonka-swf uses more than 4G of ...2021-03-29T09:26:04ZJohn KyCompiling Network.AWS.SWF.Types.Product in amazonka-swf uses more than 4G of memory on Ubuntu-18.04## Summary
Write a brief description of the issue.
## Steps to reproduce
This is reproducible in this project at the commit:
https://github.com/arbor/antiope/commit/e3d7841912052c8a48fda0685b1ab41384e6faa9
Using the command:
```
ca...## Summary
Write a brief description of the issue.
## Steps to reproduce
This is reproducible in this project at the commit:
https://github.com/arbor/antiope/commit/e3d7841912052c8a48fda0685b1ab41384e6faa9
Using the command:
```
cabal v2-build all $_BUILD_ENABLE_TESTS_FLAG $_BUILD_ENABLE_BENCHMARKS_FLAG -j1
```
As shown in this failed Circle CI build:
https://circleci.com/gh/arbor/antiope/998
## Expected behavior
It is expected that a single module should not take this much memory to compile. Previous versions of GHC did not have this problem.
## Environment
* GHC version used: `ghc-8.8.1`
```
$ uname -a
Darwin INTLKyMac.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
```8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17483Yet another mysterious Windows failure2020-01-21T14:16:37ZBen GamariYet another mysterious Windows failureI am occasionally seeing Windows tests fail with errors of the form (for various tests):
```
Traceback (most recent call last):
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 973, in test_commo...I am occasionally seeing Windows tests fail with errors of the form (for various tests):
```
Traceback (most recent call last):
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 973, in test_common_work
do_test(name, way, func, args, files)
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 1071, in do_test
result = func(*[name,way] + args)
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 1199, in compile_fail
return do_compile( name, way, True, None, [], extra_hc_opts )
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 1252, in do_compile
expected_stderr_file = find_expected_file(name, 'stderr')
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 2353, in find_expected_file
if in_srcdir(f).exists():
File "/usr/lib/python3.7/pathlib.py", line 1329, in exists
self.stat()
File "/usr/lib/python3.7/pathlib.py", line 1151, in stat
return self._accessor.stat(self)
OSError: [Errno 0] Error: '/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/tests/typecheck/should_fail/tcfail161.stderr-mingw32'
```
Note the `Errno 0`; this is just bizarre given that `tcfail161.sterr-mingw32` doesn't even exist.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17508Alpine bindist segmentation faults2024-03-21T16:04:47ZBen GamariAlpine bindist segmentation faultsThe 8.10.1-alpha1 Alpine bindist appears to generate invalid code. For instance, https://gitlab.haskell.org/ghc/ghc/-/jobs/209099.
The crash appears to occur in GMP.The 8.10.1-alpha1 Alpine bindist appears to generate invalid code. For instance, https://gitlab.haskell.org/ghc/ghc/-/jobs/209099.
The crash appears to occur in GMP.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17563Validity check quantified constraints2021-11-17T21:20:04ZRichard Eisenbergrae@richarde.devValidity check quantified constraintsThis module is accepted:
```hs
{-# LANGUAGE QuantifiedConstraints #-}
module Bug2 where
blah :: (forall a. a b ~ a c) => b -> c
blah = undefined
```
But it shouldn't be: it uses `~` with neither `GADTs` nor `TypeFamilies` enabled.This module is accepted:
```hs
{-# LANGUAGE QuantifiedConstraints #-}
module Bug2 where
blah :: (forall a. a b ~ a c) => b -> c
blah = undefined
```
But it shouldn't be: it uses `~` with neither `GADTs` nor `TypeFamilies` enabled.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17583No -pgmcxx option to correspond with -optcxx2022-07-11T23:15:09ZMerijn VerstraatenNo -pgmcxx option to correspond with -optcxx## Summary
GHC 8.10 now stores C++ compiler flags in its settings and supports `-optcxx` to pass other flags, however the configure script doesn't detect or let users specify which C++ compiler to use, and there is also no corresponding...## Summary
GHC 8.10 now stores C++ compiler flags in its settings and supports `-optcxx` to pass other flags, however the configure script doesn't detect or let users specify which C++ compiler to use, and there is also no corresponding `-pgmcxx` option to override the C++ compiler used.
Lacking this configure option and flag makes it more complicated to implement better C++ support in Cabal/cabal-install.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17634Hadrian's hadrian.settings autocompletion returns far too many results2020-01-21T14:16:37ZBen GamariHadrian's hadrian.settings autocompletion returns far too many resultsCurrently `hadrian autocomplete --complete-setting=stage1.` will return over 500 keys since it returns every possible completion matching the prefix `stage1.`. This is not particularly helpful, akin to `ls /<tab>` listing the entire cont...Currently `hadrian autocomplete --complete-setting=stage1.` will return over 500 keys since it returns every possible completion matching the prefix `stage1.`. This is not particularly helpful, akin to `ls /<tab>` listing the entire contents of your filesystem.
It should rather only complete until the next dot (unless the match is unique).8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17660Performance regression in bytestring from 8.8 to 8.102021-07-14T16:17:36ZSimon JakobiPerformance regression in bytestring from 8.8 to 8.10## Summary
Many of the benchmarks in `bytestring`'s `bench-bytestring-builder` benchmark suite run much slower with 8.10.1-alpha2 than with 8.8.
Here are the first lines of the benchmark diff (produced with [`criterion-compare`](https:...## Summary
Many of the benchmarks in `bytestring`'s `bench-bytestring-builder` benchmark suite run much slower with 8.10.1-alpha2 than with 8.8.
Here are the first lines of the benchmark diff (produced with [`criterion-compare`](https://github.com/bgamari/criterion-compare)), sorted by significance:
![image](/uploads/516ac79ca826aa9ee23bf8b2eb830f4e/image.png)
[Full diff](/uploads/5d96ce2cce29f7038379515e6bf3450a/comparison.html)
Some of the results may be noisy, but at that magnitude it shouldn't matter much.
I also benchmarked with HEAD (923a127205dd60147453f4420614efd1be29f070), and got even worse results, but that might have been because that `ghc` was built with `--flavour=Quick`.
Note that the `substrings/*` benchmarks measure [the `findSubstrings` function](https://github.com/haskell/bytestring/blob/95fe6bdf13c9cc86c1c880164f7844d61d989574/Data/ByteString.hs#L1416-L1435), which is deprecated. So the performance of the other benchmarks is actually more important.
## Steps to reproduce
1. Clone the branch from [this PR](https://github.com/haskell/bytestring/pull/196) which fixes building the benchmarks.
2. `cd bench`
3. `cabal -O2 run bench-bytestring-builder`
## Expected behavior
The performance of these benchmarks should be no worse with 8.10 than with 8.8.
## Environment
* GHC versions used: 8.8.1 and 8.10.1-alpha2, both from hvr's PPA.
* Operating System: Linux
* System Architecture: `x86_64`8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17693Improve and document atomicModifyMutVar2#2023-02-20T09:32:37ZSimon Peyton JonesImprove and document atomicModifyMutVar2#The primop `atomicModifyMutVar2#` is ill-documented, and its type
is extremely odd. Its declared type (in `primops.txt.pp` is
```
MutVar# s a -> (a -> c) -> State# s -> (# State# s, a, c #)
```
but that's a lie. Its real type is mor...The primop `atomicModifyMutVar2#` is ill-documented, and its type
is extremely odd. Its declared type (in `primops.txt.pp` is
```
MutVar# s a -> (a -> c) -> State# s -> (# State# s, a, c #)
```
but that's a lie. Its real type is more like this
```
MutVar# s a -> (a -> (a,b)) -> State# s -> (# State# s, a, (a, b) #)
```
And there is other tricky and entirely un-documented stuff about it. It all comes from an accepted [GHC Proposal 149: replace atomicModifyMutVar# primop](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0149-atomicModifyMutVar.rst), but much is unclear about it (to me anyway).
These topics are discussed in [this email thread](https://mail.haskell.org/pipermail/ghc-devs/2019-October/018223.html).
The thread ends up saying: I propose:
* To give `atomicModifyMutVar2#` its proper type, with a pair, as in the proposal.
* To do that, fiddle with `genprimopcode`, to allow it to parse tuples as well as unboxed tuples; not hard.
* This would disallow all this stuff about “any type that has a first field looking like a”, restricting to pairs alone. This didn’t form part of the proposal, and was never documented.
* Add a bit more clarity to the documentation, so it’d clear what must be forced.
This ticket is to record this task.
I've even done quite a bit of the work: see branch `wip/T17693`.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17956GHC 8.10.1 bundles an older version of text than 8.8.32020-10-06T15:00:32ZRyan ScottGHC 8.10.1 bundles an older version of text than 8.8.3```
$ /opt/ghc/8.8.3/bin/ghc-pkg list
/opt/ghc/8.8.3/lib/ghc-8.8.3/package.conf.d
...
text-1.2.4.0
...
$ ./ghc-8.10.1/bin/ghc-pkg list
/home/rgscott/Software/ghc-8.10.1/lib/ghc-8.10.1/package.conf.d
...
text-1.2.3.2
...```
$ /opt/ghc/8.8.3/bin/ghc-pkg list
/opt/ghc/8.8.3/lib/ghc-8.8.3/package.conf.d
...
text-1.2.4.0
...
$ ./ghc-8.10.1/bin/ghc-pkg list
/home/rgscott/Software/ghc-8.10.1/lib/ghc-8.10.1/package.conf.d
...
text-1.2.3.2
...
```
I doubt this was intended.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/18217Unable build 8.10.1 on s390x2020-07-23T15:33:05Zmimi.vxUnable build 8.10.1 on s390x## Summary
On s390x build stops with:
```
[ 4466s] "inplace/bin/ghc-stage1" -optc-Wall -optc-Wno-return-type -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpo...## Summary
On s390x build stops with:
```
[ 4466s] "inplace/bin/ghc-stage1" -optc-Wall -optc-Wno-return-type -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wno-aggregate-return -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Iincludes/dist-install/build -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_thr\" -optc-ffunction-sections -optc-fdata-sections -static -optc-DTHREADED_RTS -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.thr_o
[ 4466s] In file included from includes/Stg.h:318,
[ 4466s]
[ 4466s] from rts/StgCRun.c:45:0: error:
[ 4466s]
[ 4466s] includes/stg/Regs.h:442:2: error:
[ 4466s] error: #error BaseReg must be in a register for THREADED_RTS
[ 4466s] 442 | #error BaseReg must be in a register for THREADED_RTS
[ 4466s] | ^~~~~
[ 4466s] |
[ 4466s] 442 | #error BaseReg must be in a register for THREADED_RTS
[ 4466s] | ^
[ 4466s] In file included from includes/Stg.h:318,
[ 4466s]
[ 4466s] from rts/StgCRun.c:45:0: error:
[ 4466s] rts/StgCRun.c: In function 'StgRun':
[ 4466s]
[ 4466s] includes/stg/Regs.h:444:46: error:
[ 4466s] error: 'MainCapability' undeclared (first use in this function); did you mean 'markCapability'?
[ 4466s] 444 | #define BaseReg (&((struct PartCapability_ *)MainCapability)->r)
[ 4466s] | ^~~~~~~~~~~~~~
[ 4466s] |
[ 4466s] 444 | #define BaseReg (&((struct PartCapability_ *)MainCapability)->r)
[ 4466s] | ^
[ 4466s]
[ 4466s] includes/stg/Regs.h:161:14: error:
[ 4466s] note: in expansion of macro 'BaseReg'
[ 4466s] 161 | # define R1 (BaseReg->rR1)
[ 4466s] | ^~~~~~~
[ 4466s] |
[ 4466s] 161 | # define R1 (BaseReg->rR1)
[ 4466s] | ^
[ 4466s]
[ 4466s] rts/StgCRun.c:83:27: error:
[ 4466s] note: in expansion of macro 'R1'
[ 4466s] 83 | return (StgRegTable *)R1.p;
[ 4466s] | ^~
[ 4466s] |
[ 4466s] 83 | return (StgRegTable *)R1.p;
[ 4466s] | ^
[ 4466s]
[ 4466s] includes/stg/Regs.h:444:46: error:
[ 4466s] note: each undeclared identifier is reported only once for each function it appears in
[ 4466s] 444 | #define BaseReg (&((struct PartCapability_ *)MainCapability)->r)
[ 4466s] | ^~~~~~~~~~~~~~
[ 4466s] |
[ 4466s] 444 | #define BaseReg (&((struct PartCapability_ *)MainCapability)->r)
[ 4466s] | ^
[ 4466s]
[ 4466s] includes/stg/Regs.h:161:14: error:
[ 4466s] note: in expansion of macro 'BaseReg'
[ 4466s] 161 | # define R1 (BaseReg->rR1)
[ 4466s] | ^~~~~~~
[ 4466s] |
[ 4466s] 161 | # define R1 (BaseReg->rR1)
[ 4466s] | ^
[ 4466s]
[ 4466s] rts/StgCRun.c:83:27: error:
[ 4466s] note: in expansion of macro 'R1'
[ 4466s] 83 | return (StgRegTable *)R1.p;
[ 4466s] | ^~
[ 4466s] |
[ 4466s] 83 | return (StgRegTable *)R1.p;
[ 4466s] | ^
[ 4466s] `cc' failed in phase `C Compiler'. (Exit code: 1)
[ 4466s] make[1]: *** [rts/ghc.mk:322: rts/dist/build/StgCRun.thr_o] Error 1
[ 4466s] make[1]: *** Waiting for unfinished jobs....
[ 4466s] make: *** [Makefile:128: all] Error 2
[ 4466s] error: Bad exit status from /var/tmp/rpm-tmp.J0wvxD (%build)
```
## Steps to reproduce
```
./configure
./make
```
## Expected behaviour
build ghc
## Environment
s390x
* GHC version used:
for bootstrapping 8.8.3
Optional:
* Operating System: openSUSE Tumbleweed zSystems
* System Architecture: s390x8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/18247-ddump-minimal-imports does not dump some pattern imports correctly2023-02-21T17:01:00Zjrp2014-ddump-minimal-imports does not dump some pattern imports correctly## Summary
The minimal imports generated by `-ddump-minimal-imports` are sometimes not correct.
For example, it generates `import Agda.Utils.List1 ( pattern (:|) )` correctly, but doesn't include the `pattern` keyword for `Def` in `imp...## Summary
The minimal imports generated by `-ddump-minimal-imports` are sometimes not correct.
For example, it generates `import Agda.Utils.List1 ( pattern (:|) )` correctly, but doesn't include the `pattern` keyword for `Def` in `import qualified Agda.Syntax.Abstract as A ( QName, NameToExpr(nameToExpr), Expr(Con), Def )`, where `Def` is defined in the `Agda.Syntax.Abstract` module as:
```haskell
-- | Pattern synonym for regular Def
pattern Def :: QName -> Expr
pattern Def x = Def' x NoSuffix
```
This limits the utility of the feature.
## Environment
* GHC version used: 8.10.1
* OS; MacOS Catalina8.10.2Alan ZimmermanAlan Zimmerman