GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:13:54Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/1358debian package ghc6-doc should depend on haddock?2019-07-07T19:13:54Zfrederik@ofb.netdebian package ghc6-doc should depend on haddock?$ sudo apt-get install ghc6-doc
Reading package lists... Done
Building dependency tree... Done
ghc6-doc is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 59 not upgraded.
1 not fully installed or removed.
Need...$ sudo apt-get install ghc6-doc
Reading package lists... Done
Building dependency tree... Done
ghc6-doc is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 59 not upgraded.
1 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Setting up ghc6-doc (6.6.1-1) ...
/usr/lib/ghc6-doc/gen_contents_index: line 34: haddock: command not found
dpkg: error processing ghc6-doc (--configure):
subprocess post-installation script returned error exit status 127
Errors were encountered while processing:
ghc6-doc
E: Sub-process /usr/bin/dpkg returned an error code (1)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"debian package ghc6-doc should depend on haddock?","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"$ sudo apt-get install ghc6-doc\r\nReading package lists... Done\r\nBuilding dependency tree... Done\r\nghc6-doc is already the newest version.\r\n0 upgraded, 0 newly installed, 0 to remove and 59 not upgraded.\r\n1 not fully installed or removed.\r\nNeed to get 0B of archives.\r\nAfter unpacking 0B of additional disk space will be used.\r\nSetting up ghc6-doc (6.6.1-1) ...\r\n/usr/lib/ghc6-doc/gen_contents_index: line 34: haddock: command not found\r\ndpkg: error processing ghc6-doc (--configure):\r\n subprocess post-installation script returned error exit status 127\r\nErrors were encountered while processing:\r\n ghc6-doc\r\nE: Sub-process /usr/bin/dpkg returned an error code (1)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1359readline confusion building ghc6.6.1 on OS X2019-07-07T19:13:54Zhal@oz.netreadline confusion building ghc6.6.1 on OS XBecause of another software package, I had previously installed gnu readline 5.1 in /usr/local. In order to build ghc 6.6.1, I first installed the pre-built version of 6.6 and during that installation there was a message about replacing ...Because of another software package, I had previously installed gnu readline 5.1 in /usr/local. In order to build ghc 6.6.1, I first installed the pre-built version of 6.6 and during that installation there was a message about replacing the system readline as part of the install (alas, I forgot to write down the exact message). When I ran make after configuring 6.6.1, the haskell library readline function didn't compile, and the make aborted when a later step couldn't find readline to build the libraries.
I tried again with a freshly unpacked source directory but after reinstallng gnu's readline first, and the build appears to have completed successfuly this time.
So something isn't quite right in the way that readline is handled, either because 6.6 deleted something that it shouldn't have, or the build is very sensitive to where readline is and has problems if there is a copy in /usr/local, or some other reason.
Of course this is less important now that a pre-built 6.6.1 is available on the web site, but it would be nice to clean up if possible.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"readline confusion building ghc6.6.1 on OS X","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Because of another software package, I had previously installed gnu readline 5.1 in /usr/local. In order to build ghc 6.6.1, I first installed the pre-built version of 6.6 and during that installation there was a message about replacing the system readline as part of the install (alas, I forgot to write down the exact message). When I ran make after configuring 6.6.1, the haskell library readline function didn't compile, and the make aborted when a later step couldn't find readline to build the libraries. \r\n\r\nI tried again with a freshly unpacked source directory but after reinstallng gnu's readline first, and the build appears to have completed successfuly this time.\r\n\r\nSo something isn't quite right in the way that readline is handled, either because 6.6 deleted something that it shouldn't have, or the build is very sensitive to where readline is and has problems if there is a copy in /usr/local, or some other reason.\r\n\r\nOf course this is less important now that a pre-built 6.6.1 is available on the web site, but it would be nice to clean up if possible.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1360ghci :load and :add clear module context2019-07-07T19:13:53Zfrederik@ofb.netghci :load and :add clear module contextIf I add modules with a ":m" command, and then load a file with ":l" or add something with ":a", then the effect of the previous ":m" incantation seems do disappear, is this for a reason?
<details><summary>Trac metadata</summary>
| Tra...If I add modules with a ":m" command, and then load a file with ":l" or add something with ":a", then the effect of the previous ":m" incantation seems do disappear, is this for a reason?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ghci :load and :add clear module context","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"If I add modules with a \":m\" command, and then load a file with \":l\" or add something with \":a\", then the effect of the previous \":m\" incantation seems do disappear, is this for a reason?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1361When trying to run yi, it fails to compile main, and exits with an error2019-07-07T19:13:53ZguestWhen trying to run yi, it fails to compile main, and exits with an errorI am using ghc-6.6.1 installed in a non-standard location, and I just built yi-0.2 also for a non-standard location, and the first time I run it I get:
```
<interactive>:1:33:
Failed to load interface for `Yi':
Use -v to see a...I am using ghc-6.6.1 installed in a non-standard location, and I just built yi-0.2 also for a non-standard location, and the first time I run it I get:
```
<interactive>:1:33:
Failed to load interface for `Yi':
Use -v to see a list of the files searched for.
yi: panic! (the 'impossible' happened)
(GHC version 6.6.1 for i386-unknown-linux):
Could not compile Yi.main!
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The output from the configuration and build is:
```
$ runhaskell Setup.hs configure --prefix=/design/local/yi
Configuring yi-0.2...
configure: Dependency ghc>=6.6: using ghc-6.6.1
configure: Dependency base-any: using base-2.1.1
configure: Dependency mtl-any: using mtl-1.0.1
configure: Dependency regex-posix-any: using regex-posix-0.71
configure: Using install prefix: /design/local/yi
configure: Binaries installed in: /design/local/yi/bin
configure: Libraries installed in: /design/local/yi/lib/yi-0.2/ghc-6.6.1
configure: Private binaries installed in: /design/local/yi/libexec
configure: Data files installed in: /design/local/yi/share/yi-0.2
configure: Using compiler: /design/local/ghc-6.6.1/bin/ghc
configure: Compiler flavor: GHC
configure: Compiler version: 6.6.1
configure: Using package tool: /design/local/ghc-6.6.1/bin/ghc-pkg
configure: Using ar found on system at: /usr/bin/ar
configure: No haddock found
configure: No pfesetup found
configure: Using ranlib found on system at: /usr/bin/ranlib
configure: Using runghc found on system at: /design/local/ghc-6.6.1/bin/runghc
configure: No runhugs found
configure: No happy found
configure: No alex found
configure: Using hsc2hs: /design/local/ghc-6.6.1/bin/hsc2hs
configure: No c2hs found
configure: No cpphs found
configure: No greencard found
$ runhaskell Setup.hs build
Preprocessing executables for yi-0.2...
Building yi-0.2...
[1 of 4] Compiling Yi.Kernel ( Yi/Kernel.hs, dist/build/yi/yi-tmp/Yi/Kernel.o
)
[2 of 4] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/yi/yi-tmp/Yi/Debug.o )
[3 of 4] Compiling Yi.Boot ( Yi/Boot.hs, dist/build/yi/yi-tmp/Yi/Boot.o )
[4 of 4] Compiling Main ( Main.hs, dist/build/yi/yi-tmp/Main.o )
Linking dist/build/yi/yi ...
$ runhaskell Setup.hs install
Installing: /design/local/yi/lib/yi-0.2/ghc-6.6.1 & /design/local/yi/bin yi-0.2...
```
My machine is:
```
$ cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon Update 7)
$ uname -a
Linux carl 2.4.21-40.ELhugemem #1 SMP Thu Feb 2 22:14:10 EST 2006 i686 i686 i386 GNU/Linux
```
Let me know if there is any more info I can provide.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"When trying to run yi, it fails to compile main, and exits with an error","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am using ghc-6.6.1 installed in a non-standard location, and I just built yi-0.2 also for a non-standard location, and the first time I run it I get:\r\n{{{\r\n<interactive>:1:33:\r\n Failed to load interface for `Yi':\r\n Use -v to see a list of the files searched for.\r\nyi: panic! (the 'impossible' happened)\r\n (GHC version 6.6.1 for i386-unknown-linux):\r\n Could not compile Yi.main!\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe output from the configuration and build is:\r\n{{{\r\n$ runhaskell Setup.hs configure --prefix=/design/local/yi\r\nConfiguring yi-0.2...\r\nconfigure: Dependency ghc>=6.6: using ghc-6.6.1\r\nconfigure: Dependency base-any: using base-2.1.1\r\nconfigure: Dependency mtl-any: using mtl-1.0.1\r\nconfigure: Dependency regex-posix-any: using regex-posix-0.71\r\nconfigure: Using install prefix: /design/local/yi\r\nconfigure: Binaries installed in: /design/local/yi/bin\r\nconfigure: Libraries installed in: /design/local/yi/lib/yi-0.2/ghc-6.6.1\r\nconfigure: Private binaries installed in: /design/local/yi/libexec\r\nconfigure: Data files installed in: /design/local/yi/share/yi-0.2\r\nconfigure: Using compiler: /design/local/ghc-6.6.1/bin/ghc\r\nconfigure: Compiler flavor: GHC\r\nconfigure: Compiler version: 6.6.1\r\nconfigure: Using package tool: /design/local/ghc-6.6.1/bin/ghc-pkg\r\nconfigure: Using ar found on system at: /usr/bin/ar\r\nconfigure: No haddock found\r\nconfigure: No pfesetup found\r\nconfigure: Using ranlib found on system at: /usr/bin/ranlib\r\nconfigure: Using runghc found on system at: /design/local/ghc-6.6.1/bin/runghc\r\nconfigure: No runhugs found\r\nconfigure: No happy found\r\nconfigure: No alex found\r\nconfigure: Using hsc2hs: /design/local/ghc-6.6.1/bin/hsc2hs\r\nconfigure: No c2hs found\r\nconfigure: No cpphs found\r\nconfigure: No greencard found\r\n$ runhaskell Setup.hs build\r\nPreprocessing executables for yi-0.2...\r\nBuilding yi-0.2...\r\n[1 of 4] Compiling Yi.Kernel ( Yi/Kernel.hs, dist/build/yi/yi-tmp/Yi/Kernel.o\r\n )\r\n[2 of 4] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/yi/yi-tmp/Yi/Debug.o )\r\n[3 of 4] Compiling Yi.Boot ( Yi/Boot.hs, dist/build/yi/yi-tmp/Yi/Boot.o )\r\n[4 of 4] Compiling Main ( Main.hs, dist/build/yi/yi-tmp/Main.o )\r\nLinking dist/build/yi/yi ...\r\n$ runhaskell Setup.hs install\r\nInstalling: /design/local/yi/lib/yi-0.2/ghc-6.6.1 & /design/local/yi/bin yi-0.2...\r\n}}}\r\n\r\nMy machine is:\r\n{{{\r\n$ cat /etc/redhat-release\r\nRed Hat Enterprise Linux WS release 3 (Taroon Update 7)\r\n$ uname -a\r\nLinux carl 2.4.21-40.ELhugemem #1 SMP Thu Feb 2 22:14:10 EST 2006 i686 i686 i386 GNU/Linux\r\n}}}\r\n\r\nLet me know if there is any more info I can provide.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1362Fix PPC Mac OS X memory access problem in includes/SMP.h2019-07-07T19:13:53ZthorkilnaurFix PPC Mac OS X memory access problem in includes/SMP.hThe following session uses a recently pulled ghc HEAD which has been built with `-debug`:
```
$ gdb /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-fill-indent-20070506_1304/ghc/compiler/stage2/ghc-6.7.20070513
...
...The following session uses a recently pulled ghc HEAD which has been built with `-debug`:
```
$ gdb /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-fill-indent-20070506_1304/ghc/compiler/stage2/ghc-6.7.20070513
...
(gdb) run -B/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-fill-indent-20070506_1304/ghc
Starting program: /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-fill-indent-20070506_1304/ghc/compiler/stage2/ghc-6.7.20070513 -B/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-fill-indent-20070506_1304/ghc
Reading symbols for shared libraries ..+. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00cb2744
0x00d8f5e8 in xchg (p=0x2dff000, w=13313840) at ../includes/SMP.h:74
74 __asm__ __volatile__ (
(gdb) where
#0 0x00d8f5e8 in xchg (p=0x2dff000, w=13313840) at ../includes/SMP.h:74
#1 0x00d8f564 in lockClosure (p=0x2dff000) at ../includes/SMP.h:185
#2 0x00d8f0dc in threadStackOverflow (cap=0x1103b00, tso=0x2dff000) at Schedule.c:2762
#3 0x00d8d75c in scheduleHandleStackOverflow (cap=0x1103b00, task=0x2b00430, t=0x2dff000) at Schedule.c:1643
#4 0x00d8c700 in schedule (initialCapability=0x1103b00, task=0x2b00430) at Schedule.c:681
#5 0x00d8e974 in scheduleWaitThread (tso=0x2d80800, ret=0x0, cap=0x1103b00) at Schedule.c:2466
#6 0x00e8aff0 in rts_evalLazyIO (cap=0x1103b00, p=0x10119d8, ret=0x0) at RtsAPI.c:510
#7 0x00c0ae20 in main (argc=2, argv=0xbffff600) at Main.c:105
(gdb) info threads
3 process 5257 thread 0x2003 0x9002c548 in semaphore_wait_signal_trap ()
2 process 5257 thread 0x20f 0x9001fa0c in select ()
* 1 process 5257 local thread 0xf03 0x00d8f5e8 in xchg (p=0x2dff000, w=13313840) at ../includes/SMP.h:74
(gdb) quit
The program is running. Exit anyway? (y or n) y
error while killing target (killing anyway): assertion failure on line 274 of "/SourceCache/gdb/gdb-437/src/gdb/macosx/macosx-nat-inferior-util.c" in function "macosx_inferior_suspend_ptrace": status.value.sig == TARGET_SIGNAL_STOP
warning: error on line 1729 of "/SourceCache/gdb/gdb-437/src/gdb/macosx/macosx-nat-inferior.c" in function "macosx_kill_inferior_safe": (os/kern) failure (0x5x)
$
```
The memory access error occurs in the function `xchg` in `libraries/SMP.h`, here is a disassembly produced by gdb:
```
(gdb) disassemble xchg
Dump of assembler code for function xchg:
0x00d8f5c8 <xchg+0>: stmw r30,-8(r1)
0x00d8f5cc <xchg+4>: stwu r1,-64(r1)
0x00d8f5d0 <xchg+8>: mr r30,r1
0x00d8f5d4 <xchg+12>: stw r3,88(r30)
0x00d8f5d8 <xchg+16>: stw r4,92(r30)
0x00d8f5dc <xchg+20>: lwz r2,92(r30)
0x00d8f5e0 <xchg+24>: lwz r0,88(r30)
0x00d8f5e4 <xchg+28>: lwarx r0,r0,r0
0x00d8f5e8 <xchg+32>: stwcx. r2,r0,r0
0x00d8f5ec <xchg+36>: bne- 0xd8f5e4 <xchg+28>
0x00d8f5f0 <xchg+40>: stw r0,24(r30)
0x00d8f5f4 <xchg+44>: lwz r0,24(r30)
0x00d8f5f8 <xchg+48>: mr r3,r0
0x00d8f5fc <xchg+52>: lwz r1,0(r1)
0x00d8f600 <xchg+56>: lmw r30,-8(r1)
0x00d8f604 <xchg+60>: blr
End of assembler dump.
```
The problem is in `xchg+28`-`xchg+36` which is generated from this code
in `includes/SMP.h`:
```
INLINE_HEADER StgWord
xchg(StgPtr p, StgWord w)
{
StgWord result;
#if i386_HOST_ARCH || x86_64_HOST_ARCH
...
#elif powerpc_HOST_ARCH
__asm__ __volatile__ (
"1: lwarx %0, 0, %2\n"
" stwcx. %1, 0, %2\n"
" bne- 1b"
:"=r" (result)
:"r" (w), "r" (p)
);
#elif sparc_HOST_ARCH
...
#endif
return result;
}
```
What happens is that gcc decides to allocate register `r0` to both `result` and `p`. And that leads to interesting results.
The attached patch solves the problem by specifying the register assigned to `result` as "early clobbered".
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix PPC Mac OS X memory access problem in includes/SMP.h","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"thorkilnaur"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following session uses a recently pulled ghc HEAD which has been built with {{{-debug}}}:\r\n{{{\r\n$ gdb /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-fill-indent-20070506_1304/ghc/compiler/stage2/ghc-6.7.20070513\r\n...\r\n(gdb) run -B/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-fill-indent-20070506_1304/ghc\r\nStarting program: /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-fill-indent-20070506_1304/ghc/compiler/stage2/ghc-6.7.20070513 -B/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-fill-indent-20070506_1304/ghc\r\nReading symbols for shared libraries ..+. done\r\n\r\nProgram received signal EXC_BAD_ACCESS, Could not access memory.\r\nReason: KERN_PROTECTION_FAILURE at address: 0x00cb2744\r\n0x00d8f5e8 in xchg (p=0x2dff000, w=13313840) at ../includes/SMP.h:74\r\n74 __asm__ __volatile__ (\r\n(gdb) where\r\n#0 0x00d8f5e8 in xchg (p=0x2dff000, w=13313840) at ../includes/SMP.h:74\r\n#1 0x00d8f564 in lockClosure (p=0x2dff000) at ../includes/SMP.h:185\r\n#2 0x00d8f0dc in threadStackOverflow (cap=0x1103b00, tso=0x2dff000) at Schedule.c:2762\r\n#3 0x00d8d75c in scheduleHandleStackOverflow (cap=0x1103b00, task=0x2b00430, t=0x2dff000) at Schedule.c:1643\r\n#4 0x00d8c700 in schedule (initialCapability=0x1103b00, task=0x2b00430) at Schedule.c:681\r\n#5 0x00d8e974 in scheduleWaitThread (tso=0x2d80800, ret=0x0, cap=0x1103b00) at Schedule.c:2466\r\n#6 0x00e8aff0 in rts_evalLazyIO (cap=0x1103b00, p=0x10119d8, ret=0x0) at RtsAPI.c:510\r\n#7 0x00c0ae20 in main (argc=2, argv=0xbffff600) at Main.c:105\r\n(gdb) info threads\r\n 3 process 5257 thread 0x2003 0x9002c548 in semaphore_wait_signal_trap ()\r\n 2 process 5257 thread 0x20f 0x9001fa0c in select ()\r\n* 1 process 5257 local thread 0xf03 0x00d8f5e8 in xchg (p=0x2dff000, w=13313840) at ../includes/SMP.h:74\r\n(gdb) quit\r\nThe program is running. Exit anyway? (y or n) y\r\nerror while killing target (killing anyway): assertion failure on line 274 of \"/SourceCache/gdb/gdb-437/src/gdb/macosx/macosx-nat-inferior-util.c\" in function \"macosx_inferior_suspend_ptrace\": status.value.sig == TARGET_SIGNAL_STOP\r\n\r\nwarning: error on line 1729 of \"/SourceCache/gdb/gdb-437/src/gdb/macosx/macosx-nat-inferior.c\" in function \"macosx_kill_inferior_safe\": (os/kern) failure (0x5x)\r\n$\r\n}}}\r\nThe memory access error occurs in the function {{{xchg}}} in {{{libraries/SMP.h}}}, here is a disassembly produced by gdb:\r\n{{{\r\n(gdb) disassemble xchg\r\nDump of assembler code for function xchg:\r\n0x00d8f5c8 <xchg+0>: stmw r30,-8(r1)\r\n0x00d8f5cc <xchg+4>: stwu r1,-64(r1)\r\n0x00d8f5d0 <xchg+8>: mr r30,r1\r\n0x00d8f5d4 <xchg+12>: stw r3,88(r30)\r\n0x00d8f5d8 <xchg+16>: stw r4,92(r30)\r\n0x00d8f5dc <xchg+20>: lwz r2,92(r30)\r\n0x00d8f5e0 <xchg+24>: lwz r0,88(r30)\r\n0x00d8f5e4 <xchg+28>: lwarx r0,r0,r0\r\n0x00d8f5e8 <xchg+32>: stwcx. r2,r0,r0\r\n0x00d8f5ec <xchg+36>: bne- 0xd8f5e4 <xchg+28>\r\n0x00d8f5f0 <xchg+40>: stw r0,24(r30)\r\n0x00d8f5f4 <xchg+44>: lwz r0,24(r30)\r\n0x00d8f5f8 <xchg+48>: mr r3,r0\r\n0x00d8f5fc <xchg+52>: lwz r1,0(r1)\r\n0x00d8f600 <xchg+56>: lmw r30,-8(r1)\r\n0x00d8f604 <xchg+60>: blr\r\nEnd of assembler dump.\r\n}}}\r\nThe problem is in {{{xchg+28}}}-{{{xchg+36}}} which is generated from this code\r\nin {{{includes/SMP.h}}}:\r\n{{{\r\nINLINE_HEADER StgWord\r\nxchg(StgPtr p, StgWord w)\r\n{\r\n StgWord result;\r\n#if i386_HOST_ARCH || x86_64_HOST_ARCH\r\n ...\r\n#elif powerpc_HOST_ARCH\r\n __asm__ __volatile__ (\r\n \"1: lwarx %0, 0, %2\\n\"\r\n \" stwcx. %1, 0, %2\\n\"\r\n \" bne- 1b\"\r\n :\"=r\" (result)\r\n :\"r\" (w), \"r\" (p)\r\n );\r\n#elif sparc_HOST_ARCH\r\n ...\r\n#endif\r\n return result;\r\n}\r\n}}}\r\nWhat happens is that gcc decides to allocate register {{{r0}}} to both {{{result}}} and {{{p}}}. And that leads to interesting results.\r\n\r\nThe attached patch solves the problem by specifying the register assigned to {{{result}}} as \"early clobbered\".\r\n\r\nBest regards\r\nThorkil","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1363Sourcing multi-line scripts in GHCi: track line numbers, and bail out after f...2019-07-07T19:13:52Zfrederik@ofb.netSourcing multi-line scripts in GHCi: track line numbers, and bail out after first errorApologies if this is fixed in 6.6.1.
I have done ":def . readFile" (should be pre-defined?) and use it to read multi-line files; but if there is an error on any of those lines then it seems to always be reported as line 1. This is the o...Apologies if this is fixed in 6.6.1.
I have done ":def . readFile" (should be pre-defined?) and use it to read multi-line files; but if there is an error on any of those lines then it seems to always be reported as line 1. This is the only thing which currently limits the size of the source files that I can use in this way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ghci doesn't report error line for multi-line \"scripts\"","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Apologies if this is fixed in 6.6.1.\r\n\r\nI have done \":def . readFile\" (should be pre-defined?) and use it to read multi-line files; but if there is an error on any of those lines then it seems to always be reported as line 1. This is the only thing which currently limits the size of the source files that I can use in this way.","type_of_failure":"OtherFailure","blocking":[]} -->vivianvivianhttps://gitlab.haskell.org/ghc/ghc/-/issues/1364Finalizers not guaranteed to run before the program exits2019-07-07T19:13:52Ztomac@pacific.net.auFinalizers not guaranteed to run before the program exitsIn the following code (compiled with compiled with ghc --make -fffi -fvia-c Test.hs) the finalizer never gets called, even after replacing printf with something else:
Test.hs:
```
module Main where
import Foreign.Ptr
import Foreign.Fo...In the following code (compiled with compiled with ghc --make -fffi -fvia-c Test.hs) the finalizer never gets called, even after replacing printf with something else:
Test.hs:
```
module Main where
import Foreign.Ptr
import Foreign.ForeignPtr
import Foreign.Marshal.Utils
foreign import ccall safe "ctest.h &ctest" ctestPtr :: FunPtr (Ptr Int -> IO ())
test :: Int -> IO ()
test i = with i test'
where
test' ptr = do fptr <- newForeignPtr ctestPtr ptr
putStrLn "test"
main = do putStrLn "before test..."
test 33
putStrLn "after test..."
```
ctest.h:
```
#include <stdio.h>
static inline void ctest( int *i )
{
printf( "finalizer called with: %d\n", *i );
}
```
I've asked about this on IRC and the Haskell Cafe mailing list and received confirmation that in GHC there is no guarantee that finalizers will run before the program exits:
http://www.haskell.org/pipermail/haskell-cafe/2007-May/025458.html
The FFI addendum to the Haskell 98 report states in section 5.5 that "The only guarantee \[for finalizers\] is that the finalizer runs before the program terminates".
The same statement is made in GHC documentation for newForeignPtr.
This could be a bug or merely a documentation issue but something should probably be done about it.
I suspect it's a bug considering the guarantee specified in the FFI addendum isn't met.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Finalizers not guaranteed to run before the program exits","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"In the following code (compiled with compiled with ghc --make -fffi -fvia-c Test.hs) the finalizer never gets called, even after replacing printf with something else:\r\n\r\nTest.hs:\r\n{{{\r\nmodule Main where\r\n\r\nimport Foreign.Ptr\r\nimport Foreign.ForeignPtr\r\nimport Foreign.Marshal.Utils\r\n\r\nforeign import ccall safe \"ctest.h &ctest\" ctestPtr :: FunPtr (Ptr Int -> IO ())\r\n\r\ntest :: Int -> IO ()\r\ntest i = with i test'\r\n where\r\n test' ptr = do fptr <- newForeignPtr ctestPtr ptr\r\n putStrLn \"test\"\r\n\r\nmain = do putStrLn \"before test...\"\r\n test 33\r\n putStrLn \"after test...\"\r\n}}}\r\n\r\nctest.h:\r\n{{{\r\n#include <stdio.h>\r\n\r\nstatic inline void ctest( int *i )\r\n{\r\n printf( \"finalizer called with: %d\\n\", *i );\r\n}\r\n}}}\r\n\r\nI've asked about this on IRC and the Haskell Cafe mailing list and received confirmation that in GHC there is no guarantee that finalizers will run before the program exits:\r\n\r\nhttp://www.haskell.org/pipermail/haskell-cafe/2007-May/025458.html\r\n\r\nThe FFI addendum to the Haskell 98 report states in section 5.5 that \"The only guarantee [for finalizers] is that the finalizer runs before the program terminates\".\r\n\r\nThe same statement is made in GHC documentation for newForeignPtr.\r\n\r\nThis could be a bug or merely a documentation issue but something should probably be done about it.\r\nI suspect it's a bug considering the guarantee specified in the FFI addendum isn't met.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1366GLOBAL_VAR being inlined?2019-07-07T19:13:52ZmnislaihGLOBAL_VAR being inlined?I noticed that :def wasn't working in my HEAD (as of today) build of ghc.
It would accept my command definitions silently, but they were ignored.
In InteractiveUI:
```
GLOBAL_VAR(commands, builtin_commands, [Command])
builtin_commands...I noticed that :def wasn't working in my HEAD (as of today) build of ghc.
It would accept my command definitions silently, but they were ignored.
In InteractiveUI:
```
GLOBAL_VAR(commands, builtin_commands, [Command])
builtin_commands :: [Command]
builtin_commands = [ ...
```
After a random change :
```
builtin_commands = commands `seq` [
....
]
```
it seems to me that, under certain conditions (which?), GLOBAL_VARs can end up being inlined.
To see if you can reproduce this issue, simply try defining a new command in a -O2 HEAD build of ghci using :def, and then calling it.
Output of ghci005 here in my build of HEAD:
```
unknown command ':echo'
use :? for help.
unknown command ':echo'
use :? for help.
command 'echo' not defined
unknown command ':echo'
use :? for help.
```
With the seq'ing of commands above the test passes finely.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| 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":"GLOBAL_VAR being inlined?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I noticed that :def wasn't working in my HEAD (as of today) build of ghc. \r\nIt would accept my command definitions silently, but they were ignored.\r\n\r\nIn InteractiveUI:\r\n{{{\r\nGLOBAL_VAR(commands, builtin_commands, [Command])\r\n\r\nbuiltin_commands :: [Command]\r\nbuiltin_commands = [ ...\r\n}}}\r\n\r\nAfter a random change : \r\n{{{\r\nbuiltin_commands = commands `seq` [ \r\n....\r\n]\r\n}}}\r\n\r\nit seems to me that, under certain conditions (which?), GLOBAL_VARs can end up being inlined.\r\n\r\nTo see if you can reproduce this issue, simply try defining a new command in a -O2 HEAD build of ghci using :def, and then calling it.\r\n\r\nOutput of ghci005 here in my build of HEAD:\r\n{{{\r\nunknown command ':echo'\r\nuse :? for help.\r\nunknown command ':echo'\r\nuse :? for help.\r\ncommand 'echo' not defined\r\nunknown command ':echo'\r\nuse :? for help.\r\n}}}\r\n\r\nWith the seq'ing of commands above the test passes finely.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/1367GHC[i] 6.6.1 can't find GNUreadline on PPC mac2019-07-07T19:13:52Zhal@oz.netGHC[i] 6.6.1 can't find GNUreadline on PPC macI installed GHC on a OS X 10.4.9 powerbook using the pre-built ghc-6.6.1-powerpc-apple-darwin.tar.bz2 archive (configure then make install). Unfortunately I get this message when I run either ghci or ghc:
dyld: Library not loaded: GNUre...I installed GHC on a OS X 10.4.9 powerbook using the pre-built ghc-6.6.1-powerpc-apple-darwin.tar.bz2 archive (configure then make install). Unfortunately I get this message when I run either ghci or ghc:
dyld: Library not loaded: GNUreadline.framework/GNUreadline
> Referenced from: /usr/local/lib/ghc-6.6.1/ghc-6.6.1
> Reason: image not found
Trace/BPT trap
GHC 6.6 is still installed on this system and it continues to work fine.
Suggestions appreciated. Thanks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC[i] 6.6.1 can't find GNUreadline on PPC mac","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I installed GHC on a OS X 10.4.9 powerbook using the pre-built ghc-6.6.1-powerpc-apple-darwin.tar.bz2 archive (configure then make install). Unfortunately I get this message when I run either ghci or ghc:\r\n\r\ndyld: Library not loaded: GNUreadline.framework/GNUreadline\r\n Referenced from: /usr/local/lib/ghc-6.6.1/ghc-6.6.1\r\n Reason: image not found\r\nTrace/BPT trap\r\n\r\nGHC 6.6 is still installed on this system and it continues to work fine.\r\n\r\nSuggestions appreciated. Thanks.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1368Use filepath in GHC2019-07-07T19:13:51ZSimon MarlowUse filepath in GHCReplace GHC's custom filepath manipulation utilities in `Utils` with `System.FilePath`. Easy refactoring/cleanup for someone wanting to get some GHC hacking experience.
<details><summary>Trac metadata</summary>
| Trac field ...Replace GHC's custom filepath manipulation utilities in `Utils` with `System.FilePath`. Easy refactoring/cleanup for someone wanting to get some GHC hacking experience.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Use filepath in GHC","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"Replace GHC's custom filepath manipulation utilities in `Utils` with `System.FilePath`. Easy refactoring/cleanup for someone wanting to get some GHC hacking experience.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1369Type error when compiling ST-monad-like code2019-07-07T19:13:51Zkoen@cs.chalmers.seType error when compiling ST-monad-like codeCompiling the module below works fine in GHC 6.4.2. In GHC 6.6 and 6.6.1, it gives a type error.
/Koen
```
{-# OPTIONS -fglasgow-exts #-}
module Bug where
import Control.Monad.ST
import Data.STRef
newtype M s a =
MkM (STRef s Int -...Compiling the module below works fine in GHC 6.4.2. In GHC 6.6 and 6.6.1, it gives a type error.
/Koen
```
{-# OPTIONS -fglasgow-exts #-}
module Bug where
import Control.Monad.ST
import Data.STRef
newtype M s a =
MkM (STRef s Int -> ST s a)
runM :: (forall s . M s a) -> a
runM mm =
runST (
do ref <- newSTRef 0
m ref
)
where
MkM m = mm
-- the instance declaration and function definition
-- of "inc" are just here for giving context;
-- removing them still makes runM not type check in GHC 6.6
instance Monad (M s) where
return x =
MkM (\_ -> return x)
MkM m >>= k =
MkM (\ref ->
do x <- m ref
let MkM m' = k x
m' ref
)
inc :: M s Int
inc = MkM (\ref ->
do n <- readSTRef ref
writeSTRef ref (n+1)
return n
)
```https://gitlab.haskell.org/ghc/ghc/-/issues/1370Obscure loop in interaction between arity and case-of-bottom2019-07-07T19:13:51ZSimon Peyton JonesObscure loop in interaction between arity and case-of-bottomJohn Meacham discovered that this program makes the simplifier loop:
```
newtype T = V T deriving(Eq,Ord)
```
It's a silly program, but it shouldn't kill GHC! I investigated and the reason is because we get this:
```
rec { compare :...John Meacham discovered that this program makes the simplifier loop:
```
newtype T = V T deriving(Eq,Ord)
```
It's a silly program, but it shouldn't kill GHC! I investigated and the reason is because we get this:
```
rec { compare :: T -> T -> Ordering
compare [arity 2] = compare }
max :: T -> T -> T
max x y = case compare x y of { GT -> x; other -> y }
```
The real bug is that `compare` has been eta-reduced, but still has arity 2. That's wrong. Anyway, since `compare` diverges, we get
```
max x y = compare `cast` UnsafeCoerce (T->T->T) T
```
and now we try to eta-expand the RHS of `max`, and that is a stupid thing to do (and loops in `CoreUtils.etaExpand`.
The real bug is the unsound eta-reducion for `compare`, which I knew about (comments in `Note [Add IdInfo back onto a let-bound Id]` in `SimplEnv`).
It's a dark corner case, and I'm not going to fix it today.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Obscure loop in interaction between arity and case-of-bottom","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"John Meacham discovered that this program makes the simplifier loop:\r\n{{{\r\nnewtype T = V T deriving(Eq,Ord)\r\n}}}\r\nIt's a silly program, but it shouldn't kill GHC! I investigated and the reason is because we get this:\r\n{{{\r\n rec { compare :: T -> T -> Ordering\r\n compare [arity 2] = compare }\r\n \r\n max :: T -> T -> T\r\n max x y = case compare x y of { GT -> x; other -> y }\r\n}}}\r\nThe real bug is that `compare` has been eta-reduced, but still has arity 2. That's wrong. Anyway, since `compare` diverges, we get\r\n{{{\r\n max x y = compare `cast` UnsafeCoerce (T->T->T) T\r\n}}}\r\nand now we try to eta-expand the RHS of `max`, and that is a stupid thing to do (and loops in `CoreUtils.etaExpand`.\r\n\r\nThe real bug is the unsound eta-reducion for `compare`, which I knew about (comments in `Note [Add IdInfo back onto a let-bound Id]` in `SimplEnv`). \r\n\r\nIt's a dark corner case, and I'm not going to fix it today.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/1372Recompilation checker should consider package versions (and other factors)2019-07-07T19:13:50Zbringert@cs.chalmers.seRecompilation checker should consider package versions (and other factors)Currently, if an installed package is upgraded, the recompilation checker does not think that modules which use that package need to be recompiled. Since the package version is part of the internal names, and because of cross-package opt...Currently, if an installed package is upgraded, the recompilation checker does not think that modules which use that package need to be recompiled. Since the package version is part of the internal names, and because of cross-package optimizations, this really needs to be done.
If the interface file would list which packages (including version numbers) a module uses, we could decide to recompile whenever the packages used by the module are different from those used in the current compilation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Recompilation checker should consider package versions","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Currently, if an installed package is upgraded, the recompilation checker does not think that modules which use that package need to be recompiled. Since the package version is part of the internal names, and because of cross-package optimizations, this really needs to be done. \r\n\r\nIf the interface file would list which packages (including version numbers) a module uses, we could decide to recompile whenever the packages used by the module are different from those used in the current compilation.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1373Allow Access to generated STG from the GHC API2019-07-07T19:13:50ZguestAllow Access to generated STG from the GHC APIIt would be really nice to be able to either:
1. ) access STG from the GHC API and tell the compiler to stop at that point.
1. ) be able to dump STG to some sort of separate ".stg" file for further processing.
This would enable other...It would be really nice to be able to either:
1. ) access STG from the GHC API and tell the compiler to stop at that point.
1. ) be able to dump STG to some sort of separate ".stg" file for further processing.
This would enable other backends to be written, since all the heavy lifting has been done by the point its been converted to the spineless tagless g-machine and that representation is more suitable than Cmm for generating output for languages like JavaScript.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Allow Access to generated STG from the GHC API","status":"New","operating_system":"Unknown","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":["STG"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"It would be really nice to be able to either:\r\n\r\n1.) access STG from the GHC API and tell the compiler to stop at that point. \r\n\r\n2.) be able to dump STG to some sort of separate \".stg\" file for further processing. \r\n\r\nThis would enable other backends to be written, since all the heavy lifting has been done by the point its been converted to the spineless tagless g-machine and that representation is more suitable than Cmm for generating output for languages like JavaScript.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/1374Error: file is not executable: "...\\ar.exe"2019-07-07T19:13:50ZguestError: file is not executable: "...\\ar.exe"I get
**Setup.hs: Error: file is not executable: "C:\\\\Pro\\\\Haskell\\\\ghc-6.6.1\\\\bin\\\\ar.exe"**
when building any package under Windows Vista HP.
The file really executes and current user have all required rights on it.
I got thi...I get
**Setup.hs: Error: file is not executable: "C:\\\\Pro\\\\Haskell\\\\ghc-6.6.1\\\\bin\\\\ar.exe"**
when building any package under Windows Vista HP.
The file really executes and current user have all required rights on it.
I got this message on ghc-6.6 also.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Error: file is not executable: \"...\\\\ar.exe\"","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":["Cabal","Vista"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I get\r\n'''Setup.hs: Error: file is not executable: \"C:\\\\Pro\\\\Haskell\\\\ghc-6.6.1\\\\bin\\\\ar.exe\"'''\r\nwhen building any package under Windows Vista HP.\r\nThe file really executes and current user have all required rights on it.\r\nI got this message on ghc-6.6 also.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1375ByteString’s “lines” eats empty lines2019-07-07T19:13:49ZguestByteString’s “lines” eats empty linesI’d expect this to be true for ByteStrings
map B.unpack . B.lines . B.pack == Prelude.lines
But it seems that B.lines will merge several consecutive newlines. B.split '\\n' works as it should, though.
Thanks,
Joachim
<details><summary>...I’d expect this to be true for ByteStrings
map B.unpack . B.lines . B.pack == Prelude.lines
But it seems that B.lines will merge several consecutive newlines. B.split '\\n' works as it should, though.
Thanks,
Joachim
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ByteString’s “lines” eats empty lines","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I’d expect this to be true for ByteStrings\r\nmap B.unpack . B.lines . B.pack == Prelude.lines\r\nBut it seems that B.lines will merge several consecutive newlines. B.split '\\n' works as it should, though.\r\n\r\nThanks,\r\nJoachim","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1donsdonshttps://gitlab.haskell.org/ghc/ghc/-/issues/1376panic caused in ghci by the following code involving monad transformers2019-07-07T19:13:49Zlogancapaldo@gmail.companic caused in ghci by the following code involving monad transformersI was attempting to learn to use monad transformers when I came across this bug,
the following is the contents of StateAccum.hs
```
import Control.Monad
import Control.Monad.State
import Control.Monad.List
sumUp :: [Int] -> State Int [...I was attempting to learn to use monad transformers when I came across this bug,
the following is the contents of StateAccum.hs
```
import Control.Monad
import Control.Monad.State
import Control.Monad.List
sumUp :: [Int] -> State Int [()]
sumUp = sequence . map (modify . (+))
type StateWithList = ListT (State Int)
sumUp' xs = do x <- xs
lift (modify (+x))
return (lift get)
sumThreeLists :: [Int] -> [Int] -> [Int] -> Int
sumThreeLists xs ys zs = execState (sumUp xs >> sumUp ys >> sumUp zs) 0
main = do print $ execState (sumUp [1,2,3]) 0
print $ sumThreeLists [1..10] [1..10] [1..10]
```
This is a transcript of the ghci session that causes the panic:
```
% ghci StateAccum.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( StateAccum.hs, interpreted )
Ok, modules loaded: Main.
*Main> sumUp' [return 1, return 2]
ghc-6.6.1: panic! (the 'impossible' happened)
(GHC version 6.6.1 for powerpc-apple-darwin):
nameModule it{v a1es}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*Main>
```
I'm using the binary ghc package for Mac OS PPC provided on the ghc site. The output for uname -a on my machine is
` Darwin Logan-Capaldos-Computer.local 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc `
Running with ghci -v, this is the output
```
% ghci -v StateAccum.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Using package config file: /usr/local/lib/ghc-6.6.1/package.conf
wired-in package base mapped to base-2.1.1
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.1
Hsc static flags: -static
Loading package base ... linking ... done.
wired-in package base mapped to base-2.1.1
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.1
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
wired-in package base mapped to base-2.1.1
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.1
*** Chasing dependencies:
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Upsweep completely successful.
*** Deleting temp files:
Deleting:
*** Chasing dependencies:
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
compile: input file StateAccum.hs
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( StateAccum.hs, interpreted )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 244
*** Simplify:
Result size = 292
Result size = 263
Result size = 263
*** Tidy Core:
Result size = 263
*** CorePrep:
Result size = 331
*** ByteCodeGen:
*** Deleting temp files:
Deleting:
Upsweep completely successful.
*** Deleting temp files:
Deleting:
Ok, modules loaded: Main.
*Main> sumUp' [return 1, return 2]
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
ghc-6.6.1: panic! (the 'impossible' happened)
(GHC version 6.6.1 for powerpc-apple-darwin):
nameModule it{v a1es}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*Main>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic caused in ghci by the following code involving monad transformers","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was attempting to learn to use monad transformers when I came across this bug,\r\nthe following is the contents of StateAccum.hs\r\n{{{\r\nimport Control.Monad\r\nimport Control.Monad.State\r\nimport Control.Monad.List\r\n\r\nsumUp :: [Int] -> State Int [()]\r\nsumUp = sequence . map (modify . (+))\r\n\r\ntype StateWithList = ListT (State Int)\r\n\r\nsumUp' xs = do x <- xs\r\n lift (modify (+x))\r\n return (lift get)\r\n\r\n\r\nsumThreeLists :: [Int] -> [Int] -> [Int] -> Int\r\nsumThreeLists xs ys zs = execState (sumUp xs >> sumUp ys >> sumUp zs) 0\r\n\r\nmain = do print $ execState (sumUp [1,2,3]) 0\r\n print $ sumThreeLists [1..10] [1..10] [1..10]\r\n}}}\r\n\r\nThis is a transcript of the ghci session that causes the panic:\r\n{{{\r\n% ghci StateAccum.hs\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Main ( StateAccum.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> sumUp' [return 1, return 2]\r\nghc-6.6.1: panic! (the 'impossible' happened)\r\n (GHC version 6.6.1 for powerpc-apple-darwin):\r\n nameModule it{v a1es}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n*Main> \r\n}}}\r\n\r\nI'm using the binary ghc package for Mac OS PPC provided on the ghc site. The output for uname -a on my machine is\r\n\r\n{{{ Darwin Logan-Capaldos-Computer.local 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc }}}\r\n\r\nRunning with ghci -v, this is the output\r\n{{{\r\n% ghci -v StateAccum.hs\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nUsing package config file: /usr/local/lib/ghc-6.6.1/package.conf\r\nwired-in package base mapped to base-2.1.1\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0\r\nwired-in package template-haskell mapped to template-haskell-2.1\r\nHsc static flags: -static\r\nLoading package base ... linking ... done.\r\nwired-in package base mapped to base-2.1.1\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0\r\nwired-in package template-haskell mapped to template-haskell-2.1\r\n*** Parser:\r\n*** Desugar:\r\n*** Simplify:\r\n*** CorePrep:\r\n*** ByteCodeGen:\r\n*** Parser:\r\n*** Desugar:\r\n*** Simplify:\r\n*** CorePrep:\r\n*** ByteCodeGen:\r\nwired-in package base mapped to base-2.1.1\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0\r\nwired-in package template-haskell mapped to template-haskell-2.1\r\n*** Chasing dependencies:\r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Chasing dependencies:\r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\ncompile: input file StateAccum.hs\r\n*** Checking old interface for main:Main:\r\n[1 of 1] Compiling Main ( StateAccum.hs, interpreted )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\n Result size = 244\r\n*** Simplify:\r\n Result size = 292\r\n Result size = 263\r\n Result size = 263\r\n*** Tidy Core:\r\n Result size = 263\r\n*** CorePrep:\r\n Result size = 331\r\n*** ByteCodeGen:\r\n*** Deleting temp files:\r\nDeleting: \r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\nOk, modules loaded: Main.\r\n*Main> sumUp' [return 1, return 2]\r\n*** Parser:\r\n*** Desugar:\r\n*** Simplify:\r\n*** CorePrep:\r\n*** ByteCodeGen:\r\nghc-6.6.1: panic! (the 'impossible' happened)\r\n (GHC version 6.6.1 for powerpc-apple-darwin):\r\n nameModule it{v a1es}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n*Main> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1378command line switch to disable ghci banner2019-07-07T19:13:48ZEeliscommand line switch to disable ghci bannerThere really should be a ghci command line switch to disable the obnoxious, space-wasting (it consumes a quarter of my standard 80x25 terminal), and frankly smug, ascii-art banner it shows on startup. -v0 kills it, but kills other output...There really should be a ghci command line switch to disable the obnoxious, space-wasting (it consumes a quarter of my standard 80x25 terminal), and frankly smug, ascii-art banner it shows on startup. -v0 kills it, but kills other output as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"command line switch to disable ghci banner","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"There really should be a ghci command line switch to disable the obnoxious, space-wasting (it consumes a quarter of my standard 80x25 terminal), and frankly smug, ascii-art banner it shows on startup. -v0 kills it, but kills other output as well.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1380Safe Haskell2019-07-07T19:13:48ZIan Lynagh <igloo@earth.li>Safe HaskellWe should make it easy to do safe (\~= no IO) Haskell.
Things to think about include:
- Expressions with type IO a
- unsafePerformIO etc
- unsafe array indexing functions etc
- FFI declarations
- Template Haskell
- bugs like custom Ix ...We should make it easy to do safe (\~= no IO) Haskell.
Things to think about include:
- Expressions with type IO a
- unsafePerformIO etc
- unsafe array indexing functions etc
- FFI declarations
- Template Haskell
- bugs like custom Ix instances allowing incorrect array indexing
- importing other modules which can do unsafe things (this generalises some of the above)
- Allowing restricted IO functions, e.g. reading/writing functions within a certain directory only
We may want to add support for this to GHC and/or Cabal, e.g. only allow a module to be compiled with `-fsafe` if (a) all of its imports are marked safe (a new ghc-pkg field) and (b) it only does safe things itself (no TH etc). It would also be possible to tell ghc-pkg that you consider a module safe.
There's a proposal at http://www.pphsg.org/safeghc/ for a similar thing, but at the value level rather than the module/package level. However, we don't think the increased implementation cost is worth the small extra benefit it provides.
One might also worry about resource exhaustion.
There have also been a number of discussions about his on the mailing lists and on IRC, e.g. the thread beginning http://www.haskell.org/pipermail/haskell-cafe/2007-May/025941.html
Working out exactly what it should do is half of the challenge here!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Safe Haskell","status":"New","operating_system":"Unknown","component":"None","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"We should make it easy to do safe (~= no IO) Haskell.\r\n\r\nThings to think about include:\r\n * Expressions with type IO a\r\n * unsafePerformIO etc\r\n * unsafe array indexing functions etc\r\n * FFI declarations\r\n * Template Haskell\r\n * bugs like custom Ix instances allowing incorrect array indexing\r\n * importing other modules which can do unsafe things (this generalises some of the above)\r\n * Allowing restricted IO functions, e.g. reading/writing functions within a certain directory only\r\n\r\nWe may want to add support for this to GHC and/or Cabal, e.g. only allow a module to be compiled with `-fsafe` if (a) all of its imports are marked safe (a new ghc-pkg field) and (b) it only does safe things itself (no TH etc). It would also be possible to tell ghc-pkg that you consider a module safe.\r\n\r\nThere's a proposal at http://www.pphsg.org/safeghc/ for a similar thing, but at the value level rather than the module/package level. However, we don't think the increased implementation cost is worth the small extra benefit it provides.\r\n\r\nOne might also worry about resource exhaustion.\r\n\r\nThere have also been a number of discussions about his on the mailing lists and on IRC, e.g. the thread beginning http://www.haskell.org/pipermail/haskell-cafe/2007-May/025941.html\r\n\r\nWorking out exactly what it should do is half of the challenge here!","type_of_failure":"OtherFailure","blocking":[]} -->⊥dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/1382Monad GHC.Prim.Any1 gets derived in a context2019-07-07T19:13:47Ziampure@gmail.comMonad GHC.Prim.Any1 gets derived in a contextBecause Monad GHC.Prim.Any1 gets derived in the type of the function test in the attached file, I cannot write an instance for it (obviously) and I cannot continue writing the code where I use the test function. I.e. I have this problem ...Because Monad GHC.Prim.Any1 gets derived in the type of the function test in the attached file, I cannot write an instance for it (obviously) and I cannot continue writing the code where I use the test function. I.e. I have this problem in a real project and it's blocking progress, until I find a work-around (which I didn't find after about an hour). I hope this gets fixed soon.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Monad GHC.Prim.Any1 gets derived in a context","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":["Any1","context","type-inference"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Because Monad GHC.Prim.Any1 gets derived in the type of the function test in the attached file, I cannot write an instance for it (obviously) and I cannot continue writing the code where I use the test function. I.e. I have this problem in a real project and it's blocking progress, until I find a work-around (which I didn't find after about an hour). I hope this gets fixed soon.","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Jones