GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-21T16:04:47Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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 Gamari