GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-11-30T06:24:44Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14739Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures2022-11-30T06:24:44ZmitchtyCannot compile ghc 8.2.1 or 8.2.2 on armv7l architecturesNoticed while trying to build ghc 8.2.1, and ghc 8.2.2 on alpine linux armhf as well as nixos. Opening this ticket as I previously thought this was just some quirk of the alpine linux port but managed to find out from dhess on irc that n...Noticed while trying to build ghc 8.2.1, and ghc 8.2.2 on alpine linux armhf as well as nixos. Opening this ticket as I previously thought this was just some quirk of the alpine linux port but managed to find out from dhess on irc that nixos hits the same issue for both as well on armv7l arches.
What happens. 8.2.1 logs, 8.2.2 has similar or the same issues, I was just double checking that 8.2.1 has the same problems.
```
"inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packag
es -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/vendor/attoparsec-0.13.1.
0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build
/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dis
t/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id filepath-1.4.1.2 -package-id directory-1.
3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2
-package-id Cabal-2.0.0.2 -package-id ghc-boot-8.2.1 -package-id ghc-8.2.1 -package-id bytestring-0.10.8.2 -package-i
d transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsop
ts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir uti
ls/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-api/src/Haddock/Backends/Hyperlink
er/Types.hs -o utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o
"inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packag
es -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/vendor/attoparsec-0.13.1.
0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build
/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dis
t/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id filepath-1.4.1.2 -package-id directory-1.
3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2
-package-id Cabal-2.0.0.2 -package-id ghc-boot-8.2.1 -package-id ghc-8.2.1 -package-id bytestring-0.10.8.2 -package-i
d transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsop
ts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir uti
ls/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-library/src/Documentation/Haddock/
Types.hs -o utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o
make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Segmentation fault
(core dumped)
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/ResponseFile.dyn_o] Segmentation fault (core dumped)
make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Segmentation fault (core dumpe
d)
make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Segmentation
fault (core dumped)
$ gdb /home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc-stage2 src/ghc-8.2.1/core
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv6-alpine-linux-musleabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc-stage2...done.
[New LWP 24905]
[New LWP 24908]
bt
Core was generated by `/home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc-stage2 -B/ho'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0019d628 in stg_IND_STATIC_info ()
[Current thread is 1 (LWP 24905)]
(gdb) bt
#0 0x0019d628 in stg_IND_STATIC_info ()
#1 0xaffcfe1c in stg_newAlignedPinnedByteArrayzh$def ()
from /home/build/aports/community/ghc/src/ghc-8.2.1/rts/dist/build/libHSrts_thr-ghc8.2.1.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
```
I've been poking around but i'm a bit out of my depth here in understanding the ghc rts here and debugging it as well. But its curious that only the stage2 compiler is having issues being built and not stage0 or stage1.
If needed/desired I can provide access/login to this box for debugging but its sloooow, \~29 hours to do a build to this point.
But I'm willing to help move things along, ghc on arm is one of the main reaons for the port to alpine linux and 8.0.2 works fine.
<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":"Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Noticed while trying to build ghc 8.2.1, and ghc 8.2.2 on alpine linux armhf as well as nixos. Opening this ticket as I previously thought this was just some quirk of the alpine linux port but managed to find out from dhess on irc that nixos hits the same issue for both as well on armv7l arches.\r\n\r\nWhat happens. 8.2.1 logs, 8.2.2 has similar or the same issues, I was just double checking that 8.2.1 has the same problems.\r\n\r\n{{{\r\n\"inplace/bin/ghc-stage2\" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packag\r\nes -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/vendor/attoparsec-0.13.1.\r\n0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build\r\n/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dis\r\nt/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id filepath-1.4.1.2 -package-id directory-1.\r\n3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2\r\n -package-id Cabal-2.0.0.2 -package-id ghc-boot-8.2.1 -package-id ghc-8.2.1 -package-id bytestring-0.10.8.2 -package-i\r\nd transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsop\r\nts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir uti\r\nls/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-api/src/Haddock/Backends/Hyperlink\r\ner/Types.hs -o utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o\r\n\"inplace/bin/ghc-stage2\" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packag\r\nes -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/vendor/attoparsec-0.13.1.\r\n0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build\r\n/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dis\r\nt/build/haddock/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id filepath-1.4.1.2 -package-id directory-1.\r\n3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2\r\n -package-id Cabal-2.0.0.2 -package-id ghc-boot-8.2.1 -package-id ghc-8.2.1 -package-id bytestring-0.10.8.2 -package-i\r\nd transformers-0.5.2.0 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsop\r\nts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir uti\r\nls/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-library/src/Documentation/Haddock/\r\nTypes.hs -o utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o\r\nmake[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Segmentation fault\r\n(core dumped)\r\nmake[1]: *** Waiting for unfinished jobs....\r\nmake[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/ResponseFile.dyn_o] Segmentation fault (core dumped)\r\nmake[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Segmentation fault (core dumpe\r\nd)\r\nmake[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Segmentation\r\n fault (core dumped)\r\n \r\n $ gdb /home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc-stage2 src/ghc-8.2.1/core\r\nGNU gdb (GDB) 7.12.1\r\nCopyright (C) 2017 Free Software Foundation, Inc.\r\nLicense GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\r\nThis is free software: you are free to change and redistribute it.\r\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\r\nand \"show warranty\" for details.\r\nThis GDB was configured as \"armv6-alpine-linux-musleabihf\".\r\nType \"show configuration\" for configuration details.\r\nFor bug reporting instructions, please see:\r\n<http://www.gnu.org/software/gdb/bugs/>.\r\nFind the GDB manual and other documentation resources online at:\r\n<http://www.gnu.org/software/gdb/documentation/>.\r\nFor help, type \"help\".\r\nType \"apropos word\" to search for commands related to \"word\"...\r\nReading symbols from /home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc-stage2...done.\r\n[New LWP 24905]\r\n[New LWP 24908]\r\nbt\r\nCore was generated by `/home/build/aports/community/ghc/src/ghc-8.2.1/inplace/lib/bin/ghc-stage2 -B/ho'.\r\nProgram terminated with signal SIGSEGV, Segmentation fault.\r\n#0 0x0019d628 in stg_IND_STATIC_info ()\r\n[Current thread is 1 (LWP 24905)]\r\n(gdb) bt\r\n#0 0x0019d628 in stg_IND_STATIC_info ()\r\n#1 0xaffcfe1c in stg_newAlignedPinnedByteArrayzh$def ()\r\n from /home/build/aports/community/ghc/src/ghc-8.2.1/rts/dist/build/libHSrts_thr-ghc8.2.1.so\r\nBacktrace stopped: previous frame identical to this frame (corrupt stack?)\r\n(gdb)\r\n}}}\r\n\r\nI've been poking around but i'm a bit out of my depth here in understanding the ghc rts here and debugging it as well. But its curious that only the stage2 compiler is having issues being built and not stage0 or stage1.\r\n\r\nIf needed/desired I can provide access/login to this box for debugging but its sloooow, ~29 hours to do a build to this point.\r\n\r\nBut I'm willing to help move things along, ghc on arm is one of the main reaons for the port to alpine linux and 8.0.2 works fine. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1957Program that runs slower with optimizations on2022-11-29T14:34:22ZclanehinProgram that runs slower with optimizations onThis program runs significantly slower with optimization than without.
I need two modules to manifest this bug.
Is this a duplicate of 917/1945? Using -fno-full-laziness does not mitigate the problem.
This seems to be the opposite of ...This program runs significantly slower with optimization than without.
I need two modules to manifest this bug.
Is this a duplicate of 917/1945? Using -fno-full-laziness does not mitigate the problem.
This seems to be the opposite of 1945. Without optimizations, there is a long delay and then all 10 results print at once. With optimizations, there is a shorter delay between each print statement.
```
module Main
(main)
> where
import NaiveFib
import Control.Monad
main :: IO ()
main = replicateM_ 10 (printFib 37)
module NaiveFib
(printFib,naiveFib)
> where
printFib :: Integer -\> IO ()
printFib = print . naiveFib
naiveFib :: Integer -\> Integer
naiveFib 0 = 0
naiveFib 1 = 1
naiveFib n = naiveFib (n-1) + naiveFib (n-2)
lane\@wired:\~/test/optimizer-bug$ make main-O0
ghc-6.8.1 -O0 --make Main.hs -o main-O0
\[1 of 2\] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o )
\[2 of 2\] Compiling Main ( Main.hs, Main.o )
Linking main-O0 ...
lane\@wired:\~/test/optimizer-bug$ time ./main-O0
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
real 0m34.491s
user 0m25.982s
sys 0m0.564s
lane\@wired:\~/test/optimizer-bug$ make main-O2
ghc-6.8.1 -O2 --make Main.hs -o main-O2
\[1 of 2\] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o )
\[2 of 2\] Compiling Main ( Main.hs, Main.o )
Linking main-O2 ...
lane\@wired:\~/test/optimizer-bug$ time ./main-O2
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
24157817
real 1m50.331s
user 1m23.641s
sys 0m1.008s
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.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":"Program that runs slower with optimizations on","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program runs significantly slower with optimization than without. \r\n\r\nI need two modules to manifest this bug.\r\n\r\nIs this a duplicate of 917/1945? Using -fno-full-laziness does not mitigate the problem.\r\n\r\nThis seems to be the opposite of 1945. Without optimizations, there is a long delay and then all 10 results print at once. With optimizations, there is a shorter delay between each print statement.\r\n\r\nmodule Main\r\n (main)\r\n where\r\n\r\nimport NaiveFib\r\nimport Control.Monad\r\n\r\nmain :: IO ()\r\nmain = replicateM_ 10 (printFib 37)\r\n\r\nmodule NaiveFib\r\n (printFib,naiveFib)\r\n where\r\n\r\nprintFib :: Integer -> IO ()\r\nprintFib = print . naiveFib\r\n\r\nnaiveFib :: Integer -> Integer\r\nnaiveFib 0 = 0\r\nnaiveFib 1 = 1\r\nnaiveFib n = naiveFib (n-1) + naiveFib (n-2)\r\n\r\nlane@wired:~/test/optimizer-bug$ make main-O0\r\nghc-6.8.1 -O0 --make Main.hs -o main-O0\r\n[1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o )\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\nLinking main-O0 ...\r\nlane@wired:~/test/optimizer-bug$ time ./main-O0\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n\r\nreal 0m34.491s\r\nuser 0m25.982s\r\nsys 0m0.564s\r\n\r\nlane@wired:~/test/optimizer-bug$ make main-O2\r\nghc-6.8.1 -O2 --make Main.hs -o main-O2\r\n[1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o )\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\nLinking main-O2 ...\r\nlane@wired:~/test/optimizer-bug$ time ./main-O2\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n24157817\r\n\r\nreal 1m50.331s\r\nuser 1m23.641s\r\nsys 0m1.008s\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16352Hadrian: generation of PDF documents doesn't work2022-11-29T09:44:10ZAlp MestanogullariHadrian: generation of PDF documents doesn't work1) With [ghc.nix](https://github.com/alpmestan/ghc.nix)
While trying to produce `_build/docs/pdfs/Haddock.pdf`:
```
kpathsea: Running mktexmf pcrr8t
! I can't find file `pcrr8t'.
<*> ...:=ljfour; mag:=1; nonstopmode; input pcrr8t
...1) With [ghc.nix](https://github.com/alpmestan/ghc.nix)
While trying to produce `_build/docs/pdfs/Haddock.pdf`:
```
kpathsea: Running mktexmf pcrr8t
! I can't find file `pcrr8t'.
<*> ...:=ljfour; mag:=1; nonstopmode; input pcrr8t
Please type another input file name
! Emergency stop.
<*> ...:=ljfour; mag:=1; nonstopmode; input pcrr8t
Transcript written on mfput.log.
grep: pcrr8t.log: No such file or directory
```
2) With the CI docker images
(e.g [this x86_64 debian8 one](https://gitlab.haskell.org/ghc/ghc/blob/master/.circleci/images/x86_64-linux-deb8/Dockerfile))
Agian, while trying to product the PDF version of the haddock manual:
```
| Run Xelatex: Haddock.tex => /tmp/extra-dir-87721391039866
This is XeTeX, Version 3.14159265-2.6-0.99992 (TeX Live 2015/dev/Debian) (preloaded format=xelatex)
restricted \write18 enabled.
entering extended mode
(./Haddock.tex
LaTeX2e <2014/05/01>
Babel <3.9l> and hyphenation patterns for 2 languages loaded.
(./sphinxmanual.cls
Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))
(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
Package inputenc Warning: inputenc package ignored with utf8 based engines.
)
! Undefined control sequence.
<recently read> \DeclareUnicodeCharacter
l.5 \DeclareUnicodeCharacter
{00A0}{\nobreakspace}
No pages of output.
Transcript written on Haddock.log.
```
[This StackExchange post](https://tex.stackexchange.com/a/378643) that Matthew pointed me to gives a clue as to as why this happens.
---
I am going to comment out the `need`s that make us produce these files in Hadrian when we ask for the docs, for now, leaving a comment pointing to this ticket. Then as we figure out solutions to these issues (especially 2), since that's GHC's CI system), we can put those PDFs back in and mark this ticket as solved.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | snowleopard |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian: generation of PDF documents doesn't work","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["snowleopard"],"type":"Bug","description":"1) With [https://github.com/alpmestan/ghc.nix ghc.nix]\r\n\r\nWhile trying to produce `_build/docs/pdfs/Haddock.pdf`:\r\n\r\n{{{\r\nkpathsea: Running mktexmf pcrr8t\r\n\r\n! I can't find file `pcrr8t'.\r\n<*> ...:=ljfour; mag:=1; nonstopmode; input pcrr8t\r\n \r\nPlease type another input file name\r\n! Emergency stop.\r\n<*> ...:=ljfour; mag:=1; nonstopmode; input pcrr8t\r\n \r\nTranscript written on mfput.log.\r\ngrep: pcrr8t.log: No such file or directory\r\n\r\n}}}\r\n\r\n2) With the CI docker images\r\n\r\n(e.g [https://gitlab.haskell.org/ghc/ghc/blob/master/.circleci/images/x86_64-linux-deb8/Dockerfile this x86_64 debian8 one])\r\n\r\nAgian, while trying to product the PDF version of the haddock manual:\r\n\r\n{{{\r\n| Run Xelatex: Haddock.tex => /tmp/extra-dir-87721391039866\r\nThis is XeTeX, Version 3.14159265-2.6-0.99992 (TeX Live 2015/dev/Debian) (preloaded format=xelatex)\r\n restricted \\write18 enabled.\r\nentering extended mode\r\n(./Haddock.tex\r\nLaTeX2e <2014/05/01>\r\nBabel <3.9l> and hyphenation patterns for 2 languages loaded.\r\n(./sphinxmanual.cls\r\nDocument Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)\r\n(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls\r\nDocument Class: report 2014/09/29 v1.4h Standard LaTeX document class\r\n(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))\r\n(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty\r\n\r\nPackage inputenc Warning: inputenc package ignored with utf8 based engines.\r\n\r\n)\r\n! Undefined control sequence.\r\n<recently read> \\DeclareUnicodeCharacter \r\n \r\nl.5 \\DeclareUnicodeCharacter\r\n {00A0}{\\nobreakspace}\r\nNo pages of output.\r\nTranscript written on Haddock.log.\r\n}}}\r\n\r\n[https://tex.stackexchange.com/a/378643 This StackExchange post] that Matthew pointed me to gives a clue as to as why this happens.\r\n\r\n---\r\n\r\nI am going to comment out the `need`s that make us produce these files in Hadrian when we ask for the docs, for now, leaving a comment pointing to this ticket. Then as we figure out solutions to these issues (especially 2), since that's GHC's CI system), we can put those PDFs back in and mark this ticket as solved.","type_of_failure":"OtherFailure","blocking":[]} -->Make removalhttps://gitlab.haskell.org/ghc/ghc/-/issues/15919Deprecate split objects2022-11-29T08:49:16ZBen GamariDeprecate split objectsFor several reasons (see below) we now generally recommend users use split sections instead of split objects.
Reasons:
- SplitSections is quite a bit simpler
- SplitSections may produce smaller binaries
- SplitSections requires fewer a...For several reasons (see below) we now generally recommend users use split sections instead of split objects.
Reasons:
- SplitSections is quite a bit simpler
- SplitSections may produce smaller binaries
- SplitSections requires fewer assembler invocations, potentially improving compilation time (see #11285, #15051)
- SplitSections is the approach used by most C compilers, meaning we may avoid edge cases that SplitObjects may turn up
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Deprecate split objects","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"For several reasons (see below) we now generally recommend users use split sections instead of split objects.\r\n\r\nReasons:\r\n * SplitSections is quite a bit simpler\r\n * SplitSections may produce smaller binaries\r\n * SplitSections requires fewer assembler invocations, potentially improving compilation time (see #11285, #15051)\r\n * SplitSections is the approach used by most C compilers, meaning we may avoid edge cases that SplitObjects may turn up\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9671Allow expressions in patterns2022-11-25T17:59:31ZIcelandjackAllow expressions in patternsI've outlined a proposal for extending pattern synonyms to depend on terms (PatternFamilies), the name is less than ideal but I'll keep the page under that name for now. The proposal's introduction has been rewritten.
The simplest use c...I've outlined a proposal for extending pattern synonyms to depend on terms (PatternFamilies), the name is less than ideal but I'll keep the page under that name for now. The proposal's introduction has been rewritten.
The simplest use case are patterns that matches only when a set contains an element (`IsMember`) or when a set does not contain an element (`NotMember`):
\[\[Image(wiki:PatternFamilies:member.png)\]\]
```hs
hasKeys :: Set Item -> IO ()
hasKeys (IsMember "keys") = leaveHouse
hasKeys (NotMember "keys") = findKeys >> leaveHouse
```
or a pattern that matches a map if the key exists:
\[\[Image(wiki:PatternFamilies:lookup.png)\]\]
used like this:
```hs
age :: Map Person Age -> String
age (Lookup "Alice" 60) = "Alice is 60 years old!"
age (Lookup "Alice" age) = "Alice is " ++ show age ++ "."
age (Lookup "Bob" _) = "No info on Alice but we know how old Bob is."
age _ = "..."
```
Further details and examples can be found here: PatternFamilies, I discussed it with several people ICFP 2014. This would not require a new extension but would extend PatternSynonyms. This feature can be quite useful, especially when working with deeply nested structures (ASTs, JSON, XML, ...).
If people are fine with it I will implement it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow expressions in patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["pattern","patterns,","synonyms"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I've outlined a proposal for extending pattern synonyms to depend on terms (PatternFamilies), the name is less than ideal but I'll keep the page under that name for now. The proposal's introduction has been rewritten.\r\n\r\nThe simplest use case are patterns that matches only when a set contains an element (`IsMember`) or when a set does not contain an element (`NotMember`):\r\n\r\n[[Image(wiki:PatternFamilies:member.png)]]\r\n\r\n{{{#!hs\r\n hasKeys :: Set Item -> IO ()\r\n hasKeys (IsMember \"keys\") = leaveHouse\r\n hasKeys (NotMember \"keys\") = findKeys >> leaveHouse\r\n}}}\r\n\r\nor a pattern that matches a map if the key exists:\r\n\r\n[[Image(wiki:PatternFamilies:lookup.png)]]\r\n\r\nused like this:\r\n\r\n{{{#!hs\r\n age :: Map Person Age -> String\r\n age (Lookup \"Alice\" 60) = \"Alice is 60 years old!\"\r\n age (Lookup \"Alice\" age) = \"Alice is \" ++ show age ++ \".\"\r\n age (Lookup \"Bob\" _) = \"No info on Alice but we know how old Bob is.\"\r\n age _ = \"...\"\r\n}}}\r\n\r\nFurther details and examples can be found here: PatternFamilies, I discussed it with several people ICFP 2014. This would not require a new extension but would extend PatternSynonyms. This feature can be quite useful, especially when working with deeply nested structures (ASTs, JSON, XML, ...).\r\n\r\nIf people are fine with it I will implement it.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/13406IO hack in demand analyzer can miss I/O2022-11-24T23:09:44ZDavid FeuerIO hack in demand analyzer can miss I/OIf someone digs into the `IO` type, they could (with good reason, even!) decide that they want to produce something other than an unboxed pair. Here's an example, imitating `StateT st IO a` in a way that's sure to be unboxed well:
```hs...If someone digs into the `IO` type, they could (with good reason, even!) decide that they want to produce something other than an unboxed pair. Here's an example, imitating `StateT st IO a` in a way that's sure to be unboxed well:
```hs
newtype IOState st a = IOState
{ unIOState :: State# RealWorld
-> st
-> (# State# RealWorld, st, a #) }
```
This won't trip `io_hack_reqd`, so demand analysis won't see it as I/O, and everything will be wrong. Urk. Furthermore, in the future, we may allow newtypes around unlifted types, in which case this stuff gets even messier.
<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 | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"IO hack in demand analyzer can miss I/O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If someone digs into the `IO` type, they could (with good reason, even!) decide that they want to produce something other than an unboxed pair. Here's an example, imitating `StateT st IO a` in a way that's sure to be unboxed well:\r\n\r\n{{{#!hs\r\nnewtype IOState st a = IOState\r\n { unIOState :: State# RealWorld\r\n -> st\r\n -> (# State# RealWorld, st, a #) }\r\n}}}\r\n\r\nThis won't trip `io_hack_reqd`, so demand analysis won't see it as I/O, and everything will be wrong. Urk. Furthermore, in the future, we may allow newtypes around unlifted types, in which case this stuff gets even messier.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3629Code compiled WITHOUT profiling many times slower than compiled WITH profilin...2022-11-24T23:09:44ZgchrupalaCode compiled WITHOUT profiling many times slower than compiled WITH profiling onI have a program which runs extremely slow when I compile it with profiling disabled. It only becomes usable when compiled with profiling options on (-prof -auto-all).
I reproduced it with GHC 6.10, 6.12 and 6.13.
The source is attache...I have a program which runs extremely slow when I compile it with profiling disabled. It only becomes usable when compiled with profiling options on (-prof -auto-all).
I reproduced it with GHC 6.10, 6.12 and 6.13.
The source is attached.
I compiled and ran like this:
```
ghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp
time ./runST > /dev/null
real 5m9.670s
user 5m7.627s
sys 0m0.468s
ghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp -prof -auto-all
real 0m39.544s
user 0m39.050s
sys 0m0.148s
```
In the meantime, is there is a workaround other than compiling with profiling options on? I would prefer to modify the source rather than ask users to install profiling libraries and mess with compiler options.
Best,
--
Grzegorz Chrupala
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.13 |
| 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":"Code compiled WITHOUT profiling many times slower than compiled WITH profiling on","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a program which runs extremely slow when I compile it with profiling disabled. It only becomes usable when compiled with profiling options on (-prof -auto-all).\r\n\r\nI reproduced it with GHC 6.10, 6.12 and 6.13.\r\n\r\nThe source is attached.\r\n\r\nI compiled and ran like this:\r\n\r\n{{{\r\nghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp\r\ntime ./runST > /dev/null\r\nreal\t5m9.670s\r\nuser\t5m7.627s\r\nsys\t0m0.468s\r\n\r\nghc-6.13.20091027 --make -O2 runST.hs -fforce-recomp -prof -auto-all\r\nreal\t0m39.544s\r\nuser\t0m39.050s\r\nsys\t0m0.148s\r\n}}}\r\n\r\nIn the meantime, is there is a workaround other than compiling with profiling options on? I would prefer to modify the source rather than ask users to install profiling libraries and mess with compiler options.\r\n\r\nBest,\r\n\r\n--\r\nGrzegorz Chrupala\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3549unlit does not follow H98 spec2022-11-22T21:31:38Zduncanunlit does not follow H98 specThe Haskell 98 spec has this to say about the [Latex \\begin{code} \\end{code}](http://haskell.org/onlinereport/syntax-iso.html) style:
> An alternative style of literate programming is particularly suitable for use with the LaTeX text...The Haskell 98 spec has this to say about the [Latex \\begin{code} \\end{code}](http://haskell.org/onlinereport/syntax-iso.html) style:
> An alternative style of literate programming is particularly suitable for use with the LaTeX text processing system. In this convention, only those parts of the literate program that are entirely enclosed between \\begin{code}...\\end{code} delimiters are treated as program text; all other lines are comment. More precisely:
- Program code begins on the first line following a line that begins \\begin{code}.
- Program code ends just before a subsequent line that begins \\end{code} (ignoring string literals, of course).
The key phrases are "a line that begins \\begin{code}" and "line that begins \\end{code}". This means the semantics is something like:
```
classifyLine s
| "\\begin{code}" `isPrefixOf` s = BeginCode
| "\\end{code}" `isPrefixOf` s = EndCode
```
GHC's `unlit` C program uses:
```
if (strcmp(buf, "\\begin{code}") == 0)
return BEGIN;
```
The equivalent semantics in the style above would be:
```
classifyLine s
| "\\begin{code}" == s = BeginCode
| "\\end{code}" == s = EndCode
```
It seems fairly clear from the spec that GHC's unlit program is wrong in this respect.
The practical consequence is that Cabal's unlit and GHC's one do not match and this [catches people out](http://haskell.org/pipermail/haskell-cafe/2009-September/066780.html). There is [explicit advice on the Haskell wiki](http://www.haskell.org/haskellwiki/Literate_programming#Hiding_code_from_Haskell) recommending that people take advantage of this GHC bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"unlit does not follow H98 spec","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Haskell 98 spec has this to say about the [http://haskell.org/onlinereport/syntax-iso.html Latex \\begin{code} \\end{code}] style:\r\n\r\n An alternative style of literate programming is particularly suitable for use with the LaTeX text processing system. In this convention, only those parts of the literate program that are entirely enclosed between \\begin{code}...\\end{code} delimiters are treated as program text; all other lines are comment. More precisely:\r\n\r\n * Program code begins on the first line following a line that begins \\begin{code}.\r\n * Program code ends just before a subsequent line that begins \\end{code} (ignoring string literals, of course).\r\n\r\nThe key phrases are \"a line that begins \\begin{code}\" and \"line that begins \\end{code}\". This means the semantics is something like:\r\n\r\n{{{\r\nclassifyLine s\r\n | \"\\\\begin{code}\" `isPrefixOf` s = BeginCode\r\n | \"\\\\end{code}\" `isPrefixOf` s = EndCode\r\n}}}\r\n\r\nGHC's `unlit` C program uses:\r\n\r\n{{{\r\n if (strcmp(buf, \"\\\\begin{code}\") == 0)\r\n return BEGIN;\r\n}}}\r\n\r\nThe equivalent semantics in the style above would be:\r\n{{{\r\nclassifyLine s\r\n | \"\\\\begin{code}\" == s = BeginCode\r\n | \"\\\\end{code}\" == s = EndCode\r\n}}}\r\n\r\nIt seems fairly clear from the spec that GHC's unlit program is wrong in this respect.\r\n\r\nThe practical consequence is that Cabal's unlit and GHC's one do not match and this [http://haskell.org/pipermail/haskell-cafe/2009-September/066780.html catches people out]. There is [http://www.haskell.org/haskellwiki/Literate_programming#Hiding_code_from_Haskell explicit advice on the Haskell wiki] recommending that people take advantage of this GHC bug.","type_of_failure":"OtherFailure","blocking":[]} -->Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/11827InteractiveEval error handling gets a boot ModSummary instead of normal ModSu...2022-11-22T03:37:56ZdarchonInteractiveEval error handling gets a boot ModSummary instead of normal ModSummaryGiven:
A.hs
```hs
module A where
data A = A
f :: A -> Bool
f C = False
```
A.hs-boot
```hs
module A where
data A
f :: A -> Bool
```
B.hs
```hs
module B where
import {-# SOURCE #-} A
data B = B A
g :: B -> Bool
g (B a) = f a
...Given:
A.hs
```hs
module A where
data A = A
f :: A -> Bool
f C = False
```
A.hs-boot
```hs
module A where
data A
f :: A -> Bool
```
B.hs
```hs
module B where
import {-# SOURCE #-} A
data B = B A
g :: B -> Bool
g (B a) = f a
```
ghci reports:
```
$ ghci B.hs
GHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/ :? for help
[1 of 3] Compiling A[boot] ( A.hs-boot, interpreted )
[2 of 3] Compiling A ( A.hs, interpreted )
A.hs:6:3: error: Not in scope: data constructor ‘C’
*** Exception: expectJust showModule
CallStack (from HasCallStack):
error, called at compiler/utils/Maybes.hs:48:27 in ghc:Maybes
>
```
So instead of a normal error telling me that the C constructor does not exist, I get an additional exception from expectJust because something went wrong in GHCs internal error reporting routine.
Looking at https://github.com/ghc/ghc/blob/master/compiler/main/InteractiveEval.hs\#L956, the expectJust exception is due to the fact that while reporting an error about A.hs, GHCi somehow got a hold of the ModSummary of A.hs-boot instead of A.hs
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1-rc3 |
| 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":"InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Given:\r\n\r\nA.hs\r\n{{{#!hs\r\nmodule A where\r\n\r\ndata A = A\r\n\r\nf :: A -> Bool\r\nf C = False\r\n}}}\r\n\r\nA.hs-boot\r\n{{{#!hs\r\nmodule A where\r\n\r\ndata A\r\n\r\nf :: A -> Bool\r\n}}}\r\n\r\nB.hs\r\n{{{#!hs\r\nmodule B where\r\n\r\nimport {-# SOURCE #-} A\r\n\r\ndata B = B A\r\n\r\ng :: B -> Bool\r\ng (B a) = f a\r\n}}}\r\n\r\nghci reports:\r\n\r\n{{{\r\n$ ghci B.hs\r\nGHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/ :? for help\r\n[1 of 3] Compiling A[boot] ( A.hs-boot, interpreted )\r\n[2 of 3] Compiling A ( A.hs, interpreted )\r\n\r\nA.hs:6:3: error: Not in scope: data constructor ‘C’\r\n*** Exception: expectJust showModule\r\nCallStack (from HasCallStack):\r\n error, called at compiler/utils/Maybes.hs:48:27 in ghc:Maybes\r\n> \r\n}}}\r\n\r\nSo instead of a normal error telling me that the C constructor does not exist, I get an additional exception from expectJust because something went wrong in GHCs internal error reporting routine.\r\n\r\nLooking at https://github.com/ghc/ghc/blob/master/compiler/main/InteractiveEval.hs#L956, the expectJust exception is due to the fact that while reporting an error about A.hs, GHCi somehow got a hold of the ModSummary of A.hs-boot instead of A.hs","type_of_failure":"OtherFailure","blocking":[]} -->Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/16014Avoid unnecessary code duplication from String Literals.2022-11-22T03:33:52ZAndreas KlebingerAvoid unnecessary code duplication from String Literals.When we compile a function like this:
```
foo :: Int -> String
foo 1 = "1_String"
foo 2 = "2_String"
foo 3 = "3_String"
foo 4 = "4_String"
foo 5 = "5_String"
foo _ = "unknown_string"
```
We get a few things.
Obviously there are the ac...When we compile a function like this:
```
foo :: Int -> String
foo 1 = "1_String"
foo 2 = "2_String"
foo 3 = "3_String"
foo 4 = "4_String"
foo 5 = "5_String"
foo _ = "unknown_string"
```
We get a few things.
Obviously there are the actual strings:
```
-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}
Foo.foo10 :: GHC.Prim.Addr#
Foo.foo10 = "1_String"#
```
There is no way around these so that's fine.
Then we end up with a function to unpack the actual string.
```
-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0}
Foo.foo9 :: [Char]
[GblId,
Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=True,
WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}]
Foo.foo9 = GHC.CString.unpackCString# Foo.foo10
```
We want to have a closure for each of these. Otherwise we end up constructing a new string each time, which would be a waste. So on the surface this is fine.
However we end up with one of these for each string.
Looking at the Cmm/Asm the functions are not THAT small.
```
[Foo.foo9_entry() // [R1]
{ info_tbls: [(c2hj,
label: Foo.foo9_info
rep: HeapRep static { Thunk }
srt: Nothing)]
stack_info: arg_space: 8 updfr_space: Just 8
}
{offset
c2hj: // global
if ((Sp + -16) < SpLim) (likely: False) goto c2hk; else goto c2hl;
c2hk: // global
R1 = R1;
call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8;
c2hl: // global
(_c2hg::I64) = call "ccall" arg hints: [PtrHint,
PtrHint] result hints: [PtrHint] newCAF(BaseReg, R1);
if (_c2hg::I64 == 0) goto c2hi; else goto c2hh;
c2hi: // global
call (I64[R1])() args: 8, res: 0, upd: 8;
c2hh: // global
I64[Sp - 16] = stg_bh_upd_frame_info;
I64[Sp - 8] = _c2hg::I64;
R2 = Foo.foo10_bytes;
Sp = Sp - 16;
call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24;
}
}
```
In actual code size (HEAD/-O2) the code + info table is about 100Byte.
To give an idea in my current ghc-stage2 I have 12,409 calls to unpackCString, and I assume 99% of them are from actual strings. So that comes out to about one megabyte. Out of a binary size of 84MB, so surprisingly significant actually!
## Now what can we do about this!
I think the right way to go here is to define a `unpackString` function which does the actual work.
Then we jump into that from a small per-string wrapper.
So we would end up with code like:
```
[Foo.foo9_entry() // [R1]
c2hj:
// R1 = Closure pointer
R2 = Foo.foo10_bytes;
call (unpackString)(R1,R2) args: 8, res: 0, upd: 8;
}
```
Which should be well under 50 bytes. It does cause an extra indirection when unpacking the String, but if the performance of that matters using String is likely the wrong choice to begin with.
How to actually get GHC to generate code like that I'm not sure yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Avoid unnecessary code duplication from String Literals.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"When we compile a function like this:\r\n\r\n{{{\r\nfoo :: Int -> String\r\nfoo 1 = \"1_String\"\r\nfoo 2 = \"2_String\"\r\nfoo 3 = \"3_String\"\r\nfoo 4 = \"4_String\"\r\nfoo 5 = \"5_String\"\r\nfoo _ = \"unknown_string\"\r\n}}}\r\n\r\nWe get a few things.\r\n\r\nObviously there are the actual strings:\r\n{{{\r\n-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}\r\nFoo.foo10 :: GHC.Prim.Addr#\r\nFoo.foo10 = \"1_String\"#\r\n}}}\r\nThere is no way around these so that's fine.\r\n\r\nThen we end up with a function to unpack the actual string.\r\n{{{\r\n-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0}\r\nFoo.foo9 :: [Char]\r\n[GblId,\r\n Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=True,\r\n WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}]\r\nFoo.foo9 = GHC.CString.unpackCString# Foo.foo10\r\n}}}\r\nWe want to have a closure for each of these. Otherwise we end up constructing a new string each time, which would be a waste. So on the surface this is fine.\r\nHowever we end up with one of these for each string.\r\n\r\nLooking at the Cmm/Asm the functions are not THAT small.\r\n{{{\r\n[Foo.foo9_entry() // [R1]\r\n { info_tbls: [(c2hj,\r\n label: Foo.foo9_info\r\n rep: HeapRep static { Thunk }\r\n srt: Nothing)]\r\n stack_info: arg_space: 8 updfr_space: Just 8\r\n }\r\n {offset\r\n c2hj: // global\r\n if ((Sp + -16) < SpLim) (likely: False) goto c2hk; else goto c2hl;\r\n c2hk: // global\r\n R1 = R1;\r\n call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8;\r\n c2hl: // global\r\n (_c2hg::I64) = call \"ccall\" arg hints: [PtrHint,\r\n PtrHint] result hints: [PtrHint] newCAF(BaseReg, R1);\r\n if (_c2hg::I64 == 0) goto c2hi; else goto c2hh;\r\n c2hi: // global\r\n call (I64[R1])() args: 8, res: 0, upd: 8;\r\n c2hh: // global\r\n I64[Sp - 16] = stg_bh_upd_frame_info;\r\n I64[Sp - 8] = _c2hg::I64;\r\n R2 = Foo.foo10_bytes;\r\n Sp = Sp - 16;\r\n call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24;\r\n }\r\n }\r\n}}}\r\nIn actual code size (HEAD/-O2) the code + info table is about 100Byte.\r\n\r\nTo give an idea in my current ghc-stage2 I have 12,409 calls to unpackCString, and I assume 99% of them are from actual strings. So that comes out to about one megabyte. Out of a binary size of 84MB, so surprisingly significant actually!\r\n\r\n== Now what can we do about this!\r\n\r\nI think the right way to go here is to define a `unpackString` function which does the actual work.\r\nThen we jump into that from a small per-string wrapper.\r\n\r\nSo we would end up with code like:\r\n{{{\r\n[Foo.foo9_entry() // [R1]\r\n c2hj: \r\n // R1 = Closure pointer\r\n R2 = Foo.foo10_bytes;\r\n call (unpackString)(R1,R2) args: 8, res: 0, upd: 8;\r\n }\r\n}}}\r\n\r\nWhich should be well under 50 bytes. It does cause an extra indirection when unpacking the String, but if the performance of that matters using String is likely the wrong choice to begin with.\r\n\r\nHow to actually get GHC to generate code like that I'm not sure yet.\r\n\r\n\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->9.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/14343bad pretty-printing of types with promoted data types2022-11-20T11:46:11Zlspitznerbad pretty-printing of types with promoted data types```
> :set -XDataKinds
> :set -XPolyKinds
> data Proxy k = Proxy
> _ :: Proxy '[ 'True ]
error:
Found hole: _ :: Proxy '['True]
> _ :: Proxy '['True]
error:
Invalid type signature: _ :: ...
Should be of form <variab...```
> :set -XDataKinds
> :set -XPolyKinds
> data Proxy k = Proxy
> _ :: Proxy '[ 'True ]
error:
Found hole: _ :: Proxy '['True]
> _ :: Proxy '['True]
error:
Invalid type signature: _ :: ...
Should be of form <variable> :: <type>
```
Alternatively, this could be attributed to the parser/lexer doing an insufficient job there.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"bad pretty-printing of types with promoted data types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n> :set -XDataKinds\r\n> :set -XPolyKinds\r\n> data Proxy k = Proxy\r\n> _ :: Proxy '[ 'True ]\r\nerror:\r\n Found hole: _ :: Proxy '['True]\r\n> _ :: Proxy '['True]\r\nerror:\r\n Invalid type signature: _ :: ...\r\n Should be of form <variable> :: <type>\r\n}}}\r\n\r\nAlternatively, this could be attributed to the parser/lexer doing an insufficient job there.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Andreas HerrmannAndreas Herrmannhttps://gitlab.haskell.org/ghc/ghc/-/issues/15680Flag for printing absolute paths in diagnostics2022-11-20T11:19:42ZquasicomputationalFlag for printing absolute paths in diagnosticsCurrently, GHC will produce errors and warnings with relative paths pointing to the input that caused it.
This is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in ...Currently, GHC will produce errors and warnings with relative paths pointing to the input that caused it.
This is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in different working directories and interleave the output from multiple GHC invocations.
In particular, this makes using `next-error` in emacs a lot less useful than it could be with cabal-install's output.
[Stack has some rather hackish code to post-process the diagnostics and to turn the relative paths absolute.](https://github.com/commercialhaskell/stack/blob/0740444175f41e6ea5ed236cd2c53681e4730003/src/Stack/Build/Execute.hs#L1896) I can personally report that this makes the development process a lot more pleasant!
I think it'd be much cleaner to have a GHC flag for this at the source. `-fabsolute-diagnostic-paths` or something similar, subject to bikeshedding.
I had a look at implementing this myself, and `mkLocMessageAnn` in `ErrUtils` would be the locus of the change. However, I can't figure out how that function should learn what the current working directory is! Any tips? Is that information lurking somewhere in `DynFlags`?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"Flag for printing absolute paths in diagnostics","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, GHC will produce errors and warnings with relative paths pointing to the input that caused it.\r\n\r\nThis is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in different working directories and interleave the output from multiple GHC invocations.\r\n\r\nIn particular, this makes using `next-error` in emacs a lot less useful than it could be with cabal-install's output.\r\n\r\n[https://github.com/commercialhaskell/stack/blob/0740444175f41e6ea5ed236cd2c53681e4730003/src/Stack/Build/Execute.hs#L1896 Stack has some rather hackish code to post-process the diagnostics and to turn the relative paths absolute.] I can personally report that this makes the development process a lot more pleasant!\r\n\r\nI think it'd be much cleaner to have a GHC flag for this at the source. `-fabsolute-diagnostic-paths` or something similar, subject to bikeshedding.\r\n\r\nI had a look at implementing this myself, and `mkLocMessageAnn` in `ErrUtils` would be the locus of the change. However, I can't figure out how that function should learn what the current working directory is! Any tips? Is that information lurking somewhere in `DynFlags`?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/7245INLINEing top-level patterns causes ghc to emit 'arity missing' traces2022-11-20T00:52:38ZjwlatoINLINEing top-level patterns causes ghc to emit 'arity missing' tracesWhen an INLINE pragma is specified on a pattern, ghc-7.6.1 shows some internal trace messages.
```
module Foo where
{-# INLINE widths #-}
widths :: [Int]
widthMonth, widthYear :: Int
widths@[widthMonth, widthYear] = [1,2]
```
```
~/...When an INLINE pragma is specified on a pattern, ghc-7.6.1 shows some internal trace messages.
```
module Foo where
{-# INLINE widths #-}
widths :: [Int]
widthMonth, widthYear :: Int
widths@[widthMonth, widthYear] = [1,2]
```
```
~/Downloads$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.1
~/Downloads$ ghc Foo.hs -O
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
makeCorePair: arity missing widths{v aeJ} [lid]
```
I'm not certain that specifying an INLINE pragma in this context even makes sense, in which case perhaps a more useful warning could be produced.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | jwlato@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"INLINEing top-level patterns causes ghc to emit 'arity missing' traces","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["jwlato@gmail.com"],"type":"Bug","description":"When an INLINE pragma is specified on a pattern, ghc-7.6.1 shows some internal trace messages.\r\n\r\n{{{\r\nmodule Foo where\r\n\r\n{-# INLINE widths #-}\r\n\r\nwidths :: [Int]\r\nwidthMonth, widthYear :: Int\r\n\r\nwidths@[widthMonth, widthYear] = [1,2]\r\n}}}\r\n\r\n{{{\r\n~/Downloads$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.6.1\r\n~/Downloads$ ghc Foo.hs -O\r\n[1 of 1] Compiling Foo ( Foo.hs, Foo.o )\r\nmakeCorePair: arity missing widths{v aeJ} [lid]\r\n}}}\r\n\r\nI'm not certain that specifying an INLINE pragma in this context even makes sense, in which case perhaps a more useful warning could be produced.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/13894isByteArrayPinned# should consider BF_LARGE2022-11-18T13:57:09ZwinterisByteArrayPinned# should consider BF_LARGEFirst of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray\#/MutableByteArray\#' is movable during safe FFI call, isn't it?
If that is the case, then the code for `stg_isByteArrayPinnedzh` ...First of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray\#/MutableByteArray\#' is movable during safe FFI call, isn't it?
If that is the case, then the code for `stg_isByteArrayPinnedzh` is not enough, since not only bytes marked with `BF_PINNED` flag is not movable, but also the bytes which is marked with `BF_LARGE`. (I read the gc code and i'm confident this holds, but if it's not, please correct me).
Currently i'm using a FFI trick[https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c\#L33](https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c#L33) to get `isByteArrayPinned#` on older GHCs, i want to make sure if `BF_LARGE` works.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"isByteArrayPinned# should consider BF_LARGE","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First of all, i want to make sure `isByteArrayPinned#` is intended to let user know if a given 'ByteArray#/MutableByteArray#' is movable during safe FFI call, isn't it?\r\n\r\nIf that is the case, then the code for `stg_isByteArrayPinnedzh` is not enough, since not only bytes marked with `BF_PINNED` flag is not movable, but also the bytes which is marked with `BF_LARGE`. (I read the gc code and i'm confident this holds, but if it's not, please correct me).\r\n\r\nCurrently i'm using a FFI trick[https://github.com/winterland1989/stdio/blob/master/cbits/bytes.c#L33] to get `isByteArrayPinned#` on older GHCs, i want to make sure if `BF_LARGE` works.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/14762Foreign.Marshal.Pool functions use inefficient O(n) operations2022-11-18T09:42:21ZNiklas Hambüchenmail@nh2.meForeign.Marshal.Pool functions use inefficient O(n) operations`Foreign.Marshal.Pool` uses `Data.List.delete` and `Data.List.elem` to determine whether a pointer is already in the pool and to delete them, as a result of `newtype Pool = Pool (IORef [Ptr ()])`.
Thus repeated operations on pools with ...`Foreign.Marshal.Pool` uses `Data.List.delete` and `Data.List.elem` to determine whether a pointer is already in the pool and to delete them, as a result of `newtype Pool = Pool (IORef [Ptr ()])`.
Thus repeated operations on pools with many entries can become very slow.
If possible, we might consider using `Ord` on the `Ptr` and an O(log n) data structure instead of a `[Ptr]` list.
Alternatively, we should warn in the docs that this is the case, but it seems better to just fix the implementation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Foreign.Marshal.Pool functions use inefficient O(n) operations","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Bug","description":"`Foreign.Marshal.Pool` uses `Data.List.delete` and `Data.List.elem` to determine whether a pointer is already in the pool and to delete them, as a result of `newtype Pool = Pool (IORef [Ptr ()])`.\r\n\r\nThus repeated operations on pools with many entries can become very slow.\r\n\r\nIf possible, we might consider using `Ord` on the `Ptr` and an O(log n) data structure instead of a `[Ptr]` list.\r\n\r\nAlternatively, we should warn in the docs that this is the case, but it seems better to just fix the implementation.","type_of_failure":"OtherFailure","blocking":[]} -->Tao Hesighingnow@gmail.comTao Hesighingnow@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/915Implement list fusion using streams instead of foldr/build2022-11-15T13:03:53ZSimon Peyton JonesImplement list fusion using streams instead of foldr/buildWe'd like to try using the stream-fusion idea of Don Stewart, Duncan Coutts and Roman Leshchinskiy, and replace the (somewhat fragile) foldr/build stuff.
See #876.
<details><summary>Trac metadata</summary>
| Trac field | V...We'd like to try using the stream-fusion idea of Don Stewart, Duncan Coutts and Roman Leshchinskiy, and replace the (somewhat fragile) foldr/build stuff.
See #876.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.2 |
| Type | Task |
| 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":"Implement list fusion using streams instead of foldr/build","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"We'd like to try using the stream-fusion idea of Don Stewart, Duncan Coutts and Roman Leshchinskiy, and replace the (somewhat fragile) foldr/build stuff.\r\n\r\nSee #876.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/855Improvements to SpecConstr2022-11-12T16:00:03ZSimon Peyton JonesImprovements to SpecConstrThere are a series of possible improvemnts to SpecConstr, described in
the source code. `compiler/specialise/SpecConstr`
- Specialising for constant parameters
- Specialising for lambda parameters
- Two ideas to do with strictness that ...There are a series of possible improvemnts to SpecConstr, described in
the source code. `compiler/specialise/SpecConstr`
- Specialising for constant parameters
- Specialising for lambda parameters
- Two ideas to do with strictness that look more tricky
Some of them look quite straightforward.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| 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":"Improvements to SpecConstr","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"There are a series of possible improvemnts to SpecConstr, described in \r\nthe source code. {{{compiler/specialise/SpecConstr}}}\r\n\r\n * Specialising for constant parameters\r\n * Specialising for lambda parameters\r\n * Two ideas to do with strictness that look more tricky\r\n\r\nSome of them look quite straightforward.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5444Slow 64-bit primops on 32 bit system2022-11-02T16:24:07ZKhudyakovSlow 64-bit primops on 32 bit systemGHC primops for 64-bit arithmetic are implemented as FFI calls. It leads to serious performance penalty for 32 bit code which heavily uses 64-bit arithmetics.
I found this while investigating poor performance of mwc-random on 32-bit sys...GHC primops for 64-bit arithmetic are implemented as FFI calls. It leads to serious performance penalty for 32 bit code which heavily uses 64-bit arithmetics.
I found this while investigating poor performance of mwc-random on 32-bit systems. 32-bit build runs 3-4 times slower than 64-bit build on the same hardware. It's difficult to estimate how faster would run optimal implementation since it doesn't exist. But it's probably at least 2x slowdown.
Here is simple program to demonstrate issue
```
sqr64 :: Int32 -> Int64
sqr64 x = y * y where y = fromIntegral x
```
Here is optimized core
```
$wsqr64 :: Int# -> Int64
$wsqr64 =
\ (ww_sGO :: Int#) ->
case {__pkg_ccall ghc-prim hs_intToInt64 Int#
-> State# RealWorld -> (# State# RealWorld, Int64# #)}_aFY
ww_sGO realWorld#
of _ { (# _, ds2_aG2 #) ->
case {__pkg_ccall ghc-prim hs_timesInt64 Int64#
-> Int64# -> State# RealWorld -> (# State# RealWorld, Int64# #)}_aGc
ds2_aG2 ds2_aG2 realWorld#
of _ { (# _, ds4_aGi #) ->
I64# ds4_aGi
}
}
sqr64 :: Int32 -> Int64
sqr64 = \ (w_sGM :: Int32) ->
case w_sGM of _ { I32# ww_sGO -> $wsqr64 ww_sGO }
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.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":"Slow 64-bit primops on 32 bit system","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC primops for 64-bit arithmetic are implemented as FFI calls. It leads to serious performance penalty for 32 bit code which heavily uses 64-bit arithmetics.\r\n\r\nI found this while investigating poor performance of mwc-random on 32-bit systems. 32-bit build runs 3-4 times slower than 64-bit build on the same hardware. It's difficult to estimate how faster would run optimal implementation since it doesn't exist. But it's probably at least 2x slowdown.\r\n\r\n\r\nHere is simple program to demonstrate issue\r\n{{{\r\nsqr64 :: Int32 -> Int64\r\nsqr64 x = y * y where y = fromIntegral x\r\n}}}\r\n\r\nHere is optimized core\r\n{{{\r\n$wsqr64 :: Int# -> Int64\r\n$wsqr64 =\r\n \\ (ww_sGO :: Int#) ->\r\n case {__pkg_ccall ghc-prim hs_intToInt64 Int#\r\n -> State# RealWorld -> (# State# RealWorld, Int64# #)}_aFY\r\n ww_sGO realWorld#\r\n of _ { (# _, ds2_aG2 #) ->\r\n case {__pkg_ccall ghc-prim hs_timesInt64 Int64#\r\n -> Int64# -> State# RealWorld -> (# State# RealWorld, Int64# #)}_aGc\r\n ds2_aG2 ds2_aG2 realWorld#\r\n of _ { (# _, ds4_aGi #) ->\r\n I64# ds4_aGi\r\n }\r\n }\r\n\r\nsqr64 :: Int32 -> Int64\r\nsqr64 = \\ (w_sGM :: Int32) ->\r\n case w_sGM of _ { I32# ww_sGO -> $wsqr64 ww_sGO }\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/16173Move `Data.Profunctor` from `profunctors` package to `base`2022-11-02T12:30:09ZDmitrii KovanikovMove `Data.Profunctor` from `profunctors` package to `base``Contravariant` was added in GHC 8.6.
- https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Functor-Contravariant.html
`Profunctor` also looks like fundamental abstraction to be worth considering adding to `base`.
Having both ...`Contravariant` was added in GHC 8.6.
- https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Functor-Contravariant.html
`Profunctor` also looks like fundamental abstraction to be worth considering adding to `base`.
Having both `Profunctor` and `Choice` typeclasses in the `base` library will also allow to write `microprism` package similar to `microlens`. Prisms often turns to be very useful since they allow to work nicely with sum types.
```hs
type Prism s t a b = forall p f. (Choice p, Applicative f) => p a (f b) -> p s (f t)
```
Additional context for this ticket from Reddit:
- https://www.reddit.com/r/haskell/comments/8v53cb/announce_ghc_861alpha1_available/e1o1giy/
It was proposed on Reddit to use `QuantifiedConstraints` for `Profunctor`. I'm not quite fluent with `QuantifiedConstraints`, but I think this may looks like this (mostly copy-pasting code from `profunctors` package):
```hs
{-# LANGUAGE QuantifiedConstraints #-}
class (forall a . Functor (p a)) => Profunctor p where
{-# MINIMAL dimap | (lmap, rmap) #-}
dimap :: (a -> b) -> (c -> d) -> p b c -> p a d
dimap f g = lmap f . rmap g
lmap :: (a -> b) -> p b c -> p a c
lmap f = dimap f id
rmap :: (b -> c) -> p a b -> p a c
rmap = dimap id
instance Profunctor (->) where
dimap ab cd bc = cd . bc . ab
lmap = flip (.)
rmap = (.)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | andrewthad, ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Move `Data.Profunctor` from `profunctors` package to `base`","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["QuantifiedConstraints","base,","profunctor,"],"differentials":[],"test_case":"","architecture":"","cc":["andrewthad","ekmett"],"type":"FeatureRequest","description":"`Contravariant` was added in GHC 8.6. \r\n\r\n* https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Functor-Contravariant.html\r\n\r\n`Profunctor` also looks like fundamental abstraction to be worth considering adding to `base`. \r\n\r\nHaving both `Profunctor` and `Choice` typeclasses in the `base` library will also allow to write `microprism` package similar to `microlens`. Prisms often turns to be very useful since they allow to work nicely with sum types.\r\n\r\n{{{#!hs\r\ntype Prism s t a b = forall p f. (Choice p, Applicative f) => p a (f b) -> p s (f t)\r\n}}}\r\n\r\nAdditional context for this ticket from Reddit:\r\n\r\n* https://www.reddit.com/r/haskell/comments/8v53cb/announce_ghc_861alpha1_available/e1o1giy/\r\n\r\nIt was proposed on Reddit to use `QuantifiedConstraints` for `Profunctor`. I'm not quite fluent with `QuantifiedConstraints`, but I think this may looks like this (mostly copy-pasting code from `profunctors` package):\r\n\r\n{{{#!hs\r\n{-# LANGUAGE QuantifiedConstraints #-}\r\n\r\nclass (forall a . Functor (p a)) => Profunctor p where\r\n {-# MINIMAL dimap | (lmap, rmap) #-}\r\n\r\n dimap :: (a -> b) -> (c -> d) -> p b c -> p a d\r\n dimap f g = lmap f . rmap g\r\n\r\n lmap :: (a -> b) -> p b c -> p a c\r\n lmap f = dimap f id\r\n\r\n rmap :: (b -> c) -> p a b -> p a c\r\n rmap = dimap id\r\n\r\ninstance Profunctor (->) where\r\n dimap ab cd bc = cd . bc . ab\r\n lmap = flip (.)\r\n rmap = (.)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11350Allow visible type application in patterns2022-11-02T11:47:58ZIcelandjackAllow visible type application in patternsEDIT: Though this ticket predates the proposal, it is a good place to track its development: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0126-type-applications-in-patterns.rst
Constructors (and pattern synonyms)...EDIT: Though this ticket predates the proposal, it is a good place to track its development: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0126-type-applications-in-patterns.rst
Constructors (and pattern synonyms) when treated as expressions may be applied to types:
```hs
{-# LANGUAGE TypeApplications #-}
Nothing :: Maybe a
Nothing @() :: Maybe ()
pattern Pair :: a -> a -> (a, a)
pattern Pair x y = (x, y)
Pair :: a -> a -> (a, a)
Pair @Int :: Int -> Int -> (Int, Int)
```
But using them in patterns won't parse:
```hs
-- parse error in pattern: @Int
maybeToList :: Maybe Int -> [Int]
maybeToList (Nothing @Int) = []
maybeToList (Just @Int x) = [x]
-- parse error in pattern: @Int
add :: (Int, Int) -> Int
add (Pair @Int x y) = x + y
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow visible type application in patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":["PatternSynonyms","TypeApplications"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Constructors (and pattern synonyms) when treated as expressions may be applied to types:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeApplications #-}\r\n\r\nNothing :: Maybe a\r\nNothing @() :: Maybe ()\r\n\r\npattern Pair :: a -> a -> (a, a)\r\npattern Pair x y = (x, y)\r\n\r\nPair :: a -> a -> (a, a)\r\nPair @Int :: Int -> Int -> (Int, Int)\r\n}}}\r\n\r\nBut using them in patterns won't parse:\r\n\r\n{{{#!hs\r\n-- parse error in pattern: @Int\r\nmaybeToList :: Maybe Int -> [Int]\r\nmaybeToList (Nothing @Int) = []\r\nmaybeToList (Just @Int x) = [x]\r\n\r\n-- parse error in pattern: @Int\r\nadd :: (Int, Int) -> Int\r\nadd (Pair @Int x y) = x + y\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1