GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:39:47Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9619HPC Code Coverage complains when two exactly the same mix files are on the path2019-07-07T18:39:47ZKasperHPC Code Coverage complains when two exactly the same mix files are on the pathCabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in modul...Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.
This issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately.
Priority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HPC Code Coverage complains when two exactly the same mix files are on the path","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.\r\n\r\n\r\nThis issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately. \r\n\r\nPriority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9449GHC.Prim documentation says "Safe Inferred"2019-07-07T18:40:21ZRichard Eisenbergrae@richarde.devGHC.Prim documentation says "Safe Inferred"The Haddock docs for GHC.Prim (for example, [here](http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html)) says that it is Safe-Inferred. This is very bogus.
When testing, I was (happily) unable to import `GHC.Prim` in...The Haddock docs for GHC.Prim (for example, [here](http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html)) says that it is Safe-Inferred. This is very bogus.
When testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Prim documentation says \"Safe Inferred\"","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Haddock docs for GHC.Prim (for example, [http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html here]) says that it is Safe-Inferred. This is very bogus.\r\n\r\nWhen testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/9317Add PolyKinds extension to Data.Monoid2019-07-07T18:40:55ZbernalexAdd PolyKinds extension to Data.MonoidPolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: \<http://www.haskell.org/pipermail/libraries/2014-July/023261.html\>.
<details><summary>Trac metadata</summary>
| Trac field | Value ...PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: \<http://www.haskell.org/pipermail/libraries/2014-July/023261.html\>.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add PolyKinds extension to Data.Monoid","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: <http://www.haskell.org/pipermail/libraries/2014-July/023261.html>.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8873/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.s...2019-07-07T18:43:00Zconfigurator/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directoryThe paths used in the `ghcii.sh` scripts to start `ghc --interactive`
are incorrectly built using `"$0"/..`, which causes the message:
```
/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdriv...The paths used in the `ghcii.sh` scripts to start `ghc --interactive`
are incorrectly built using `"$0"/..`, which causes the message:
```
/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory
/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: exec: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: cannot execute: No such file or directory
```
I believe using `"$(dirname "$0")"` would be a portable solution that works under both cygwin and Linux versions of bash.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"The paths used in the {{{ghcii.sh}}} scripts to start {{{ghc --interactive}}}\r\n are incorrectly built using {{{\"$0\"/..}}}, which causes the message:\r\n\r\n{{{\r\n/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory\r\n/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: exec: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: cannot execute: No such file or directory\r\n}}}\r\n\r\nI believe using {{{\"$(dirname \"$0\")\"}}} would be a portable solution that works under both cygwin and Linux versions of bash.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5608Fix T3807 for Mac OS X 10.52019-07-07T18:54:29ZthorkilnaurFix T3807 for Mac OS X 10.5Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):
```
=====> T3807(normal) 591 of 3083 [0, 0, 1]
cd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr
Wro...Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):
```
=====> T3807(normal) 591 of 3083 [0, 0, 1]
cd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:
Failed to open shared library: dlopen(./T3807test.so, 10): Symbol not found: ___gmp_set_memory_functions
Referenced from: /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/bindisttest/install dir/lib/ghc-7.3.20111106/integer-gmp-0.3.0.0/libHSinteger-gmp-0.3.0.0-ghc7.3.20111106.dylib
Expected in: dynamic lookup
Stderr:
make[3]: *** [T3807] Error 1
*** unexpected failure for T3807(normal)
```
Validates on
```
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$
```
and
```
$ uname -a
Linux tn24 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:40:53 UTC 2011 i686 GNU/Linux
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$
```
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix T3807 for Mac OS X 10.5","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):\r\n{{{\r\n=====> T3807(normal) 591 of 3083 [0, 0, 1]\r\ncd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr\r\nWrong exit code (expected 0 , actual 2 )\r\nStdout:\r\nFailed to open shared library: dlopen(./T3807test.so, 10): Symbol not found: ___gmp_set_memory_functions\r\nReferenced from: /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/bindisttest/install dir/lib/ghc-7.3.20111106/integer-gmp-0.3.0.0/libHSinteger-gmp-0.3.0.0-ghc7.3.20111106.dylib\r\nExpected in: dynamic lookup\r\nStderr:\r\nmake[3]: *** [T3807] Error 1\r\n*** unexpected failure for T3807(normal)\r\n}}}\r\nValidates on\r\n{{{\r\n$ uname -a\r\nDarwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.3\r\n$ \r\n}}}\r\nand\r\n{{{\r\n$ uname -a\r\nLinux tn24 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:40:53 UTC 2011 i686 GNU/Linux\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.3\r\n$ \r\n}}}\r\nBest regards\r\nThorkil","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5190TinyCoreLinux extension2019-07-07T18:56:29Zjosemaria.alkalaTinyCoreLinux extensionI am trying to create a GHC package for TinyCoreLinux http://www.tinycorelinux.com (this is a 10Mbytes linux distribution)
I have downloaded the general binary:
http://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-unknown-linux.tar.bz2
Whe...I am trying to create a GHC package for TinyCoreLinux http://www.tinycorelinux.com (this is a 10Mbytes linux distribution)
I have downloaded the general binary:
http://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-unknown-linux.tar.bz2
When I execute: ./configure, I get:
checking for path to top of build tree... ghc-pwd: mkTextEncoding: invalid argument (Invalid argument)
configure: error: cannot determine current directory
As a disclaimer, I am not a developer!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | BuildingGhcFailed |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TinyCoreLinux extension","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am trying to create a GHC package for TinyCoreLinux http://www.tinycorelinux.com (this is a 10Mbytes linux distribution)\r\n\r\nI have downloaded the general binary:\r\nhttp://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-unknown-linux.tar.bz2\r\n\r\nWhen I execute: ./configure, I get:\r\nchecking for path to top of build tree... ghc-pwd: mkTextEncoding: invalid argument (Invalid argument)\r\nconfigure: error: cannot determine current directory\r\n\r\nAs a disclaimer, I am not a developer!","type_of_failure":"BuildingGhcFailed","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4896Deriving Data does not work for attached code2019-07-07T18:58:00ZmitarDeriving Data does not work for attached codeI get the following error when I try to derive `Data` for the attached code:
```
Main.hs:17:66:
Couldn't match expected type `Bar (D a b)'
with actual type `t' a1 b1'
Expected type: Maybe (c (Bar (D a b)))
...I get the following error when I try to derive `Data` for the attached code:
```
Main.hs:17:66:
Couldn't match expected type `Bar (D a b)'
with actual type `t' a1 b1'
Expected type: Maybe (c (Bar (D a b)))
Actual type: Maybe (c (t' a1 b1))
In the expression: gcast2 f
In an equation for `dataCast2': dataCast2 f = gcast2 f
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mmitar@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Deriving Data does not work for attached code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mmitar@gmail.com"],"type":"Bug","description":"I get the following error when I try to derive `Data` for the attached code:\r\n\r\n{{{\r\nMain.hs:17:66:\r\n Couldn't match expected type `Bar (D a b)'\r\n with actual type `t' a1 b1'\r\n Expected type: Maybe (c (Bar (D a b)))\r\n Actual type: Maybe (c (t' a1 b1))\r\n In the expression: gcast2 f\r\n In an equation for `dataCast2': dataCast2 f = gcast2 f\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4366in-tree GMP build problem with shared libraries2020-02-07T13:07:19ZSimon Marlowin-tree GMP build problem with shared librariesReported by Vivian McPhail \<haskell.vivian.mcphail\@gmail.com\> on glasgow-haskell-users:
```
Trying to build rc1 from source
linux x86_64
BuildFlavour = perf
It seems that the -fPIC flag is set, but an error still occurs (
/usr/bin/...Reported by Vivian McPhail \<haskell.vivian.mcphail\@gmail.com\> on glasgow-haskell-users:
```
Trying to build rc1 from source
linux x86_64
BuildFlavour = perf
It seems that the -fPIC flag is set, but an error still occurs (
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
)
"inplace/bin/ghc-stage1" -fPIC -dynamic -O -H64m -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.2 -package rts-1.0 -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/base/./Data/Typeable.hs-boot -o libraries/base/dist-install/build/Data/Typeable.dyn_o-boot
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
libraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.2-ghc7.0.0.20100924.so] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.13 |
| 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":"in-tree GMP build problem with shared libraries","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reported by Vivian McPhail <haskell.vivian.mcphail@gmail.com> on glasgow-haskell-users:\r\n\r\n{{{\r\nTrying to build rc1 from source\r\n\r\nlinux x86_64\r\nBuildFlavour = perf\r\n\r\nIt seems that the -fPIC flag is set, but an error still occurs (\r\n/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC\r\n)\r\n\r\n\"inplace/bin/ghc-stage1\" -fPIC -dynamic -O -H64m -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.2 -package rts-1.0 -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/base/./Data/Typeable.hs-boot -o libraries/base/dist-install/build/Data/Typeable.dyn_o-boot\r\n/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC\r\nlibraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value\r\ncollect2: ld returned 1 exit status\r\nmake[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.2-ghc7.0.0.20100924.so] Error 1\r\nmake[1]: *** Waiting for unfinished jobs....\r\nmake: *** [all] Error 2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4218System.Random is way too lazy2019-07-07T19:00:04ZEyalLotemSystem.Random is way too lazyrandomRs is too lazy, generates lists of large lazy-state thunks, rather than lists of strict values.
Test program is attached.
Also, randomIO is too lazy, and builds up huge thunks. Using (randomIO \>\>= evaluate) is fine, however.
F...randomRs is too lazy, generates lists of large lazy-state thunks, rather than lists of strict values.
Test program is attached.
Also, randomIO is too lazy, and builds up huge thunks. Using (randomIO \>\>= evaluate) is fine, however.
Fails with stack overflow:
```
rs <- replicateM 1000000 evaluate :: IO [Int]
print $ last rs
```
Works:
```
rs <- replicateM 1000000 (evaluate =<< randomIO) :: IO [Int]
print $ last rs
```7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3859Problems with toClockTime on NetBSD2019-07-07T19:01:49ZIan Lynagh <igloo@earth.li>Problems with toClockTime on NetBSDhttp://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says:
```
Got it: reproducing the crash (tough on such a slow machine where rebuilding
these things is quite the process, yay me):
<patch author='zooko@zooko.com'...http://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says:
```
Got it: reproducing the crash (tough on such a slow machine where rebuilding
these things is quite the process, yay me):
<patch author='zooko@zooko.com' date='20090308025039' local_date='Making
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2,
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName =
"GMT", ctTZ = 0, ctIsDST = False}
Plugging that into your first requested program:
import System.Time
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 50 39 0 Sunday 0 "GMT"
0 False
... returns:
t: user error (Time.toClockTime: invalid input)
So.. This suggests to me there are two problems. First, the toClockTime
function has trouble with certain input.
This fails:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 59 59 1000 Thursday
280 "BST" 3600 True
This succeeds:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 3 0 0 0 Thursday 280
"BST" 3600 True
Weird huh?
And then clearly, the second problem appears to be the conversion of the
datestamp in the following partial log entry:
<patch author='zooko@zooko.com' date='20090308025039' local_date='Making
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2,
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName =
"GMT", ctTZ = 0, ctIsDST = False}
(This is with a modified darcs with the printf-equivalent in it.)
This is suspiciously near to the DST switchover. If you need a zdump of my
current DST timings, I can provide the pre-zic entries.
Is there perhaps a DST switchover assumption in that logic?
Let me know if you'd like me to delve further. Hopefully this is enough to make
the problem clear to you darcs folks.
```
This really needs to be looked at by someone with access to NetBSD (or perhaps some similar OS).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Problems with toClockTime on NetBSD","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"http://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says:\r\n{{{\r\nGot it: reproducing the crash (tough on such a slow machine where rebuilding \r\nthese things is quite the process, yay me):\r\n\r\n<patch author='zooko@zooko.com' date='20090308025039' local_date='Making \r\nfriendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, \r\nctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = \r\n\"GMT\", ctTZ = 0, ctIsDST = False}\r\n\r\nPlugging that into your first requested program:\r\n\r\nimport System.Time\r\n\r\n-- this is one line\r\nmain = print . toClockTime $ CalendarTime 2009 March 8 2 50 39 0 Sunday 0 \"GMT\" \r\n0 False\r\n\r\n... returns:\r\n\r\nt: user error (Time.toClockTime: invalid input)\r\n\r\nSo.. This suggests to me there are two problems. First, the toClockTime \r\nfunction has trouble with certain input.\r\n\r\nThis fails:\r\n-- this is one line\r\nmain = print . toClockTime $ CalendarTime 2009 March 8 2 59 59 1000 Thursday \r\n280 \"BST\" 3600 True\r\n\r\nThis succeeds:\r\n-- this is one line\r\nmain = print . toClockTime $ CalendarTime 2009 March 8 3 0 0 0 Thursday 280 \r\n\"BST\" 3600 True\r\n\r\nWeird huh?\r\n\r\nAnd then clearly, the second problem appears to be the conversion of the \r\ndatestamp in the following partial log entry:\r\n\r\n<patch author='zooko@zooko.com' date='20090308025039' local_date='Making \r\nfriendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, \r\nctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = \r\n\"GMT\", ctTZ = 0, ctIsDST = False}\r\n\r\n(This is with a modified darcs with the printf-equivalent in it.)\r\n\r\nThis is suspiciously near to the DST switchover. If you need a zdump of my \r\ncurrent DST timings, I can provide the pre-zic entries.\r\n\r\nIs there perhaps a DST switchover assumption in that logic?\r\n\r\nLet me know if you'd like me to delve further. Hopefully this is enough to make \r\nthe problem clear to you darcs folks.\r\n}}}\r\n\r\nThis really needs to be looked at by someone with access to NetBSD (or perhaps some similar OS).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3771haddock: internal error: evacuate: strange closure type 192692019-07-07T19:02:15Zdbuenohaddock: internal error: evacuate: strange closure type 19269Here are the last few lines of `make` output
```
"rm" -f libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
(echo libraries/unix/dist-install/build/cbits/HsUnix.p_o libraries/unix/dist-install/build/cbits/execvpe.p_o libraries/un...Here are the last few lines of `make` output
```
"rm" -f libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
(echo libraries/unix/dist-install/build/cbits/HsUnix.p_o libraries/unix/dist-install/build/cbits/execvpe.p_o libraries/unix/dist-install/build/cbits/dirUtils.p_o `/usr/bin/find libraries/unix/dist-install/build -name "*_stub.p_o" -print`; /usr/bin/find libraries/unix/dist-install/build/System/Posix_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Module_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Prim_p_o_split libraries/unix/dist-install/build/System/Posix/Directory_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker_p_o_split libraries/unix/dist-install/build/System/Posix/Env_p_o_split libraries/unix/dist-install/build/System/Posix/Error_p_o_split libraries/unix/dist-install/build/System/Posix/Files_p_o_split libraries/unix/dist-install/build/System/Posix/IO_p_o_split libraries/unix/dist-install/build/System/Posix/Process_p_o_split libraries/unix/dist-install/build/System/Posix/Process/Internals_p_o_split libraries/unix/dist-install/build/System/Posix/Resource_p_o_split libraries/unix/dist-install/build/System/Posix/Temp_p_o_split libraries/unix/dist-install/build/System/Posix/Terminal_p_o_split libraries/unix/dist-install/build/System/Posix/Time_p_o_split libraries/unix/dist-install/build/System/Posix/Unistd_p_o_split libraries/unix/dist-install/build/System/Posix/User_p_o_split libraries/unix/dist-install/build/System/Posix/Signals_p_o_split libraries/unix/dist-install/build/System/Posix/Signals/Exts_p_o_split libraries/unix/dist-install/build/System/Posix/Semaphore_p_o_split libraries/unix/dist-install/build/System/Posix/SharedMem_p_o_split -name '*.p_o' -print) | "xargs" "/usr/bin/ar" clqs libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
"inplace/bin/mkdirhier" libraries/unix/dist-install/doc/html/unix/
"inplace/bin/ghc-cabal" haddock dist-install libraries/unix --with-haddock=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/haddock --with-ghc=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/ghc-stage2
Running Haddock for unix-2.4.0.0...
Preprocessing library unix-2.4.0.0...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: ffi-1.0, rts-1.0
haddock: internal error: evacuate: strange closure type 19269
(GHC version 6.12.1 for powerpc_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [libraries/unix/dist-install/doc/html/unix/unix.haddock] Error 6
make: *** [all] Error 2
```
I did the following to build:
```
./configure --prefix=/usr/local/ghc-6.12.4
make
```
I'm on `Darwin power-mac-g5.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:54:29 PDT 2009; root:xnu-1228.12.14~1/RELEASE_PPC Power Macintosh`.
What other information do you need?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | powerpc64 |
</details>
<!-- {"blocked_by":[],"summary":"haddock: internal error: evacuate: strange closure type 19269","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"powerpc64","cc":[""],"type":"Bug","description":"Here are the last few lines of `make` output\r\n{{{\r\n\"rm\" -f libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a\r\n(echo libraries/unix/dist-install/build/cbits/HsUnix.p_o libraries/unix/dist-install/build/cbits/execvpe.p_o libraries/unix/dist-install/build/cbits/dirUtils.p_o `/usr/bin/find libraries/unix/dist-install/build -name \"*_stub.p_o\" -print`; /usr/bin/find libraries/unix/dist-install/build/System/Posix_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Module_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Prim_p_o_split libraries/unix/dist-install/build/System/Posix/Directory_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker_p_o_split libraries/unix/dist-install/build/System/Posix/Env_p_o_split libraries/unix/dist-install/build/System/Posix/Error_p_o_split libraries/unix/dist-install/build/System/Posix/Files_p_o_split libraries/unix/dist-install/build/System/Posix/IO_p_o_split libraries/unix/dist-install/build/System/Posix/Process_p_o_split libraries/unix/dist-install/build/System/Posix/Process/Internals_p_o_split libraries/unix/dist-install/build/System/Posix/Resource_p_o_split libraries/unix/dist-install/build/System/Posix/Temp_p_o_split libraries/unix/dist-install/build/System/Posix/Terminal_p_o_split libraries/unix/dist-install/build/System/Posix/Time_p_o_split libraries/unix/dist-install/build/System/Posix/Unistd_p_o_split libraries/unix/dist-install/build/System/Posix/User_p_o_split libraries/unix/dist-install/build/System/Posix/Signals_p_o_split libraries/unix/dist-install/build/System/Posix/Signals/Exts_p_o_split libraries/unix/dist-install/build/System/Posix/Semaphore_p_o_split libraries/unix/dist-install/build/System/Posix/SharedMem_p_o_split -name '*.p_o' -print) | \"xargs\" \"/usr/bin/ar\" clqs libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a\r\n\"inplace/bin/mkdirhier\" libraries/unix/dist-install/doc/html/unix/\r\n\"inplace/bin/ghc-cabal\" haddock dist-install libraries/unix --with-haddock=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/haddock --with-ghc=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/ghc-stage2 \r\nRunning Haddock for unix-2.4.0.0...\r\nPreprocessing library unix-2.4.0.0...\r\nWarning: The documentation for the following packages are not installed. No\r\nlinks will be generated to these packages: ffi-1.0, rts-1.0\r\nhaddock: internal error: evacuate: strange closure type 19269\r\n (GHC version 6.12.1 for powerpc_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nmake[1]: *** [libraries/unix/dist-install/doc/html/unix/unix.haddock] Error 6\r\nmake: *** [all] Error 2\r\n}}}\r\nI did the following to build:\r\n{{{\r\n./configure --prefix=/usr/local/ghc-6.12.4\r\nmake\r\n}}}\r\n\r\nI'm on `Darwin power-mac-g5.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:54:29 PDT 2009; root:xnu-1228.12.14~1/RELEASE_PPC Power Macintosh`.\r\n\r\nWhat other information do you need?","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3739ghc-cabal mishandles relative paths in arguments2019-07-07T19:02:31Zasuffieldghc-cabal mishandles relative paths in argumentsJust making a record of this one, don't expect it to get fixed in a hurry
ghc-cabal chdirs into the source directory when it runs, because cabal wants to run there. Unfortunately this means relative paths in the arguments are treated as...Just making a record of this one, don't expect it to get fixed in a hurry
ghc-cabal chdirs into the source directory when it runs, because cabal wants to run there. Unfortunately this means relative paths in the arguments are treated as relative to the cabal file, rather than the directory where ghc-cabal was invoked. This is notably an issue for --package-db, which currently requires an absolute path in order to avoid this issue.
(This appears to be the last thing in ghc which needs an absolute path; when it's gone, a lot of things become simpler)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| 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-cabal mishandles relative paths in arguments","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Just making a record of this one, don't expect it to get fixed in a hurry\r\n\r\nghc-cabal chdirs into the source directory when it runs, because cabal wants to run there. Unfortunately this means relative paths in the arguments are treated as relative to the cabal file, rather than the directory where ghc-cabal was invoked. This is notably an issue for --package-db, which currently requires an absolute path in order to avoid this issue.\r\n\r\n(This appears to be the last thing in ghc which needs an absolute path; when it's gone, a lot of things become simpler)","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3625GHCI doesn't work with dtrace on OS X2019-07-07T19:03:05Zrl@cse.unsw.edu.auGHCI doesn't work with dtrace on OS XOn OS X, user-defined dtrace probes are implemented as special symbols of the form `___dtrace_probe$...` which are magically resolved by the linker. In the attached package, we have this dtrace script:
```
provider haskell {
probe dem...On OS X, user-defined dtrace probes are implemented as special symbols of the form `___dtrace_probe$...` which are magically resolved by the linker. In the attached package, we have this dtrace script:
```
provider haskell {
probe demo__trace(char*);
};
```
and this C file:
```
void demo_trace( char *s )
{
HASKELL_DEMO_TRACE(s);
}
```
When we compile it, we get:
```
newbie:dtrace-demo rl$ nm demo-trace.o
U ___dtrace_probe$haskell$demo__trace$v1$63686172202a
U ___dtrace_stability$haskell$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0
U ___dtrace_typedefs$haskell$v1
00000000 T _demo_trace
```
When linked as a dynamic library, the undefined symbols disappear:
```
newbie:dtrace-demo rl$ ld -dylib -o demo-trace.dylib demo-trace.o
newbie:dtrace-demo rl$ nm demo-trace.dylib
00000000 t __mh_dylib_header
000008b0 T _demo_trace
```
But GHCI's linker can't resolve the symbols which means that GHCI will fail if it tries to load demo-trace.o or a package file that contains demo-trace.o. For the attached package, `ghci -package dtrace-demo` produces this error:
```
unknown symbol `___dtrace_probe$haskell$demo__trace$v1$63686172202a'
Loading package dtrace-demo-1.0 ... linking ... ghc: unable to load package `dtrace-demo-1.0'
```
Unless I'm mistaken, the only solution is to use dlopen instead of a hand-written linker as the dtrace symbols are actually resolved by the kernel.
The problem came up while implementing dtrace-based profiling for DPH. DPH uses Template Haskell so GHC tries to load a package which uses dtrace and dies.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCI doesn't work with dtrace on OS X","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On OS X, user-defined dtrace probes are implemented as special symbols of the form `___dtrace_probe$...` which are magically resolved by the linker. In the attached package, we have this dtrace script:\r\n\r\n{{{\r\nprovider haskell {\r\n probe demo__trace(char*);\r\n};\r\n}}}\r\n\r\nand this C file:\r\n\r\n{{{\r\nvoid demo_trace( char *s )\r\n{\r\n HASKELL_DEMO_TRACE(s);\r\n}\r\n}}}\r\n\r\nWhen we compile it, we get:\r\n\r\n{{{\r\nnewbie:dtrace-demo rl$ nm demo-trace.o\r\n U ___dtrace_probe$haskell$demo__trace$v1$63686172202a\r\n U ___dtrace_stability$haskell$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0\r\n U ___dtrace_typedefs$haskell$v1\r\n00000000 T _demo_trace\r\n}}}\r\n\r\nWhen linked as a dynamic library, the undefined symbols disappear:\r\n\r\n{{{\r\nnewbie:dtrace-demo rl$ ld -dylib -o demo-trace.dylib demo-trace.o \r\nnewbie:dtrace-demo rl$ nm demo-trace.dylib \r\n00000000 t __mh_dylib_header\r\n000008b0 T _demo_trace\r\n}}}\r\n\r\nBut GHCI's linker can't resolve the symbols which means that GHCI will fail if it tries to load demo-trace.o or a package file that contains demo-trace.o. For the attached package, `ghci -package dtrace-demo` produces this error:\r\n\r\n{{{\r\nunknown symbol `___dtrace_probe$haskell$demo__trace$v1$63686172202a'\r\nLoading package dtrace-demo-1.0 ... linking ... ghc: unable to load package `dtrace-demo-1.0'\r\n}}}\r\n\r\nUnless I'm mistaken, the only solution is to use dlopen instead of a hand-written linker as the dtrace symbols are actually resolved by the kernel.\r\n\r\nThe problem came up while implementing dtrace-based profiling for DPH. DPH uses Template Haskell so GHC tries to load a package which uses dtrace and dies.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3543-fext-core doesn't force recompilation when .hcr file doesn't exist2019-07-07T19:03:25Zchevalier@alum.wellesley.edu-fext-core doesn't force recompilation when .hcr file doesn't existIf I do:
ghc -o foo foo.hs
and then immediately afterward:
ghc -fext-core -c foo.hs
and foo.hcr doesn't exist, ghc still says "Compilation is not required" and doesn't create the External Core file. It should generate the .hcr given the...If I do:
ghc -o foo foo.hs
and then immediately afterward:
ghc -fext-core -c foo.hs
and foo.hcr doesn't exist, ghc still says "Compilation is not required" and doesn't create the External Core file. It should generate the .hcr given the -fext-core flag, even if the .hi file is up to date.
Sorry if this is a duplicate bug (I know that making the compilation manager pay attention to flags is an ongoing issue).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-fext-core doesn't force recompilation when .hcr file doesn't exist","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I do:\r\nghc -o foo foo.hs\r\nand then immediately afterward:\r\nghc -fext-core -c foo.hs\r\n\r\nand foo.hcr doesn't exist, ghc still says \"Compilation is not required\" and doesn't create the External Core file. It should generate the .hcr given the -fext-core flag, even if the .hi file is up to date.\r\n\r\nSorry if this is a duplicate bug (I know that making the compilation manager pay attention to flags is an ongoing issue).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3509libffi.so not found on Mac OS X (10.5.8)2019-07-07T19:03:34Zmwottonlibffi.so not found on Mac OS X (10.5.8)building with dynamic libraries on Mac OS X dies with an error about libffi.so
To reproduce:
```
add a build.mk with "GhcLibWays = v dyn"
sh boot && ./configure --enable-shared && make
```
If I copy one of the libffi\*dylib files tha...building with dynamic libraries on Mac OS X dies with an error about libffi.so
To reproduce:
```
add a build.mk with "GhcLibWays = v dyn"
sh boot && ./configure --enable-shared && make
```
If I copy one of the libffi\*dylib files that does appear to have been built correctly to libffi.so, the build proceeds but then loops in the build process.
partial trace:
```
(cd .libs && rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib libffi.5.dylib)
(cd .libs && rm -f libffi.dylib && cp -p libffi.5.0.9.dylib libffi.dylib)
ar cru .libs/libffi.a src/debug.o src/prep_cif.o src/types.o src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi.o src/x86/darwin.o src/x86/ffi64.o src/x86/darwin64.o
"inplace/bin/mkdirhier" inplace/lib/
"cp" -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/hsc2hs
ranlib: file: .libs/libffi.a(ffi64.o) has no symbols
ranlib: file: .libs/libffi.a(darwin64.o) has no symbolstouch inplace/lib/hsc2hs
ranlib .libs/libffi.a
ranlib: file: .libs/libffi.a(ffi64.o) has no symbols
ranlib: file: .libs/libffi.a(darwin64.o) has no symbols
creating libffi.la
(cd .libs && rm -f libffi.la && cp -p ../libffi.la libffi.la)
/bin/sh ./libtool --tag=CC --mode=link gcc -Wall -g -fexceptions -w -w -o libffi_convenience.la src/debug.lo src/prep_cif.lo src/types.lo src/raw_api.lo src/java_raw_api.lo src/closures.lo src/x86/ffi.lo src/x86/darwin.lo src/x86/ffi64.lo src/x86/darwin64.lo
ar cru .libs/libffi_convenience.a src/.libs/debug.o src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/darwin.o src/x86/.libs/ffi64.o src/x86/.libs/darwin64.o
ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols
ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols
ranlib .libs/libffi_convenience.a
ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols
ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols
creating libffi_convenience.la
(cd .libs && rm -f libffi_convenience.la && cp -p ../libffi_convenience.la libffi_convenience.la)
make[4]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build'
make[3]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build'
cp .libs/libffi.5.0.9.dylib /Users/mwotton/projects/ghc/libffi/libffi.5.0.9.dylib
(cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib libffi.5.dylib || { rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib libffi.5.dylib; }; })
(cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib libffi.dylib || { rm -f libffi.dylib && cp -p libffi.5.0.9.dylib libffi.dylib; }; })
cp .libs/libffi.lai /Users/mwotton/projects/ghc/libffi/libffi.la
cp .libs/libffi.a /Users/mwotton/projects/ghc/libffi/libffi.a
chmod 644 /Users/mwotton/projects/ghc/libffi/libffi.a
ranlib /Users/mwotton/projects/ghc/libffi/libffi.a
ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(ffi64.o) has no symbols
ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(darwin64.o) has no symbols
libtool: install: warning: remember to run `libtool --finish /usr/local/lib'
touch libffi/stamp.ffi.build-shared
"cp" libffi/libffi.a libffi/libHSffi.a
"cp" libffi/libffi.so libffi/libHSffi-ghc6.11.20090913.dylib
"cp" libffi/libffi.a libffi/libHSffi_p.a
cp: libffi/libffi.so: No such file or directory
make[1]: *** [libffi/libHSffi-ghc6.11.20090913.dylib] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
nice make -j 2 145.90s user 70.38s system 78% cpu 4:37.08 total
```7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3470OSX installer should give an informative error message when XCode is missing2019-07-07T19:03:43ZGregoryCollinsOSX installer should give an informative error message when XCode is missingA bug was reported on the haskell-platform trac about this: when Xcode is not installed, the OSX installer shows a blank screen with a greyed-out "Install" button. An informative message should be displayed instead.
More details (incl. ...A bug was reported on the haskell-platform trac about this: when Xcode is not installed, the OSX installer shows a blank screen with a greyed-out "Install" button. An informative message should be displayed instead.
More details (incl. screenshots) here:
http://trac.haskell.org/haskell-platform/ticket/67
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| 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":"OSX installer should give an informative error message when XCode is missing","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A bug was reported on the haskell-platform trac about this: when Xcode is not installed, the OSX installer shows a blank screen with a greyed-out \"Install\" button. An informative message should be displayed instead.\r\n\r\nMore details (incl. screenshots) here:\r\n\r\nhttp://trac.haskell.org/haskell-platform/ticket/67","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3376hpc and CPP don't mix on Windows2019-07-07T19:04:09ZIan Lynagh <igloo@earth.li>hpc and CPP don't mix on WindowsOriginaly reported by Dominic Steinitz here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-July/017511.html
On Windows, with these files:
CommonHPC.hs:
```
module Main (main) where
import Common
main = do
test
test...Originaly reported by Dominic Steinitz here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-July/017511.html
On Windows, with these files:
CommonHPC.hs:
```
module Main (main) where
import Common
main = do
test
test
test = do
putStrLn $ show $ fact 4
putStrLn $ show $ fact 5
```
Common.hs:
```
module Common (fact) where
fact 0 = 1
fact n = n * fact (n-1)
```
This works:
```
$ ghc -fhpc --make CommonHPC
$ ./CommonHPC
$ cat CommonHPC.exe.tix
Tix [ TixModule "Main" 693125724 18 [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], TixModule "Common" 4136915291 8 [2,9,9,9,9,9,9,11]]
```
but with `-cpp` we get no ticks for Common:
```
$ ghc -fhpc --make CommonHPC -cpp
$ ./CommonHPC
$ cat CommonHPC.exe.tix
Tix [ TixModule "Main" 693125724 18 [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], TixModule "Common" 3370079577 0 []]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hpc and CPP don't mix on Windows","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"andy@galois.com"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Originaly reported by Dominic Steinitz here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-July/017511.html\r\n\r\nOn Windows, with these files:\r\n\r\nCommonHPC.hs:\r\n{{{\r\nmodule Main (main) where\r\n\r\nimport Common\r\n\r\nmain = do\r\n test\r\n test\r\n\r\ntest = do\r\n putStrLn $ show $ fact 4\r\n putStrLn $ show $ fact 5\r\n}}}\r\n\r\nCommon.hs:\r\n{{{\r\nmodule Common (fact) where\r\n\r\nfact 0 = 1\r\nfact n = n * fact (n-1)\r\n}}}\r\n\r\nThis works:\r\n{{{\r\n$ ghc -fhpc --make CommonHPC\r\n$ ./CommonHPC\r\n$ cat CommonHPC.exe.tix\r\nTix [ TixModule \"Main\" 693125724 18 [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], TixModule \"Common\" 4136915291 8 [2,9,9,9,9,9,9,11]]\r\n}}}\r\n\r\nbut with `-cpp` we get no ticks for Common:\r\n{{{\r\n$ ghc -fhpc --make CommonHPC -cpp\r\n$ ./CommonHPC\r\n$ cat CommonHPC.exe.tix\r\nTix [ TixModule \"Main\" 693125724 18 [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], TixModule \"Common\" 3370079577 0 []]\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1andy@galois.comandy@galois.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/3191hpc reports spurious results with .lhs files even after processing with ghc -E2019-07-07T19:04:57ZDominichpc reports spurious results with .lhs files even after processing with ghc -EI've done a bit of investigation and it seems there are at least two problems:
1. I have literate haskell files (.lhs).
1. Even if I run them through the pre-processor (ghc -E) they still don't work
but if I manually remove these line...I've done a bit of investigation and it seems there are at least two problems:
1. I have literate haskell files (.lhs).
1. Even if I run them through the pre-processor (ghc -E) they still don't work
but if I manually remove these lines (which seem to get inserted by the
pre-processor)
{-\# LINE 1 "ASNTYPE.lhs" \#-}
\#line 1 "ASNTYPE.lhs"
then it does actually work.
I still have a problem with another project which doesn't use literate haskell
but does require the use of -cpp and has got \#ifdef's. I haven't got to the
bottom of it yet but I'm suspicious that lines starting with \# cause hpc to
misbehave.
It's strange that hpc should behave like this as I would have thought it
wouldn't care about hs / lhs and \# as ghc would have done some of its standard
processing before hpc got engaged.
This happens on linux and windows (not surprisingly).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hpc reports spurious results with .lhs files even after processing with ghc -E","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"andy@galois.com"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've done a bit of investigation and it seems there are at least two problems:\r\n\r\n1. I have literate haskell files (.lhs).\r\n\r\n2. Even if I run them through the pre-processor (ghc -E) they still don't work \r\nbut if I manually remove these lines (which seem to get inserted by the\r\npre-processor)\r\n\r\n{-# LINE 1 \"ASNTYPE.lhs\" #-}\r\n#line 1 \"ASNTYPE.lhs\"\r\n\r\nthen it does actually work.\r\n\r\nI still have a problem with another project which doesn't use literate haskell\r\nbut does require the use of -cpp and has got #ifdef's. I haven't got to the\r\nbottom of it yet but I'm suspicious that lines starting with # cause hpc to\r\nmisbehave.\r\n\r\nIt's strange that hpc should behave like this as I would have thought it\r\nwouldn't care about hs / lhs and # as ghc would have done some of its standard\r\nprocessing before hpc got engaged.\r\n\r\nThis happens on linux and windows (not surprisingly).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1andy@galois.comandy@galois.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/3065Reorder tests in quot to improve code2019-07-07T19:05:34ZSimon Peyton JonesReorder tests in quot to improve code\[SLPJ: capturing an email thread in a ticket\]
Krasimir Angelov found that this function:
```
a `quot` b
| b == 0 = divZeroError
| a == minBound && b == (-1) = overflowError
| otherwise ...\[SLPJ: capturing an email thread in a ticket\]
Krasimir Angelov found that this function:
```
a `quot` b
| b == 0 = divZeroError
| a == minBound && b == (-1) = overflowError
| otherwise = a `quotInt` b
```
is expanded to:
```
a `quot` b =
if b == 0
then divZeroError
else if a == minBound
then if b == (-1)
then overflowError
else a `quotInt` b
else a `quotInt` b
```
Then the compiler sees that b is a constant and computes that b == 0
is False and b == (-1) is also False so it could eliminate two If
statements. The result is:
```
a `quot` b =
if a == minBound
then a `quotInt` b
else a `quotInt` b
```
and this is exactly what we get. I bet that if the original function was:
```
a `quot` b
| b == 0 = divZeroError
| b == (-1) && a == minBound = overflowError -- Note the changed order here
| otherwise = a `quotInt` b
```
then we would get what we want. I think that it is much more often to
have division where the divisor is known so we will get the best code
in this case.
Shortly afterwards, Bertram Felgenhauer tried it out. It works, and it has the desired effect. It's not always a win though; the nofib prime sieve benchmark suffers.
For a patch, see
> http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune-division.patch
(SLPJ: I've attached it to the ticket too)
Nofib results extract:
```
------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed
------------------------------------------------------------------------
fish -0.7% -5.3% 0.05 0.04
primes -0.0% +28.5% +25.6% +25.5%
wheel-sieve2 -0.0% -0.3% -17.9% -18.6%
------------------------------------------------------------------------
Min -0.9% -5.3% -17.9% -18.6%
Max +0.1% +28.5% +25.6% +25.5%
Geometric Mean -0.2% +0.2% -0.0% +0.2%
```
'primes' is an outlier - the other slowdowns are below 3%
What happens in 'primes' is that 'mod' no longer gets inlined;
apparently it now looks bigger to the compiler than before.
Using -funfolding-use-threshold=10 brings the benchmark back to its
original speed, despite the extra comparison before doing the
division.
In 'wheel-sieve2', the first different optimization choice I see is
again a 'mod' that is no longer inlined; this leads to a change in other
inlining choices that result in a speedup for reasons that I have not
investigated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------------------------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bertram.felgenhauer@googlemail.com; kr.angelov@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reorder tests in quot to improve code","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bertram.felgenhauer@googlemail.com; kr.angelov@gmail.com"],"type":"Bug","description":"[SLPJ: capturing an email thread in a ticket]\r\n\r\nKrasimir Angelov found that this function:\r\n{{{\r\na `quot` b\r\n | b == 0 = divZeroError\r\n | a == minBound && b == (-1) = overflowError\r\n | otherwise = a `quotInt` b\r\n}}}\r\nis expanded to:\r\n{{{\r\na `quot` b =\r\n if b == 0\r\n then divZeroError\r\n else if a == minBound\r\n then if b == (-1)\r\n then overflowError\r\n else a `quotInt` b\r\n else a `quotInt` b\r\n}}}\r\nThen the compiler sees that b is a constant and computes that b == 0\r\nis False and b == (-1) is also False so it could eliminate two If\r\nstatements. The result is:\r\n{{{\r\na `quot` b =\r\n if a == minBound\r\n then a `quotInt` b\r\n else a `quotInt` b\r\n}}}\r\nand this is exactly what we get. I bet that if the original function was:\r\n{{{\r\na `quot` b\r\n | b == 0 = divZeroError\r\n | b == (-1) && a == minBound = overflowError -- Note the changed order here\r\n | otherwise = a `quotInt` b\r\n}}}\r\nthen we would get what we want. I think that it is much more often to\r\nhave division where the divisor is known so we will get the best code\r\nin this case.\r\n\r\nShortly afterwards, Bertram Felgenhauer tried it out. It works, and it has the desired effect. It's not always a win though; the nofib prime sieve benchmark suffers.\r\n\r\nFor a patch, see\r\n http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune-division.patch\r\n(SLPJ: I've attached it to the ticket too)\r\n\r\nNofib results extract:\r\n{{{\r\n------------------------------------------------------------------------\r\n Program Size Allocs Runtime Elapsed\r\n------------------------------------------------------------------------\r\n fish -0.7% -5.3% 0.05 0.04\r\n primes -0.0% +28.5% +25.6% +25.5%\r\n wheel-sieve2 -0.0% -0.3% -17.9% -18.6%\r\n------------------------------------------------------------------------\r\n Min -0.9% -5.3% -17.9% -18.6%\r\n Max +0.1% +28.5% +25.6% +25.5%\r\n Geometric Mean -0.2% +0.2% -0.0% +0.2%\r\n}}}\r\n'primes' is an outlier - the other slowdowns are below 3%\r\n\r\nWhat happens in 'primes' is that 'mod' no longer gets inlined;\r\napparently it now looks bigger to the compiler than before.\r\n\r\nUsing -funfolding-use-threshold=10 brings the benchmark back to its\r\noriginal speed, despite the extra comparison before doing the\r\ndivision.\r\n\r\nIn 'wheel-sieve2', the first different optimization choice I see is\r\nagain a 'mod' that is no longer inlined; this leads to a change in other\r\ninlining choices that result in a speedup for reasons that I have not\r\ninvestigated.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/3003Happy does not reject pragmas2019-07-07T19:05:55ZSamuel BronsonHappy does not reject pragmasI was about to report a bug in GHC's handling of -fno-warn-missing signatures in pragmas, but wasn't able to reproduce it. Then I noticed it: the problem was that the pragma was at the very top of a `.y` file, where it was simply discard...I was about to report a bug in GHC's handling of -fno-warn-missing signatures in pragmas, but wasn't able to reproduce it. Then I noticed it: the problem was that the pragma was at the very top of a `.y` file, where it was simply discarded, like this:
```
{-# OPTIONS_GHC -fno-warn-missing-signatures #-} {- -*- Haskell -*- -}
{
```
Happy should probably not just silently discard pragmas.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Happy does not reject pragmas","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was about to report a bug in GHC's handling of -fno-warn-missing signatures in pragmas, but wasn't able to reproduce it. Then I noticed it: the problem was that the pragma was at the very top of a {{{.y}}} file, where it was simply discarded, like this:\r\n{{{\r\n{-# OPTIONS_GHC -fno-warn-missing-signatures #-} {- -*- Haskell -*- -}\r\n\r\n{\r\n}}}\r\nHappy should probably not just silently discard pragmas.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1