GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-04-08T14:00:08Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15670FloatFnInverses seems to show some weird rounding/precision issues.2022-04-08T14:00:08ZTamar ChristinaFloatFnInverses seems to show some weird rounding/precision issues.There seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly.
```
--- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout...There seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly.
```
--- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout.normalised 2018-09-23 17:26:01.581150200 +0100
+++ numeric/should_run/FloatFnInverses.run/FloatFnInverses.run.stdout.normalised 2018-09-23 17:26:01.583146400 +0100
@@ -8,8 +8,8 @@
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
+[Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity]
+[7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"FloatFnInverses seems to show some weird rounding/precision issues.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nThere seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly.\r\n\r\n{{{\r\n--- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout.normalised 2018-09-23 17:26:01.581150200 +0100\r\n+++ numeric/should_run/FloatFnInverses.run/FloatFnInverses.run.stdout.normalised 2018-09-23 17:26:01.583146400 +0100\r\n@@ -8,8 +8,8 @@\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n+[Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity]\r\n+[7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15349fixST is a bit wrong2019-07-07T18:13:03ZDavid FeuerfixST is a bit wrongLazy blackholing lets some `ST` calculations complete that shouldn't.
```hs
import Control.Monad.ST.Strict
import Control.Monad.Fix
import Data.STRef
foo :: ST s Int
foo = do
ref <- newSTRef True
mfix $ \res -> do
x <- readSTRe...Lazy blackholing lets some `ST` calculations complete that shouldn't.
```hs
import Control.Monad.ST.Strict
import Control.Monad.Fix
import Data.STRef
foo :: ST s Int
foo = do
ref <- newSTRef True
mfix $ \res -> do
x <- readSTRef ref
if x
then do
writeSTRef ref False
return $! (res + 5)
else return 10
main = print $ runST foo
```
When this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`.
Should we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"fixST is a bit wrong","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Lazy blackholing lets some `ST` calculations complete that shouldn't.\r\n\r\n{{{#!hs\r\nimport Control.Monad.ST.Strict\r\nimport Control.Monad.Fix\r\nimport Data.STRef\r\n\r\nfoo :: ST s Int\r\nfoo = do\r\n ref <- newSTRef True\r\n mfix $ \\res -> do\r\n x <- readSTRef ref\r\n if x\r\n then do\r\n writeSTRef ref False\r\n return $! (res + 5)\r\n else return 10\r\n\r\nmain = print $ runST foo\r\n}}}\r\n\r\nWhen this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`.\r\n\r\nShould we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/15255overflow1 breaks on i3862019-07-07T18:13:36ZBen Gamarioverflow1 breaks on i386The i386 CircleCI target is showing a mysterious failure of the `overflow1` test:
```
=====> overflow1(normal) 4082 of 6414 [0, 3, 0]
Wrong exit code for overflow1(normal)(expected 251 , actual 0 )
*** unexpected failure for overflow1(n...The i386 CircleCI target is showing a mysterious failure of the `overflow1` test:
```
=====> overflow1(normal) 4082 of 6414 [0, 3, 0]
Wrong exit code for overflow1(normal)(expected 251 , actual 0 )
*** unexpected failure for overflow1(normal)
```
Need to work out what is going on here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"overflow1 breaks on i386","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The i386 CircleCI target is showing a mysterious failure of the `overflow1` test:\r\n{{{\r\n=====> overflow1(normal) 4082 of 6414 [0, 3, 0]\r\nWrong exit code for overflow1(normal)(expected 251 , actual 0 )\r\n*** unexpected failure for overflow1(normal)\r\n}}}\r\n\r\nNeed to work out what is going on here.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15245Data family promotion is possible2021-11-06T12:06:45ZVladislav ZavialovData family promotion is possibleThe User's Guide states that data families cannot be promoted, even with `-XTypeInType`:
> We promote data types and newtypes; type synonyms and type/data families are not promoted.
>
> The flag TypeInType (which implies DataKinds) rela...The User's Guide states that data families cannot be promoted, even with `-XTypeInType`:
> We promote data types and newtypes; type synonyms and type/data families are not promoted.
>
> The flag TypeInType (which implies DataKinds) relaxes some of these restrictions, allowing:
>
> Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.
And yet the following code typechecks and runs:
```hs
{-# LANGUAGE TypeFamilies, TypeInType, TypeApplications #-}
import Type.Reflection
data family K
data instance K = MkK
main = print (typeRep @'MkK)
```
Is this a GHC bug or a documentation bug? I asked in IRC but I'm still confused:
```
<int-index> The user guide states that data families aren't promoted even when -XTypeInType is enabled. Where's the logic that ensures this? I checked with `data family K; data instance K = MkK` and I can use `'MkK` with no errors/warnings.
<int-index> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overview "Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types."
<int-index> Is this info outdated?
<RyanGlScott> int-index: Is this in GHCi?
<RyanGlScott> It certainly fails in GHC
<RyanGlScott> But I think I understand why the former works
<int-index> RyanGlScott, yes, I'm checking this in GHCi
<RyanGlScott> int-index: So here's my understanding of how this works
<RyanGlScott> GHC kind-checks top-level declarations using a rather primitive SCC analysis
<RyanGlScott> In particular, it's primitive in the sense that data family instances give it a lot of trouble
<RyanGlScott> If you tried taking your code and putting it into a standalone .hs file and compiling that, then it would definitely complain about a promoted use of MkT
<RyanGlScott> As luck would have it, though, you were trying things out in GHCi
<RyanGlScott> Which essentially checks each line of input as its own strongly connected group of declarations
<RyanGlScott> So you can define MkT on one line and promote it in subsequent lines, since they're separate in the sense
<RyanGlScott> *that sense
<int-index> this sounds related to Trac #12088, and then I could work around it in GHC by using `$(return [])`, so data families are actually promoted anyway and this has nothing to do with GHC needing more powerful type theory
<RyanGlScott> Well, it does need more powerful type theory in the sense that that's a prerequisite for making the SCC analysis for kind-checking sophisticated enough to handle this
<RyanGlScott> But yes, it's quite simple to work around by using Template Haskell to explicitly split up groups.
<int-index> https://gist.github.com/int-index/c6cc1e20c4b9b5c99af40ee4e23ecb61 this works and no template haskell involved
<int-index> The reason I'm asking is that I'm touching this part of the User's Guide and I don't know what to write there.
<RyanGlScott> Huh, now that's interesting
<int-index> RyanGlScott, the only check I could find that controls what's promoted and what's not is 'isLegacyPromotableDataCon' - and enabling -XTypeInType disables this check.
<RyanGlScott> int-index: Right, that's baffling me
<RyanGlScott> Since that's supposed to be checked every time you promote a data constructor (I think)
<RyanGlScott> int-index: File a bug about that, I suppose
<RyanGlScott> Richard (who's sitting next to me right now) seems to think that that shouldn't be possible
<int-index> RyanGlScott, the thing is, I happily removed this check completely in D4748. Does this mean I have to restore a weaker version of it that only checks for data families? Why?
<int-index> Is it bad that -XDataKinds promotes data family constructors? Looks like I can just remove the "restrictions" part of the user guide and be done with it
<RyanGlScott> int-index: In theory, that shouldn't be possible
<int-index> OK, then what the check should be? No data families, any other restrictions?
<RyanGlScott> I might qualify that with "no data family instances defined in the same module"
<RyanGlScott> (Or to be precise, in the same SCC, but that's probably too technical for the users' guide)
<int-index> Well, this sounds hard to check. I was thinking along the lines of keeping the 'not (isFamInstTyCon (dataConTyCon dc))' part of the check...
<RyanGlScott> Oh, I thought you were only changing the users' guide :)
<int-index> Well, at this point I'm confused if I should change only the user guide or the check as well. If data families shouldn't be promoted ever, then I'll change GHC. If the limitation is about the current SCC group, I can just mention Trac #12088 as a known infelicity in the User's Guide
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | RyanGlScott, goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data family promotion is possible","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":["RyanGlScott","goldfire"],"type":"Bug","description":"The User's Guide states that data families cannot be promoted, even with `-XTypeInType`:\r\n\r\n> We promote data types and newtypes; type synonyms and type/data families are not promoted.\r\n>\r\n> The flag TypeInType (which implies DataKinds) relaxes some of these restrictions, allowing:\r\n>\r\n> Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.\r\n\r\nAnd yet the following code typechecks and runs:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeFamilies, TypeInType, TypeApplications #-}\r\n\r\nimport Type.Reflection\r\n\r\ndata family K\r\ndata instance K = MkK\r\n\r\nmain = print (typeRep @'MkK)\r\n}}}\r\n\r\nIs this a GHC bug or a documentation bug? I asked in IRC but I'm still confused:\r\n\r\n{{{\r\n<int-index> The user guide states that data families aren't promoted even when -XTypeInType is enabled. Where's the logic that ensures this? I checked with `data family K; data instance K = MkK` and I can use `'MkK` with no errors/warnings.\r\n<int-index> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overview \"Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.\"\r\n<int-index> Is this info outdated?\r\n<RyanGlScott> int-index: Is this in GHCi?\r\n<RyanGlScott> It certainly fails in GHC\r\n<RyanGlScott> But I think I understand why the former works\r\n<int-index> RyanGlScott, yes, I'm checking this in GHCi\r\n<RyanGlScott> int-index: So here's my understanding of how this works\r\n<RyanGlScott> GHC kind-checks top-level declarations using a rather primitive SCC analysis\r\n<RyanGlScott> In particular, it's primitive in the sense that data family instances give it a lot of trouble\r\n<RyanGlScott> If you tried taking your code and putting it into a standalone .hs file and compiling that, then it would definitely complain about a promoted use of MkT\r\n<RyanGlScott> As luck would have it, though, you were trying things out in GHCi\r\n<RyanGlScott> Which essentially checks each line of input as its own strongly connected group of declarations\r\n<RyanGlScott> So you can define MkT on one line and promote it in subsequent lines, since they're separate in the sense\r\n<RyanGlScott> *that sense\r\n<int-index> this sounds related to Trac #12088, and then I could work around it in GHC by using `$(return [])`, so data families are actually promoted anyway and this has nothing to do with GHC needing more powerful type theory\r\n<RyanGlScott> Well, it does need more powerful type theory in the sense that that's a prerequisite for making the SCC analysis for kind-checking sophisticated enough to handle this\r\n<RyanGlScott> But yes, it's quite simple to work around by using Template Haskell to explicitly split up groups.\r\n<int-index> https://gist.github.com/int-index/c6cc1e20c4b9b5c99af40ee4e23ecb61 this works and no template haskell involved\r\n<int-index> The reason I'm asking is that I'm touching this part of the User's Guide and I don't know what to write there.\r\n<RyanGlScott> Huh, now that's interesting\r\n<int-index> RyanGlScott, the only check I could find that controls what's promoted and what's not is 'isLegacyPromotableDataCon' - and enabling -XTypeInType disables this check.\r\n<RyanGlScott> int-index: Right, that's baffling me\r\n<RyanGlScott> Since that's supposed to be checked every time you promote a data constructor (I think)\r\n<RyanGlScott> int-index: File a bug about that, I suppose\r\n<RyanGlScott> Richard (who's sitting next to me right now) seems to think that that shouldn't be possible\r\n<int-index> RyanGlScott, the thing is, I happily removed this check completely in D4748. Does this mean I have to restore a weaker version of it that only checks for data families? Why?\r\n<int-index> Is it bad that -XDataKinds promotes data family constructors? Looks like I can just remove the \"restrictions\" part of the user guide and be done with it\r\n<RyanGlScott> int-index: In theory, that shouldn't be possible\r\n<int-index> OK, then what the check should be? No data families, any other restrictions?\r\n<RyanGlScott> I might qualify that with \"no data family instances defined in the same module\"\r\n<RyanGlScott> (Or to be precise, in the same SCC, but that's probably too technical for the users' guide)\r\n<int-index> Well, this sounds hard to check. I was thinking along the lines of keeping the 'not (isFamInstTyCon (dataConTyCon dc))' part of the check...\r\n<RyanGlScott> Oh, I thought you were only changing the users' guide :)\r\n<int-index> Well, at this point I'm confused if I should change only the user guide or the check as well. If data families shouldn't be promoted ever, then I'll change GHC. If the limitation is about the current SCC group, I can just mention Trac #12088 as a known infelicity in the User's Guide\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15062num009 is incredibly platform-sensitive2022-01-16T09:37:43ZBen Gamarinum009 is incredibly platform-sensitiveThe functions tested by `num009` are certainly worthwhile to test, but we really need to find a better way to test them. Currently the test seemingly fails in more places than it passes:
- Fails on Darwin (#2370)
- Fails on POWER8 (#136...The functions tested by `num009` are certainly worthwhile to test, but we really need to find a better way to test them. Currently the test seemingly fails in more places than it passes:
- Fails on Darwin (#2370)
- Fails on POWER8 (#13634)
- Fails on Win32 when in the `ghci` way (no ticket)
- Fails under i386 on CircleCI (e.g. https://circleci.com/gh/ghc/ghc/3666)
Perhaps we should instead test the output against the same evaluations performed by a C program. This would eliminate spurious failures due to platform or C library differences.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"num009 is incredibly platform-sensitive","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The functions tested by `num009` are certainly worthwhile to test, but we really need to find a better way to test them. Currently the test seemingly fails in more places than it passes:\r\n\r\n * Fails on Darwin (#2370)\r\n * Fails on POWER8 (#13634)\r\n * Fails on Win32 when in the `ghci` way (no ticket)\r\n * Fails under i386 on CircleCI (e.g. https://circleci.com/gh/ghc/ghc/3666)\r\n\r\nPerhaps we should instead test the output against the same evaluations performed by a C program. This would eliminate spurious failures due to platform or C library differences.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/12714T9405 fails on Windows2022-04-08T14:00:09ZBen GamariT9405 fails on WindowsThe `T9405` testcase currently fails on Windows,
```
=====> T9405(normal) 8 of 14 [0, 1, 0]
cd "./rts/T9405.run" && $MAKE -s --no-print-directory T9405
Wrong exit code (expected 0 , actual 2 )
Stdout:
[1 of 1] Compiling Main ...The `T9405` testcase currently fails on Windows,
```
=====> T9405(normal) 8 of 14 [0, 1, 0]
cd "./rts/T9405.run" && $MAKE -s --no-print-directory T9405
Wrong exit code (expected 0 , actual 2 )
Stdout:
[1 of 1] Compiling Main ( T9405.hs, T9405.o )
Linking T9405.exe ...
Stderr:
make[1]: *** [Makefile:50: T9405] Error 1
```
Contrary to what was suggested in [ticket:12004\#comment:120267](https://gitlab.haskell.org//ghc/ghc/issues/12004#note_120267) it looks like the problem is that an empty `.ticky` file is produced. Even increasing the `sleep` time to 10 seconds (after bumping the sleep in `T9405.hs` accordingly) doesn't change this, so I suspect there is a runtime system bug here.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/1243720% regression in max_bytes_used for T19692020-01-23T16:18:02ZSimon Marlow20% regression in max_bytes_used for T1969This is 20% worse:
```
=====> T1969(normal) 1 of 1 [0, 0, 0]
cd "./T1969.run" && "/data/users/smarlow/ghc/inplace/test spaces/ghc-stage2" -c T1969.hs -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fs...This is 20% worse:
```
=====> T1969(normal) 1 of 1 [0, 0, 0]
cd "./T1969.run" && "/data/users/smarlow/ghc/inplace/test spaces/ghc-stage2" -c T1969.hs -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups +RTS -G1 -RTS +RTS -V0 -tT1969.comp.stats --machine-readable -RTS
max_bytes_used value is too high:
Expected T1969(normal) max_bytes_used: 15017528 +/-15%
Lower bound T1969(normal) max_bytes_used: 12764898
Upper bound T1969(normal) max_bytes_used: 17270158
Actual T1969(normal) max_bytes_used: 18071064
Deviation T1969(normal) max_bytes_used: 20.3 %
*** unexpected stat test failure for T1969(normal)
```
One of these patches is the culprit, but I can't tell from the build logs because the build was broken between these two points:
```
commit 6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91
Author: Ömer Sinan Ağacan <omeragacan@gmail.com>
Bump Haddock submodule
commit 8d4760fb7b20682cb5e470b24801301cfbbdce3b
Author: Simon Peyton Jones <simonpj@microsoft.com>
Comments re ApThunks + small refactor in mkRhsClosure
commit 9c54185b26922d88e516942aad946f05f707d7ce
Author: Simon Peyton Jones <simonpj@microsoft.com>
Comments + tiny refactor of isNullarySrcDataCon
commit a09c0e3e68c96882a1fb392c9dbeea84056bf32f
Author: Simon Peyton Jones <simonpj@microsoft.com>
Comments only
commit 714bebff44076061d0a719c4eda2cfd213b7ac3d
Author: Ömer Sinan Ağacan <omeragacan@gmail.com>
Implement unboxed sum primitive type
```
The patch immediately preceding this sequence does not have the failure: https://phabricator.haskell.org/rGHC83e4f49577665278fe08fbaafe2239553f3c448e (follow the link to the build)
and the final patch in this sequence \*does\* have the failure: https://phabricator.haskell.org/rGHC6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 (along with an improvement in T9675)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"20% regression in max_bytes_used for T1969","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"osa1"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"This is 20% worse:\r\n\r\n{{{\r\n=====> T1969(normal) 1 of 1 [0, 0, 0]\r\ncd \"./T1969.run\" && \"/data/users/smarlow/ghc/inplace/test spaces/ghc-stage2\" -c T1969.hs -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups +RTS -G1 -RTS +RTS -V0 -tT1969.comp.stats --machine-readable -RTS\r\nmax_bytes_used value is too high:\r\n Expected T1969(normal) max_bytes_used: 15017528 +/-15%\r\n Lower bound T1969(normal) max_bytes_used: 12764898 \r\n Upper bound T1969(normal) max_bytes_used: 17270158 \r\n Actual T1969(normal) max_bytes_used: 18071064 \r\n Deviation T1969(normal) max_bytes_used: 20.3 %\r\n*** unexpected stat test failure for T1969(normal)\r\n}}}\r\n\r\nOne of these patches is the culprit, but I can't tell from the build logs because the build was broken between these two points:\r\n\r\n{{{\r\ncommit 6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91\r\nAuthor: Ömer Sinan Ağacan <omeragacan@gmail.com>\r\n\r\n Bump Haddock submodule\r\n\r\ncommit 8d4760fb7b20682cb5e470b24801301cfbbdce3b\r\nAuthor: Simon Peyton Jones <simonpj@microsoft.com>\r\n\r\n Comments re ApThunks + small refactor in mkRhsClosure\r\n\r\ncommit 9c54185b26922d88e516942aad946f05f707d7ce\r\nAuthor: Simon Peyton Jones <simonpj@microsoft.com>\r\n\r\n Comments + tiny refactor of isNullarySrcDataCon\r\n\r\ncommit a09c0e3e68c96882a1fb392c9dbeea84056bf32f\r\nAuthor: Simon Peyton Jones <simonpj@microsoft.com>\r\n\r\n Comments only\r\n\r\ncommit 714bebff44076061d0a719c4eda2cfd213b7ac3d\r\nAuthor: Ömer Sinan Ağacan <omeragacan@gmail.com>\r\n\r\n Implement unboxed sum primitive type\r\n}}}\r\n\r\nThe patch immediately preceding this sequence does not have the failure: https://phabricator.haskell.org/rGHC83e4f49577665278fe08fbaafe2239553f3c448e (follow the link to the build)\r\n\r\nand the final patch in this sequence *does* have the failure: https://phabricator.haskell.org/rGHC6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 (along with an improvement in T9675)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11495TH_spliceE5_prof is failing with release candidate 8.0.12020-09-18T20:58:53ZThomas MiedemaTH_spliceE5_prof is failing with release candidate 8.0.1`TH_spliceE5_prof` looks like this:
```
TH_spliceE5_prof::
$(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof
'$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --mak...`TH_spliceE5_prof` looks like this:
```
TH_spliceE5_prof::
$(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof
'$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --make -v0 TH_spliceE5_prof.hs -c
'$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) --make -v0 TH_spliceE5_prof.hs -prof -auto-all -osuf .p.o -o $@
./$@
```
In 4905b83a2d448c65ccced385343d4e8124548a3b, Simon added that `$(ghcThWayFlags)` to the first compilation command. With a release compiler, `ghcThWayFlags` defaults to `-dynamic`. But compiling with `-dynamic` doesn't produce `.dyn_o` files (you need `-dynamic-too` for that, which is enabled by `-XTemplateHaskell`, but \*\*not\*\* when compiling with `-dynamic`), so the second compilation results in:
```
TH_spliceE5_prof.hs:8:17: fatal:
cannot find object file ‘./TH_spliceE5_prof_Lib.dyn_o’
while linking an interpreted expression
make[1]: *** [TH_spliceE5_prof] Error 1
*** unexpected failure for TH_spliceE5_prof(normal)
```
Not passing `-dynamic` fixes the test. But in the function `failNonStd` in `compiler/ghci/Linker.hs` Simon suggests that passing `-dynamic` is necessary:
```
Cannot load -prof objects when GHC is built with -dynamic
To fix this, either:
(1) Use -fexternal-interprter, or
(2) Build the program twice: once with -dynamic, and then
with -prof using -osuf to set a different object file suffix.
```
Some ideas for a solution:
- change that message to not mention `-dynamic`
- always turn on `-dynamic-too` when `-XTemplateHaskell` is on, also when using `-dynamic`
- find the place where `.dyn_o` is expected, and teach it that `.o` might also be ok.
- make `-fexternal-interpreter` the default. Delete the test and a whole bunch of other stuff.
It's all such a mess.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/11260Re-compilation driver/recomp11 test fails2023-10-20T08:03:16ZPeter Trommlerptrommler@acm.orgRe-compilation driver/recomp11 test failsrecomp011:
```
[1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed]
Linking Main ...
4343
+Linking Main ...
4343
```recomp011:
```
[1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed]
Linking Main ...
4343
+Linking Main ...
4343
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/11259Use system runtime linker in GHCi on PowerPC 64 bit2019-11-05T08:18:12ZPeter Trommlerptrommler@acm.orgUse system runtime linker in GHCi on PowerPC 64 bitTeach GHCi to use the system runtime linker to load Haskell libraries on powerpc64.
See the following test failures.
ghcilink004:
```
ghc-stage2: dir004/libfoo.a: unknown architecture (e_machine == 21)
ghc-stage2: panic! (the 'impossi...Teach GHCi to use the system runtime linker to load Haskell libraries on powerpc64.
See the following test failures.
ghcilink004:
```
ghc-stage2: dir004/libfoo.a: unknown architecture (e_machine == 21)
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20151219 for powerpc64-unknown-linux):
loadArchive "dir004/libfoo.a": failed
CallStack (from ImplicitParams):
error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
prog001:
```
ghc-iserv.bin: /home/peter/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a: unknown architecture (e_machine == 21)
ghc-iserv.bin: loadArchive "/home/peter/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a": failed
CallStack (from ImplicitParams):
error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink
ghc-stage2: ghc-iserv terminated (1)
```
Using the system runtime linker fixes 13 failing tests.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| 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":"Use system runtime linker in GHCi on PowerPC 64 bit","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"trommler"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Teach GHCi to use the system runtime linker to load Haskell libraries on powerpc64.\r\n\r\nSee the following test failures.\r\n\r\nghcilink004:\r\n{{{\r\nghc-stage2: dir004/libfoo.a: unknown architecture (e_machine == 21)\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20151219 for powerpc64-unknown-linux):\r\n loadArchive \"dir004/libfoo.a\": failed\r\nCallStack (from ImplicitParams):\r\n error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nprog001:\r\n{{{\r\nghc-iserv.bin: /home/peter/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a: unknown architecture (e_machine == 21)\r\nghc-iserv.bin: loadArchive \"/home/peter/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a\": failed\r\nCallStack (from ImplicitParams):\r\n error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink\r\nghc-stage2: ghc-iserv terminated (1)\r\n}}}\r\n\r\nUsing the system runtime linker fixes 13 failing tests.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.org