GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-12-03T05:03:15Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13632Frontend plugin arguments are reversed2021-12-03T05:03:15ZDouglas Wilsondouglas@well-typed.comFrontend plugin arguments are reversedThe arguments passed to a frontend plugin are passed in the opposite order to that with which they were passed to the command line.
I will attach a diff that modifies the frontend01 test to exhibit the error.
<details><summary>Trac met...The arguments passed to a frontend plugin are passed in the opposite order to that with which they were passed to the command line.
I will attach a diff that modifies the frontend01 test to exhibit the error.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Frontend plugin arguments are reversed","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The arguments passed to a frontend plugin are passed in the opposite order to that with which they were passed to the command line.\r\n\r\nI will attach a diff that modifies the frontend01 test to exhibit the error.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13631In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone2019-07-07T18:20:51ZvantoIn GHCi a result is wrong when -fdefer-typed-holes is used with underscore aloneI open this ticket instead of `#13579` to restate it and I closed the other.\\\\
In fact a result of the compiler which I think is wrong misled me.\\\\
Therefore I close tickets `#13602` and `#13557`.\\\\
In Haskell2010 Language Report i...I open this ticket instead of `#13579` to restate it and I closed the other.\\\\
In fact a result of the compiler which I think is wrong misled me.\\\\
Therefore I close tickets `#13602` and `#13557`.\\\\
In Haskell2010 Language Report it is said that :\\\\
1. underscore "_ " all by itself is a reserved identifier.\\\\
1. underscore "_" is treated as a lowercase letter, and can occur wherever a lowercase letter can.\\\\
So `_e` is an identifier like `__`\\\\
GHCi gives a bad result when he computed the code below.\\\\
```
Prelude> :set -fdefer-typed-holes
Prelude> let f = map (\x -> True) [_, _]
<interactive>:2:27: warning: [-Wtyped-holes]
* Found hole: _ :: a0
Where: `a0' is an ambiguous type variable
* In the expression: _
In the second argument of `map', namely `[_, _]'
In the expression: map (\ x -> True) [_, _]
* Relevant bindings include
f :: [Bool] (bound at <interactive>:2:5)
<interactive>:2:30: warning: [-Wtyped-holes]
* Found hole: _ :: a0
Where: `a0' is an ambiguous type variable
* In the expression: _
In the second argument of `map', namely `[_, _]'
In the expression: map (\ x -> True) [_, _]
* Relevant bindings include
f :: [Bool] (bound at <interactive>:2:5)
Prelude> f
[True,True]
```
The underscore "_" is alone , all by itself and yet is recognized as an identifier, and GHCi gives a result.\\\\
This is the bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I open this ticket instead of {{{#13579}}} to restate it and I closed the other.\\\\\r\nIn fact a result of the compiler which I think is wrong misled me.\\\\\r\nTherefore I close tickets {{{#13602}}} and {{{#13557}}}.\\\\\r\nIn Haskell2010 Language Report it is said that :\\\\\r\n1. underscore \"_ \" all by itself is a reserved identifier.\\\\\r\n2. underscore \"_\" is treated as a lowercase letter, and can occur wherever a lowercase letter can.\\\\\r\nSo {{{_e}}} is an identifier like {{{__}}}\\\\\r\n\r\nGHCi gives a bad result when he computed the code below.\\\\\r\n\r\n\r\n{{{\r\nPrelude> :set -fdefer-typed-holes\r\nPrelude> let f = map (\\x -> True) [_, _]\r\n\r\n<interactive>:2:27: warning: [-Wtyped-holes]\r\n * Found hole: _ :: a0\r\n Where: `a0' is an ambiguous type variable\r\n * In the expression: _\r\n In the second argument of `map', namely `[_, _]'\r\n In the expression: map (\\ x -> True) [_, _]\r\n * Relevant bindings include\r\n f :: [Bool] (bound at <interactive>:2:5)\r\n\r\n<interactive>:2:30: warning: [-Wtyped-holes]\r\n * Found hole: _ :: a0\r\n Where: `a0' is an ambiguous type variable\r\n * In the expression: _\r\n In the second argument of `map', namely `[_, _]'\r\n In the expression: map (\\ x -> True) [_, _]\r\n * Relevant bindings include\r\n f :: [Bool] (bound at <interactive>:2:5)\r\nPrelude> f\r\n[True,True]\r\n}}}\r\nThe underscore \"_\" is alone , all by itself and yet is recognized as an identifier, and GHCi gives a result.\\\\\r\nThis is the bug.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13630ByteString pinned memory can be leaky2021-01-05T18:30:13ZNiklas Hambüchenmail@nh2.meByteString pinned memory can be leakyMy question on IRC:
```
How does memory allocation for pinned blocks work?
Let's say pinned blocks are 4KB in size, and I allocate first a 3 KB
ByteString A and then an 8-byte ByteString B.
Now I GC A, no longer need it.
Then accordi...My question on IRC:
```
How does memory allocation for pinned blocks work?
Let's say pinned blocks are 4KB in size, and I allocate first a 3 KB
ByteString A and then an 8-byte ByteString B.
Now I GC A, no longer need it.
Then according to
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned
"a single pinned object keeps alive the whole block in which it resides",
my small ByteString B keeps the entire block alive.
But what happens with the 3KB in the front of that block?
Will it be re-used by the next ByteString allocation (say 1KB)?
In other words, how smart is allocatePinned as an allocator?
```
The answer:
```
slyfox: nh2: allocatePinned it quite dump. it only allocated from free tail space
```
```
nh2: slyfox: that sounds like a huge potential for memory leak then
slyfox: yes, fragmentation is quite bad for bytestrings
```
So it seems that I can get into the unfortunate situation where a super short `ByteString` of a few bytes can waste an entire 4 KB block of memory; some migth call this a leak.
One idea to solve it seems to be to change standard `ByteStrings` to not pinned, and to allocate pinned ones explicitly when needed. This seems to be an often-discussed topic and not trivial because many `ByteString` functions are implemented using libc FFI functions.
However, it seems there will always be _some_ need for pinned memory, so we should better have an efficient way to manage it in any case.
Efficient here means, for example, to re-use freed memory inside a block instead of only using free tail space.
It seems that `jemalloc` has a feature to use given blocks of memory and provide a `malloc()` functionality inside them:
https://stackoverflow.com/questions/30836359/jemalloc-mmap-and-shared-memory
Perhaps this could be used to provide GHC with a simple method to use pinned memory more efficiently?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2, slyfox |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ByteString pinned memory can be leaky","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2","slyfox"],"type":"Bug","description":"My question on IRC:\r\n\r\n{{{\r\nHow does memory allocation for pinned blocks work?\r\n\r\nLet's say pinned blocks are 4KB in size, and I allocate first a 3 KB\r\nByteString A and then an 8-byte ByteString B.\r\n\r\nNow I GC A, no longer need it.\r\n\r\nThen according to\r\n https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned\r\n\"a single pinned object keeps alive the whole block in which it resides\",\r\nmy small ByteString B keeps the entire block alive.\r\n\r\nBut what happens with the 3KB in the front of that block?\r\nWill it be re-used by the next ByteString allocation (say 1KB)?\r\nIn other words, how smart is allocatePinned as an allocator?\r\n}}}\r\n\r\nThe answer:\r\n\r\n{{{\r\nslyfox: nh2: allocatePinned it quite dump. it only allocated from free tail space\r\n}}}\r\n\r\n{{{\r\nnh2: slyfox: that sounds like a huge potential for memory leak then\r\nslyfox: yes, fragmentation is quite bad for bytestrings\r\n}}}\r\n\r\nSo it seems that I can get into the unfortunate situation where a super short `ByteString` of a few bytes can waste an entire 4 KB block of memory; some migth call this a leak.\r\n\r\nOne idea to solve it seems to be to change standard `ByteStrings` to not pinned, and to allocate pinned ones explicitly when needed. This seems to be an often-discussed topic and not trivial because many `ByteString` functions are implemented using libc FFI functions.\r\n\r\nHowever, it seems there will always be _some_ need for pinned memory, so we should better have an efficient way to manage it in any case.\r\n\r\nEfficient here means, for example, to re-use freed memory inside a block instead of only using free tail space.\r\n\r\nIt seems that `jemalloc` has a feature to use given blocks of memory and provide a `malloc()` functionality inside them:\r\n\r\nhttps://stackoverflow.com/questions/30836359/jemalloc-mmap-and-shared-memory\r\n\r\nPerhaps this could be used to provide GHC with a simple method to use pinned memory more efficiently?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13629sqrt should use machine instruction on x86_642021-03-16T15:30:38ZBen Gamarisqrt should use machine instruction on x86_64The NCG currently implements the square root MachOp with an out-of-line call. This resulted in a large performance regression in `n-body` (see #13570). Fix this.
See discussion [here](https://mail.haskell.org/pipermail/ghc-devs/2017-Apr...The NCG currently implements the square root MachOp with an out-of-line call. This resulted in a large performance regression in `n-body` (see #13570). Fix this.
See discussion [here](https://mail.haskell.org/pipermail/ghc-devs/2017-April/014168.html) as well.https://gitlab.haskell.org/ghc/ghc/-/issues/13628Confusing error message with TypeApplications already enabled2019-07-07T18:20:52ZNiklas Hambüchenmail@nh2.meConfusing error message with TypeApplications already enabledI have `{-# LANGUAGE TypeApplications #-}` in my file, and accidentally wrote a typo: `myFunction@a` (missing space, intended was `myFunction @a`).
GHC 8.0.2 outputs:
```
Pattern syntax in expression context: myFunction@a
Did y...I have `{-# LANGUAGE TypeApplications #-}` in my file, and accidentally wrote a typo: `myFunction@a` (missing space, intended was `myFunction @a`).
GHC 8.0.2 outputs:
```
Pattern syntax in expression context: myFunction@a
Did you mean to enable TypeApplications?
```
I already have TypeApplications on, why does GHC suggest this?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Confusing error message with TypeApplications already enabled","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Bug","description":"I have `{-# LANGUAGE TypeApplications #-}` in my file, and accidentally wrote a typo: `myFunction@a` (missing space, intended was `myFunction @a`).\r\n\r\nGHC 8.0.2 outputs:\r\n\r\n{{{\r\n Pattern syntax in expression context: myFunction@a\r\n Did you mean to enable TypeApplications?\r\n}}}\r\n\r\nI already have TypeApplications on, why does GHC suggest this?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13627IndexError: pop from empty list2019-07-07T18:20:52ZLemmingIndexError: pop from empty list#### How to Reproduce
While doing a GET operation on `/attachment/ticket/13626/`, Trac issued an internal error.
*(please provide additional details here)*
Request parameters:
```
{u'action': u'new', 'path': u'13626/', 'realm': u'tic...#### How to Reproduce
While doing a GET operation on `/attachment/ticket/13626/`, Trac issued an internal error.
*(please provide additional details here)*
Request parameters:
```
{u'action': u'new', 'path': u'13626/', 'realm': u'ticket'}
```
User agent: `#USER_AGENT#`
#### System Information
*Systeminformation nicht verfügbar*
#### Enabled Plugins
*Plugininformation nicht verfügbar*
#### Interface Customization
*Interface customization information not available*
#### Python Traceback
```
Traceback (most recent call last):
File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 623, in _dispatch_request
dispatcher.dispatch(req)
File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 259, in dispatch
iterable=chrome.use_chunked_encoding)
File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 1164, in render_template
encoding='utf-8')
File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 184, in render
return encode(generator, method=method, encoding=encoding, out=out)
File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 58, in encode
for chunk in iterator:
File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 350, in __call__
for kind, data, pos in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 829, in __call__
for kind, data, pos in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 669, in __call__
for kind, data, pos in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 774, in __call__
for kind, data, pos in chain(stream, [(None, None, None)]):
File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 594, in __call__
for ev in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure
for event in stream:
File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 1431, in _strip_accesskeys
for kind, data, pos in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure
for event in stream:
File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 1420, in _generate
for kind, data, pos in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py", line 706, in _unmark
for mark, event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py", line 1101, in __call__
for mark, event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py", line 118, in __iter__
event = self.stream.next()
File "/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py", line 734, in __call__
for mark, event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py", line 702, in _mark
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match
ctxt, start=idx + 1, **vars):
File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match
ctxt, start=idx + 1, **vars):
File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 362, in _match
content = list(content)
File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 326, in _match
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip
event = next()
File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten
for kind, data, pos in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate
subevent = next()
File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip
event = next()
File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten
for kind, data, pos in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate
subevent = next()
File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include
for event in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip
event = next()
File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten
for kind, data, pos in stream:
File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 178, in _generate
for event in msgbuf.translate(gettext(msgbuf.format())):
File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 1051, in translate
events = self.events[order].pop(0)
IndexError: pop from empty list
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"IndexError: pop from empty list","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"==== How to Reproduce ====\r\n\r\nWhile doing a GET operation on `/attachment/ticket/13626/`, Trac issued an internal error.\r\n\r\n''(please provide additional details here)''\r\n\r\nRequest parameters:\r\n{{{\r\n{u'action': u'new', 'path': u'13626/', 'realm': u'ticket'}\r\n}}}\r\n\r\nUser agent: `#USER_AGENT#`\r\n\r\n==== System Information ====\r\n''Systeminformation nicht verfügbar''\r\n\r\n==== Enabled Plugins ====\r\n''Plugininformation nicht verfügbar''\r\n\r\n==== Interface Customization ====\r\n''Interface customization information not available''\r\n\r\n==== Python Traceback ====\r\n{{{\r\nTraceback (most recent call last):\r\n File \"build/bdist.linux-x86_64/egg/trac/web/main.py\", line 623, in _dispatch_request\r\n dispatcher.dispatch(req)\r\n File \"build/bdist.linux-x86_64/egg/trac/web/main.py\", line 259, in dispatch\r\n iterable=chrome.use_chunked_encoding)\r\n File \"build/bdist.linux-x86_64/egg/trac/web/chrome.py\", line 1164, in render_template\r\n encoding='utf-8')\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/core.py\", line 184, in render\r\n return encode(generator, method=method, encoding=encoding, out=out)\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/output.py\", line 58, in encode\r\n for chunk in iterator:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/output.py\", line 350, in __call__\r\n for kind, data, pos in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/output.py\", line 829, in __call__\r\n for kind, data, pos in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/output.py\", line 669, in __call__\r\n for kind, data, pos in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/output.py\", line 774, in __call__\r\n for kind, data, pos in chain(stream, [(None, None, None)]):\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/output.py\", line 594, in __call__\r\n for ev in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/core.py\", line 289, in _ensure\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/core.py\", line 289, in _ensure\r\n for event in stream:\r\n File \"build/bdist.linux-x86_64/egg/trac/web/chrome.py\", line 1431, in _strip_accesskeys\r\n for kind, data, pos in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/core.py\", line 289, in _ensure\r\n for event in stream:\r\n File \"build/bdist.linux-x86_64/egg/trac/web/chrome.py\", line 1420, in _generate\r\n for kind, data, pos in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/core.py\", line 289, in _ensure\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/core.py\", line 289, in _ensure\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py\", line 706, in _unmark\r\n for mark, event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py\", line 1101, in __call__\r\n for mark, event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py\", line 118, in __iter__\r\n event = self.stream.next()\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py\", line 734, in __call__\r\n for mark, event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/filters/transform.py\", line 702, in _mark\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/base.py\", line 618, in _include\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py\", line 378, in _match\r\n ctxt, start=idx + 1, **vars):\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py\", line 378, in _match\r\n ctxt, start=idx + 1, **vars):\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py\", line 362, in _match\r\n content = list(content)\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/base.py\", line 618, in _include\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py\", line 326, in _match\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py\", line 315, in _strip\r\n event = next()\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/base.py\", line 558, in _flatten\r\n for kind, data, pos in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/core.py\", line 289, in _ensure\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/path.py\", line 588, in _generate\r\n subevent = next()\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/base.py\", line 618, in _include\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py\", line 315, in _strip\r\n event = next()\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/base.py\", line 558, in _flatten\r\n for kind, data, pos in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/core.py\", line 289, in _ensure\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/path.py\", line 588, in _generate\r\n subevent = next()\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/base.py\", line 618, in _include\r\n for event in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py\", line 315, in _strip\r\n event = next()\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/template/base.py\", line 558, in _flatten\r\n for kind, data, pos in stream:\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py\", line 178, in _generate\r\n for event in msgbuf.translate(gettext(msgbuf.format())):\r\n File \"/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py\", line 1051, in translate\r\n events = self.events[order].pop(0)\r\nIndexError: pop from empty list\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/13626Ambiguity when exporting a data constructor despite qualification2019-07-07T18:20:52ZLemmingAmbiguity when exporting a data constructor despite qualification```
$ cat A.hs
module A where
data T = Cons
$ cat B.hs
module B (T(T)) where
import qualified A
data T = T
$ ghc-8.2.0.20170422 -Wall B.hs
[2 of 2] Compiling B ( B.hs, B.o ) [A changed]
B.hs:1:11: error:
• Ambigu...```
$ cat A.hs
module A where
data T = Cons
$ cat B.hs
module B (T(T)) where
import qualified A
data T = T
$ ghc-8.2.0.20170422 -Wall B.hs
[2 of 2] Compiling B ( B.hs, B.o ) [A changed]
B.hs:1:11: error:
• Ambiguous occurrence ‘T’
It could refer to either ‘A.T’,
imported qualified from ‘A’ at B.hs:3:1-18
or ‘T’, defined at B.hs:5:1
• In the export: T(T)
|
1 | module B (T(T)) where
| ^^^^
```
There should be no ambiguity, because there is only one data constructor named `T`.
Even if `A.T`'s data constructor would also be called `T`
there would be no ambiguity because `A` is imported with qualification.
The problem does not appear, if `B.T`'s data constructor is named `Cons`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Ambiguity when exporting a data constructor despite qualification","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ cat A.hs\r\nmodule A where\r\n\r\ndata T = Cons\r\n\r\n$ cat B.hs\r\nmodule B (T(T)) where\r\n\r\nimport qualified A\r\n\r\ndata T = T\r\n\r\n$ ghc-8.2.0.20170422 -Wall B.hs\r\n[2 of 2] Compiling B ( B.hs, B.o ) [A changed]\r\n\r\nB.hs:1:11: error:\r\n • Ambiguous occurrence ‘T’\r\n It could refer to either ‘A.T’,\r\n imported qualified from ‘A’ at B.hs:3:1-18\r\n or ‘T’, defined at B.hs:5:1\r\n • In the export: T(T)\r\n |\r\n1 | module B (T(T)) where\r\n | ^^^^\r\n}}}\r\n\r\nThere should be no ambiguity, because there is only one data constructor named `T`.\r\nEven if `A.T`'s data constructor would also be called `T`\r\nthere would be no ambiguity because `A` is imported with qualification.\r\nThe problem does not appear, if `B.T`'s data constructor is named `Cons`.","type_of_failure":"OtherFailure","blocking":[]} -->Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/13625GHC internal error: ‘Y’ is not in scope during type checking, but it passed t...2019-07-07T18:20:53ZMatthew PickeringGHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer```
{-# LANGUAGE TypeInType #-}
data X :: Y where Y :: X
```
The error message is:
```
Bug.hs:2:11: error: …
• GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [r...```
{-# LANGUAGE TypeInType #-}
data X :: Y where Y :: X
```
The error message is:
```
Bug.hs:2:11: error: …
• GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [r1cR :-> APromotionErr TyConPE]
• In the kind ‘Y’
```
Originally reported by \@mietek in #11821
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mietek |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mietek"],"type":"Bug","description":"{{{\r\n{-# LANGUAGE TypeInType #-}\r\ndata X :: Y where Y :: X\r\n}}}\r\n\r\nThe error message is:\r\n\r\n{{{\r\nBug.hs:2:11: error: …\r\n • GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: [r1cR :-> APromotionErr TyConPE]\r\n • In the kind ‘Y’\r\n}}}\r\n\r\nOriginally reported by @mietek in #11821","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13624loadObj() does not respect alignment2021-02-10T08:21:58ZTrevor L. McDonellloadObj() does not respect alignmentThis is perhaps known, but I'll write it down here in case somebody else runs into this problem as well.
Since `loadObj()` just `mmap()`s the entire object file and decodes it *in place*, it does not respect the alignment requirements s...This is perhaps known, but I'll write it down here in case somebody else runs into this problem as well.
Since `loadObj()` just `mmap()`s the entire object file and decodes it *in place*, it does not respect the alignment requirements specified in the section headers. This is problematic for instructions which require alignment, e.g. SSE, AVX.
The attached `map.ll` program is `map (+1)` over an array of floating point numbers. In particular, the core loop is 8-way SIMD vectorised x 4-way unrolled, for 32-elements per loop iteration. A tail loop handles any remainder one-at-a-time.
You can compile it using `llc -filetype=obj -mcpu=native map.ll`. For a CPU with AVX instructions (sandy bridge or later) you should get the following:
```
$ objdump -d map.o
Disassembly of section .text:
0000000000000000 <map>:
0: 49 89 f3 mov %rsi,%r11
3: 49 29 fb sub %rdi,%r11
6: 0f 8e f9 00 00 00 jle 105 <map+0x105>
c: 49 83 fb 20 cmp $0x20,%r11
10: 0f 82 bd 00 00 00 jb d3 <map+0xd3>
16: 4d 89 da mov %r11,%r10
19: 49 83 e2 e0 and $0xffffffffffffffe0,%r10
1d: 4d 89 d9 mov %r11,%r9
20: 49 83 e1 e0 and $0xffffffffffffffe0,%r9
24: 0f 84 a9 00 00 00 je d3 <map+0xd3>
2a: 49 01 fa add %rdi,%r10
2d: 48 8d 44 ba 60 lea 0x60(%rdx,%rdi,4),%rax
32: 49 8d 7c b8 60 lea 0x60(%r8,%rdi,4),%rdi
37: c5 fc 28 05 00 00 00 vmovaps 0x0(%rip),%ymm0 # 3f <map+0x3f>
3e: 00
3f: 4c 89 c9 mov %r9,%rcx
42: 66 66 66 66 66 2e 0f data16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1)
49: 1f 84 00 00 00 00 00
50: c5 f8 10 4f a0 vmovups -0x60(%rdi),%xmm1
55: c5 f8 10 57 c0 vmovups -0x40(%rdi),%xmm2
5a: c5 f8 10 5f e0 vmovups -0x20(%rdi),%xmm3
5f: c5 f8 10 27 vmovups (%rdi),%xmm4
63: c4 e3 75 18 4f b0 01 vinsertf128 $0x1,-0x50(%rdi),%ymm1,%ymm1
6a: c4 e3 6d 18 57 d0 01 vinsertf128 $0x1,-0x30(%rdi),%ymm2,%ymm2
71: c4 e3 65 18 5f f0 01 vinsertf128 $0x1,-0x10(%rdi),%ymm3,%ymm3
78: c4 e3 5d 18 67 10 01 vinsertf128 $0x1,0x10(%rdi),%ymm4,%ymm4
7f: c5 f4 58 c8 vaddps %ymm0,%ymm1,%ymm1
83: c5 ec 58 d0 vaddps %ymm0,%ymm2,%ymm2
87: c5 e4 58 d8 vaddps %ymm0,%ymm3,%ymm3
8b: c5 dc 58 e0 vaddps %ymm0,%ymm4,%ymm4
8f: c4 e3 7d 19 48 b0 01 vextractf128 $0x1,%ymm1,-0x50(%rax)
96: c5 f8 11 48 a0 vmovups %xmm1,-0x60(%rax)
9b: c4 e3 7d 19 50 d0 01 vextractf128 $0x1,%ymm2,-0x30(%rax)
a2: c5 f8 11 50 c0 vmovups %xmm2,-0x40(%rax)
a7: c4 e3 7d 19 58 f0 01 vextractf128 $0x1,%ymm3,-0x10(%rax)
ae: c5 f8 11 58 e0 vmovups %xmm3,-0x20(%rax)
b3: c4 e3 7d 19 60 10 01 vextractf128 $0x1,%ymm4,0x10(%rax)
ba: c5 f8 11 20 vmovups %xmm4,(%rax)
be: 48 83 e8 80 sub $0xffffffffffffff80,%rax
c2: 48 83 ef 80 sub $0xffffffffffffff80,%rdi
c6: 48 83 c1 e0 add $0xffffffffffffffe0,%rcx
ca: 75 84 jne 50 <map+0x50>
cc: 4d 39 cb cmp %r9,%r11
cf: 75 05 jne d6 <map+0xd6>
d1: eb 32 jmp 105 <map+0x105>
d3: 49 89 fa mov %rdi,%r10
d6: 4c 29 d6 sub %r10,%rsi
d9: 4a 8d 04 92 lea (%rdx,%r10,4),%rax
dd: 4b 8d 0c 90 lea (%r8,%r10,4),%rcx
e1: c5 fa 10 05 00 00 00 vmovss 0x0(%rip),%xmm0 # e9 <map+0xe9>
e8: 00
e9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
f0: c5 fa 58 09 vaddss (%rcx),%xmm0,%xmm1
f4: c5 fa 11 08 vmovss %xmm1,(%rax)
f8: 48 83 c0 04 add $0x4,%rax
fc: 48 83 c1 04 add $0x4,%rcx
100: 48 ff ce dec %rsi
103: 75 eb jne f0 <map+0xf0>
105: c5 f8 77 vzeroupper
108: c3 req
```
The attached `test.c` will load the object file and try to execute it. The `#define N` on line 7 will change the size of the array. For fewer than 32 elements this works as expected (where the input array is \[0..N-1\]):
```
$ ./build.sh
+ llc-4.0 -filetype=obj -mcpu=native map.ll
+ ghc --make -no-hs-main test.c
$ ./a.out
array size is 31
calling function...
ok
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0
```
For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault.
```
$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) run
Process 7294 launched: '<snip>/a.out' (x86_64)
array size is 32
calling function...
Process 7294 stopped
* thread #1: tid = 0xc41676, 0x000000010019f207, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x000000010019f207
-> 0x10019f207: vmovaps 0xe1(%rip), %ymm0
0x10019f20f: movq %r9, %rcx
0x10019f212: nopw %cs:(%rax,%rax)
0x10019f220: vmovups -0x60(%rdi), %xmm1
```
The `VMOVAPS` instruction requires the source address to be 32-byte aligned. It is attempting to load 8 floats from one of the const sections (the ones for the +1), but since the section was not loaded at the required alignment, fails.
I've tested this on x86_64 macOS (Mach-O) and ubuntu (ELF). I don't have any other systems to test on.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"loadObj() does not respect alignment","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is perhaps known, but I'll write it down here in case somebody else runs into this problem as well.\r\n\r\nSince `loadObj()` just `mmap()`s the entire object file and decodes it ''in place'', it does not respect the alignment requirements specified in the section headers. This is problematic for instructions which require alignment, e.g. SSE, AVX.\r\n\r\nThe attached `map.ll` program is `map (+1)` over an array of floating point numbers. In particular, the core loop is 8-way SIMD vectorised x 4-way unrolled, for 32-elements per loop iteration. A tail loop handles any remainder one-at-a-time.\r\n\r\nYou can compile it using `llc -filetype=obj -mcpu=native map.ll`. For a CPU with AVX instructions (sandy bridge or later) you should get the following:\r\n\r\n{{{\r\n$ objdump -d map.o\r\nDisassembly of section .text:\r\n\r\n0000000000000000 <map>:\r\n 0:\t49 89 f3 \tmov %rsi,%r11\r\n 3:\t49 29 fb \tsub %rdi,%r11\r\n 6:\t0f 8e f9 00 00 00 \tjle 105 <map+0x105>\r\n c:\t49 83 fb 20 \tcmp $0x20,%r11\r\n 10:\t0f 82 bd 00 00 00 \tjb d3 <map+0xd3>\r\n 16:\t4d 89 da \tmov %r11,%r10\r\n 19:\t49 83 e2 e0 \tand $0xffffffffffffffe0,%r10\r\n 1d:\t4d 89 d9 \tmov %r11,%r9\r\n 20:\t49 83 e1 e0 \tand $0xffffffffffffffe0,%r9\r\n 24:\t0f 84 a9 00 00 00 \tje d3 <map+0xd3>\r\n 2a:\t49 01 fa \tadd %rdi,%r10\r\n 2d:\t48 8d 44 ba 60 \tlea 0x60(%rdx,%rdi,4),%rax\r\n 32:\t49 8d 7c b8 60 \tlea 0x60(%r8,%rdi,4),%rdi\r\n 37:\tc5 fc 28 05 00 00 00 \tvmovaps 0x0(%rip),%ymm0 # 3f <map+0x3f>\r\n 3e:\t00\r\n 3f:\t4c 89 c9 \tmov %r9,%rcx\r\n 42:\t66 66 66 66 66 2e 0f \tdata16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1)\r\n 49:\t1f 84 00 00 00 00 00\r\n 50:\tc5 f8 10 4f a0 \tvmovups -0x60(%rdi),%xmm1\r\n 55:\tc5 f8 10 57 c0 \tvmovups -0x40(%rdi),%xmm2\r\n 5a:\tc5 f8 10 5f e0 \tvmovups -0x20(%rdi),%xmm3\r\n 5f:\tc5 f8 10 27 \tvmovups (%rdi),%xmm4\r\n 63:\tc4 e3 75 18 4f b0 01 \tvinsertf128 $0x1,-0x50(%rdi),%ymm1,%ymm1\r\n 6a:\tc4 e3 6d 18 57 d0 01 \tvinsertf128 $0x1,-0x30(%rdi),%ymm2,%ymm2\r\n 71:\tc4 e3 65 18 5f f0 01 \tvinsertf128 $0x1,-0x10(%rdi),%ymm3,%ymm3\r\n 78:\tc4 e3 5d 18 67 10 01 \tvinsertf128 $0x1,0x10(%rdi),%ymm4,%ymm4\r\n 7f:\tc5 f4 58 c8 \tvaddps %ymm0,%ymm1,%ymm1\r\n 83:\tc5 ec 58 d0 \tvaddps %ymm0,%ymm2,%ymm2\r\n 87:\tc5 e4 58 d8 \tvaddps %ymm0,%ymm3,%ymm3\r\n 8b:\tc5 dc 58 e0 \tvaddps %ymm0,%ymm4,%ymm4\r\n 8f:\tc4 e3 7d 19 48 b0 01 \tvextractf128 $0x1,%ymm1,-0x50(%rax)\r\n 96:\tc5 f8 11 48 a0 \tvmovups %xmm1,-0x60(%rax)\r\n 9b:\tc4 e3 7d 19 50 d0 01 \tvextractf128 $0x1,%ymm2,-0x30(%rax)\r\n a2:\tc5 f8 11 50 c0 \tvmovups %xmm2,-0x40(%rax)\r\n a7:\tc4 e3 7d 19 58 f0 01 \tvextractf128 $0x1,%ymm3,-0x10(%rax)\r\n ae:\tc5 f8 11 58 e0 \tvmovups %xmm3,-0x20(%rax)\r\n b3:\tc4 e3 7d 19 60 10 01 \tvextractf128 $0x1,%ymm4,0x10(%rax)\r\n ba:\tc5 f8 11 20 \tvmovups %xmm4,(%rax)\r\n be:\t48 83 e8 80 \tsub $0xffffffffffffff80,%rax\r\n c2:\t48 83 ef 80 \tsub $0xffffffffffffff80,%rdi\r\n c6:\t48 83 c1 e0 \tadd $0xffffffffffffffe0,%rcx\r\n ca:\t75 84 \tjne 50 <map+0x50>\r\n cc:\t4d 39 cb \tcmp %r9,%r11\r\n cf:\t75 05 \tjne d6 <map+0xd6>\r\n d1:\teb 32 \tjmp 105 <map+0x105>\r\n d3:\t49 89 fa \tmov %rdi,%r10\r\n d6:\t4c 29 d6 \tsub %r10,%rsi\r\n d9:\t4a 8d 04 92 \tlea (%rdx,%r10,4),%rax\r\n dd:\t4b 8d 0c 90 \tlea (%r8,%r10,4),%rcx\r\n e1:\tc5 fa 10 05 00 00 00 \tvmovss 0x0(%rip),%xmm0 # e9 <map+0xe9>\r\n e8:\t00\r\n e9:\t0f 1f 80 00 00 00 00 \tnopl 0x0(%rax)\r\n f0:\tc5 fa 58 09 \tvaddss (%rcx),%xmm0,%xmm1\r\n f4:\tc5 fa 11 08 \tvmovss %xmm1,(%rax)\r\n f8:\t48 83 c0 04 \tadd $0x4,%rax\r\n fc:\t48 83 c1 04 \tadd $0x4,%rcx\r\n 100:\t48 ff ce \tdec %rsi\r\n 103:\t75 eb \tjne f0 <map+0xf0>\r\n 105:\tc5 f8 77 \tvzeroupper\r\n 108:\tc3 \treq\r\n}}}\r\n\r\nThe attached `test.c` will load the object file and try to execute it. The `#define N` on line 7 will change the size of the array. For fewer than 32 elements this works as expected (where the input array is [0..N-1]):\r\n\r\n{{{\r\n$ ./build.sh\r\n+ llc-4.0 -filetype=obj -mcpu=native map.ll\r\n+ ghc --make -no-hs-main test.c\r\n\r\n$ ./a.out\r\narray size is 31\r\ncalling function...\r\nok\r\n1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0\r\n}}}\r\n\r\nFor 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault.\r\n\r\n{{{\r\n$ lldb a.out\r\n(lldb) target create \"a.out\"\r\nCurrent executable set to 'a.out' (x86_64).\r\n(lldb) run\r\nProcess 7294 launched: '<snip>/a.out' (x86_64)\r\narray size is 32\r\ncalling function...\r\nProcess 7294 stopped\r\n* thread #1: tid = 0xc41676, 0x000000010019f207, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)\r\n frame #0: 0x000000010019f207\r\n-> 0x10019f207: vmovaps 0xe1(%rip), %ymm0\r\n 0x10019f20f: movq %r9, %rcx\r\n 0x10019f212: nopw %cs:(%rax,%rax)\r\n 0x10019f220: vmovups -0x60(%rdi), %xmm1\r\n}}}\r\n\r\nThe `VMOVAPS` instruction requires the source address to be 32-byte aligned. It is attempting to load 8 floats from one of the const sections (the ones for the +1), but since the section was not loaded at the required alignment, fails.\r\n\r\nI've tested this on x86_64 macOS (Mach-O) and ubuntu (ELF). I don't have any other systems to test on.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.2Artem PyanykhArtem Pyanykhhttps://gitlab.haskell.org/ghc/ghc/-/issues/13623join points produce bad code for stream fusion2019-07-07T18:20:53Zchoenerzsjoin points produce bad code for stream fusionBelow, I am generating to stream fusion streams xs and ys. Both parameterized on k l. The two streams are then concatenated. Finally I do a strict left fold.
This example needs the 'vector' package but nothing else.
```hs
module Test w...Below, I am generating to stream fusion streams xs and ys. Both parameterized on k l. The two streams are then concatenated. Finally I do a strict left fold.
This example needs the 'vector' package but nothing else.
```hs
module Test where
import Data.Vector.Fusion.Stream.Monadic as S
foo :: Int -> Int -> IO Int
foo = \i j -> S.foldl' (+) 0 $ xs i j S.++ ys i j
where xs k l = S.enumFromStepN k l 2
ys k l = S.enumFromStepN k l 3
{-# Inline xs #-}
{-# Inline ys #-}
{-# Inline foo #-}
```
With ghc-8.0.1 I get nice core:
```hs
$wfoo_r1Ai
$wfoo_r1Ai =
\ ww_s1q5 ww1_s1q9 w_s1q2 ->
letrec {
$s$wfoldlM'_loop_s1xc
$s$wfoldlM'_loop_s1xc =
\ sc_s1x7 sc1_s1x5 sc2_s1x6 sc3_s1x4 ->
case tagToEnum# (># sc2_s1x6 0#) of _ {
False -> (# sc_s1x7, I# sc3_s1x4 #);
True ->
$s$wfoldlM'_loop_s1xc
sc_s1x7
(+# sc1_s1x5 ww1_s1q9)
(-# sc2_s1x6 1#)
(+# sc3_s1x4 sc1_s1x5)
}; } in
letrec {
$s$wfoldlM'_loop1_s1x3
$s$wfoldlM'_loop1_s1x3 =
\ sc_s1x2 sc1_s1x0 sc2_s1x1 sc3_s1wZ ->
case tagToEnum# (># sc2_s1x1 0#) of _ {
False -> $s$wfoldlM'_loop_s1xc sc_s1x2 ww_s1q5 3# sc3_s1wZ;
True ->
$s$wfoldlM'_loop1_s1x3
sc_s1x2
(+# sc1_s1x0 ww1_s1q9)
(-# sc2_s1x1 1#)
(+# sc3_s1wZ sc1_s1x0)
}; } in
$s$wfoldlM'_loop1_s1x3 w_s1q2 ww_s1q5 2# 0#
```
Now the same with ghc-8.2-rc1. Here, [Stream.++](https://github.com/haskell/vector/blob/master/Data/Vector/Fusion/Stream/Monadic.hs) function is not fully optimized away (Left and Right constructors!). Instead we have a join point that executes either of the two parts (xs or ys) based on a `case w2_s1U2 of {Left -> ; Right ->}`.
```hs
$wfoo_r23R
$wfoo_r23R
= \ ww_s1Ue ww1_s1Ui w_s1Ub ->
let {
x1_a1tj
x1_a1tj = I# ww_s1Ue } in
let {
tb_a1wC
tb_a1wC = (x1_a1tj, lvl1_r23Q) } in
let {
lvl2_s1Yh
lvl2_s1Yh = Right tb_a1wC } in
joinrec {
$wfoldlM'_loop_s1U8
$wfoldlM'_loop_s1U8 w1_s1U0 ww2_s1U6 w2_s1U2 w3_s1U3
= case w1_s1U0 of { __DEFAULT ->
case w2_s1U2 of {
Left sa_a1yP ->
case sa_a1yP of { (w4_a1zr, m1_a1zs) ->
case m1_a1zs of { I# x2_a1zw ->
case tagToEnum# (># x2_a1zw 0#) of {
False -> jump $wfoldlM'_loop_s1U8 SPEC ww2_s1U6 lvl2_s1Yh w3_s1U3;
True ->
case w4_a1zr of { I# y_a1xT ->
jump $wfoldlM'_loop_s1U8
SPEC
(+# ww2_s1U6 y_a1xT)
(Left (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#)))
w3_s1U3
}
}
}
};
Right sb_a1z3 ->
case sb_a1z3 of { (w4_a1zr, m1_a1zs) ->
case m1_a1zs of { I# x2_a1zw ->
case tagToEnum# (># x2_a1zw 0#) of {
False -> (# w3_s1U3, I# ww2_s1U6 #);
True ->
case w4_a1zr of { I# y_a1xT ->
jump $wfoldlM'_loop_s1U8
SPEC
(+# ww2_s1U6 y_a1xT)
(Right (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#)))
w3_s1U3
}
}
}
}
}
}; } in
jump $wfoldlM'_loop_s1U8 SPEC 0# (Left (x1_a1tj, lvl_r23P)) w_s1Ub
```
For my stream-fusion heavy code, this yields a slowdown of approximately x4 (10 seconds with ghc-8.2-rc1, 2.5 seconds with ghc-8.0.1).
###
ghc-options:
-O2
-ddump-to-file
-ddump-simpl
-dsuppress-all
> -dshow-passes8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13622Regression: can't export constructor when conflicting, qualified constructor ...2019-07-07T18:20:54ZRyan ScottRegression: can't export constructor when conflicting, qualified constructor is also in scopeI ran into this regression when trying to compile the `ersatz` library with GHC 8.2.1-rc1. Here is a minimized example:
```hs
module Bug (Bits(Bits)) where
import qualified Data.Bits as Bits
newtype Bits = Bits Int
```
Compiling this...I ran into this regression when trying to compile the `ersatz` library with GHC 8.2.1-rc1. Here is a minimized example:
```hs
module Bug (Bits(Bits)) where
import qualified Data.Bits as Bits
newtype Bits = Bits Int
```
Compiling this with GHC 8.0.2 works fine, but with 8.2.1-rc1, you get this error:
```
l$ /opt/ghc/8.2.1/bin/ghci Bug.hs
GHCi, version 8.2.0.20170422: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:1:13: error:
• Ambiguous occurrence ‘Bits’
It could refer to either ‘Bits.Bits’,
imported qualified from ‘Data.Bits’ at Bug.hs:3:1-34
or ‘Bits’, defined at Bug.hs:5:1
• In the export: Bits(Bits)
|
1 | module Bug (Bits(Bits)) where
| ^^^^^^^^^^
```
Despite the fact that `Bits` isn't actually ambiguous, since the `Bits` from `Data.Bits` is qualified.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mpickering |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression: can't export constructor when conflicting, qualified constructor is also in scope","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mpickering"],"type":"Bug","description":"I ran into this regression when trying to compile the `ersatz` library with GHC 8.2.1-rc1. Here is a minimized example:\r\n\r\n{{{#!hs\r\nmodule Bug (Bits(Bits)) where\r\n\r\nimport qualified Data.Bits as Bits\r\n\r\nnewtype Bits = Bits Int\r\n}}}\r\n\r\nCompiling this with GHC 8.0.2 works fine, but with 8.2.1-rc1, you get this error:\r\n\r\n{{{\r\nl$ /opt/ghc/8.2.1/bin/ghci Bug.hs\r\nGHCi, version 8.2.0.20170422: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:1:13: error:\r\n • Ambiguous occurrence ‘Bits’\r\n It could refer to either ‘Bits.Bits’,\r\n imported qualified from ‘Data.Bits’ at Bug.hs:3:1-34\r\n or ‘Bits’, defined at Bug.hs:5:1\r\n • In the export: Bits(Bits)\r\n |\r\n1 | module Bug (Bits(Bits)) where\r\n | ^^^^^^^^^^\r\n}}}\r\n\r\nDespite the fact that `Bits` isn't actually ambiguous, since the `Bits` from `Data.Bits` is qualified.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/13621Problems with injective type families2019-07-07T18:20:54ZIcelandjackProblems with injective type families```hs
{-# LANGUAGE GADTs, TypeInType, DataKinds, TypeFamilyDependencies #-}
import Data.Kind
type family
IB a = res | res -> a where
IB Int = Bool
IB Bool = Int
type Cat k = k -> k -> Type
data F :: Cat Type where
F :: (a ->...```hs
{-# LANGUAGE GADTs, TypeInType, DataKinds, TypeFamilyDependencies #-}
import Data.Kind
type family
IB a = res | res -> a where
IB Int = Bool
IB Bool = Int
type Cat k = k -> k -> Type
data F :: Cat Type where
F :: (a -> IB a) -> F a (IB a)
data Exp :: Type -> Type where
I :: Int -> Exp Int
B :: Bool -> Exp Bool
fmap' :: F a b -> (Exp a -> Exp b)
fmap' (F f) = \case
B b -> I (f b)
I i -> B (f i)
```
I would have thought this should work as well, given that `IB` is injective:
```hs
data F :: Cat Type where
F :: (IB a -> a) -> F (IB a) a
```
but it gives
```hs
fmap' :: F a b -> (Exp a -> Exp b)
fmap' (F f) = \case
B b -> I (f b)
-- c.hs:33:13: error:
-- • Could not deduce: b ~ Int
-- from the context: a ~ IB b
-- bound by a pattern with constructor:
-- F :: forall a. (IB a -> a) -> F (IB a) a,
-- in an equation for ‘fmap'’
-- at c.hs:32:8-10
-- or from: a ~ Bool
-- bound by a pattern with constructor: B :: Bool -> Exp Bool,
-- in a case alternative
-- at c.hs:33:3-5
-- ‘b’ is a rigid type variable bound by
-- the type signature for:
-- fmap' :: forall a b. F a b -> Exp a -> Exp b
-- at c.hs:31:10
-- • In the first argument of ‘I’, namely ‘(f b)’
-- In the expression: I (f b)
-- In a case alternative: B b -> I (f b)
-- • Relevant bindings include
-- f :: IB b -> b (bound at c.hs:32:10)
-- fmap' :: F a b -> Exp a -> Exp b (bound at c.hs:32:1)
-- Failed, modules loaded: none.
```
But if we know that `a ~ Bool` (as we do from matching on `B`), and we know that `a ~ IB b` then by injectivity it should figure that `b ~ Int`?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Problems with injective type families","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["InjectiveFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE GADTs, TypeInType, DataKinds, TypeFamilyDependencies #-}\r\n\r\nimport Data.Kind\r\n\r\ntype family\r\n IB a = res | res -> a where\r\n IB Int = Bool\r\n IB Bool = Int\r\n\r\ntype Cat k = k -> k -> Type\r\n\r\ndata F :: Cat Type where\r\n F :: (a -> IB a) -> F a (IB a)\r\n\r\ndata Exp :: Type -> Type where\r\n I :: Int -> Exp Int\r\n B :: Bool -> Exp Bool\r\n\r\nfmap' :: F a b -> (Exp a -> Exp b)\r\nfmap' (F f) = \\case\r\n B b -> I (f b)\r\n I i -> B (f i)\r\n}}}\r\n\r\nI would have thought this should work as well, given that `IB` is injective:\r\n\r\n{{{#!hs\r\ndata F :: Cat Type where\r\n F :: (IB a -> a) -> F (IB a) a\r\n}}}\r\n\r\nbut it gives\r\n\r\n{{{#!hs\r\nfmap' :: F a b -> (Exp a -> Exp b)\r\nfmap' (F f) = \\case\r\n B b -> I (f b)\r\n\r\n-- c.hs:33:13: error:\r\n-- • Could not deduce: b ~ Int\r\n-- from the context: a ~ IB b\r\n-- bound by a pattern with constructor:\r\n-- F :: forall a. (IB a -> a) -> F (IB a) a,\r\n-- in an equation for ‘fmap'’\r\n-- at c.hs:32:8-10\r\n-- or from: a ~ Bool\r\n-- bound by a pattern with constructor: B :: Bool -> Exp Bool,\r\n-- in a case alternative\r\n-- at c.hs:33:3-5\r\n-- ‘b’ is a rigid type variable bound by\r\n-- the type signature for:\r\n-- fmap' :: forall a b. F a b -> Exp a -> Exp b\r\n-- at c.hs:31:10\r\n-- • In the first argument of ‘I’, namely ‘(f b)’\r\n-- In the expression: I (f b)\r\n-- In a case alternative: B b -> I (f b)\r\n-- • Relevant bindings include\r\n-- f :: IB b -> b (bound at c.hs:32:10)\r\n-- fmap' :: F a b -> Exp a -> Exp b (bound at c.hs:32:1)\r\n-- Failed, modules loaded: none.\r\n}}}\r\n\r\nBut if we know that `a ~ Bool` (as we do from matching on `B`), and we know that `a ~ IB b` then by injectivity it should figure that `b ~ Int`?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13620hsc2hs parses incorrectly '#ifdef' under '#{enum' in '--cross-compile' mode2019-07-07T18:20:55ZSergei Trofimovichhsc2hs parses incorrectly '#ifdef' under '#{enum' in '--cross-compile' modeThe code is simplified version of something from Win32 package (https://github.com/haskell/win32/blob/master/System/Win32/SimpleMAPI.hsc\#L56):
```hs
#{enum Int ,
, a = sizeof(int)
#if 0
, b = sizeof(char)
#endif
}
```
`...The code is simplified version of something from Win32 package (https://github.com/haskell/win32/blob/master/System/Win32/SimpleMAPI.hsc\#L56):
```hs
#{enum Int ,
, a = sizeof(int)
#if 0
, b = sizeof(char)
#endif
}
```
```
$ hsc2hs b.hsc -o b.hs-native
$ hsc2hs b.hsc -o b.hs-cross --cross-compile
b.hsc:1 sizeof(int)
#if 0
is not an integer
```
I'm not sure if it's a valid .hsc but having at least the same (valid or invalid) result in both modes would be nice.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | hsc2hs |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx-, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hsc2hs parses incorrectly '#ifdef' under '#{enum' in '--cross-compile' mode","status":"New","operating_system":"","component":"hsc2hs","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx-","hvr"],"type":"Bug","description":"The code is simplified version of something from Win32 package (https://github.com/haskell/win32/blob/master/System/Win32/SimpleMAPI.hsc#L56):\r\n\r\n{{{#!hs\r\n#{enum Int ,\r\n , a = sizeof(int)\r\n#if 0\r\n , b = sizeof(char)\r\n#endif\r\n }\r\n}}}\r\n\r\n{{{\r\n$ hsc2hs b.hsc -o b.hs-native\r\n$ hsc2hs b.hsc -o b.hs-cross --cross-compile\r\nb.hsc:1 sizeof(int)\r\n#if 0\r\n is not an integer\r\n}}}\r\n\r\nI'm not sure if it's a valid .hsc but having at least the same (valid or invalid) result in both modes would be nice.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13619hsc2hs parses incorrectly c99 style ("/// ...") comments in '--cross-compile'...2019-07-07T18:20:56ZSergei Trofimovichhsc2hs parses incorrectly c99 style ("/// ...") comments in '--cross-compile' modeThe code is simplified version of something from Win32 package
(https://github.com/haskell/win32/blob/master/Graphics/Win32/GDI/Pen.hsc\#L59):
```hs
-- a.hsc
#{enum Int , // "hi" there!
, a = sizeof(int)
}
```
```
$ hsc2hs ...The code is simplified version of something from Win32 package
(https://github.com/haskell/win32/blob/master/Graphics/Win32/GDI/Pen.hsc\#L59):
```hs
-- a.hsc
#{enum Int , // "hi" there!
, a = sizeof(int)
}
```
```
$ hsc2hs a.hsc -o a.hs-cross --cross-compile
$ hsc2hs a.hsc -o a.hs-native
```
```diff
--- a.hs-cross 2017-04-26 21:56:56.157323964 +0100
+++ a.hs-native 2017-04-26 21:57:00.753311717 +0100
@@ -2,3 +2,3 @@
a :: Int
-a = // "hi" there! 4
+a = 4
```
I'm not sure if it's a valid .hsc but having at least the same
(valid or invalid) result in both modes would be nice.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | hsc2hs |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx-, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hsc2hs parses incorrectly c99 style (\"/// ...\") comments in '--cross-compile' mode","status":"New","operating_system":"","component":"hsc2hs","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx-","hvr"],"type":"Bug","description":"The code is simplified version of something from Win32 package\r\n(https://github.com/haskell/win32/blob/master/Graphics/Win32/GDI/Pen.hsc#L59):\r\n\r\n{{{#!hs\r\n-- a.hsc\r\n#{enum Int , // \"hi\" there!\r\n , a = sizeof(int)\r\n }\r\n}}}\r\n\r\n{{{\r\n$ hsc2hs a.hsc -o a.hs-cross --cross-compile\r\n$ hsc2hs a.hsc -o a.hs-native\r\n}}}\r\n{{{#!diff\r\n--- a.hs-cross 2017-04-26 21:56:56.157323964 +0100\r\n+++ a.hs-native 2017-04-26 21:57:00.753311717 +0100\r\n@@ -2,3 +2,3 @@\r\n a :: Int\r\n-a = // \"hi\" there! 4\r\n+a = 4\r\n}}}\r\n\r\nI'm not sure if it's a valid .hsc but having at least the same\r\n(valid or invalid) result in both modes would be nice.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13618Reified data family instances type variables not related to value constructor...2019-07-07T18:20:56ZglguyReified data family instances type variables not related to value constructor fieldsWhen using the reify template-haskell operation on a data family, the returned data instances lose the relationship between the type variables in the parameters and those in the value constructors.
In this paste I show that reify forget...When using the reify template-haskell operation on a data family, the returned data instances lose the relationship between the type variables in the parameters and those in the value constructors.
In this paste I show that reify forgets the relationship, but that declaration splices preserve it. Note the two occurrences of a_6989586621679027007 .
I would specifically expect the occurences of a_6989586621679015819 and a_6989586621679015790 to be the same.
The code that implements this reification is in compiler/typecheck/TcSplice.hs , the template-haskell package merely exposes the functionality, so this is why I've specified "compiler (type checker)"
I've confirmed that this bug exists in GHC 8.0.2 and 8.2.1-rc1. I suspect it exists in older versions, too.
```haskell
$ /Users/emertens/Tools/ghc-8.2.1-rc1/bin/ghci
GHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XTypeFamilies
Prelude> :set -XTemplateHaskell
Prelude> import Language.Haskell.TH
Prelude Language.Haskell.TH> import Text.Show.Pretty (ppShow)
Prelude Language.Haskell.TH Text.Show.Pretty> data family DF a; data instance DF [a] = DFList a
Prelude Language.Haskell.TH Text.Show.Pretty> putStrLn $(stringE . ppShow =<< reify ''DF)
FamilyI
(DataFamilyD
Ghci1.DF [ KindedTV a_6989586621679015789 StarT ] (Just StarT))
[ DataInstD
[]
Ghci1.DF
[ AppT ListT (VarT a_6989586621679015819) ]
Nothing
[ NormalC
Ghci1.DFList
[ ( Bang NoSourceUnpackedness NoSourceStrictness
, VarT a_6989586621679015790
)
]
]
[]
]
Prelude Language.Haskell.TH Text.Show.Pretty> putStrLn $(stringE . ppShow =<< [d| data family DF a; data instance DF [a] = DFList a |])
[ DataFamilyD
DF_6989586621679027004 [ PlainTV a_6989586621679027006 ] Nothing
, DataInstD
[]
DF_6989586621679027004
[ AppT ListT (VarT a_6989586621679027007) ]
Nothing
[ NormalC
DFList_6989586621679027005
[ ( Bang NoSourceUnpackedness NoSourceStrictness
, VarT a_6989586621679027007
)
]
]
[]
]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reified data family instances type variables not related to value constructor fields","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using the reify template-haskell operation on a data family, the returned data instances lose the relationship between the type variables in the parameters and those in the value constructors.\r\n\r\nIn this paste I show that reify forgets the relationship, but that declaration splices preserve it. Note the two occurrences of a_6989586621679027007 .\r\n\r\nI would specifically expect the occurences of a_6989586621679015819 and a_6989586621679015790 to be the same.\r\n\r\nThe code that implements this reification is in compiler/typecheck/TcSplice.hs , the template-haskell package merely exposes the functionality, so this is why I've specified \"compiler (type checker)\"\r\n\r\nI've confirmed that this bug exists in GHC 8.0.2 and 8.2.1-rc1. I suspect it exists in older versions, too.\r\n\r\n{{{#!haskell\r\n$ /Users/emertens/Tools/ghc-8.2.1-rc1/bin/ghci\r\nGHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XTypeFamilies\r\nPrelude> :set -XTemplateHaskell\r\nPrelude> import Language.Haskell.TH\r\nPrelude Language.Haskell.TH> import Text.Show.Pretty (ppShow)\r\nPrelude Language.Haskell.TH Text.Show.Pretty> data family DF a; data instance DF [a] = DFList a\r\nPrelude Language.Haskell.TH Text.Show.Pretty> putStrLn $(stringE . ppShow =<< reify ''DF)\r\nFamilyI\r\n (DataFamilyD\r\n Ghci1.DF [ KindedTV a_6989586621679015789 StarT ] (Just StarT))\r\n [ DataInstD\r\n []\r\n Ghci1.DF\r\n [ AppT ListT (VarT a_6989586621679015819) ]\r\n Nothing\r\n [ NormalC\r\n Ghci1.DFList\r\n [ ( Bang NoSourceUnpackedness NoSourceStrictness\r\n , VarT a_6989586621679015790\r\n )\r\n ]\r\n ]\r\n []\r\n ]\r\nPrelude Language.Haskell.TH Text.Show.Pretty> putStrLn $(stringE . ppShow =<< [d| data family DF a; data instance DF [a] = DFList a |])\r\n[ DataFamilyD\r\n DF_6989586621679027004 [ PlainTV a_6989586621679027006 ] Nothing\r\n, DataInstD\r\n []\r\n DF_6989586621679027004\r\n [ AppT ListT (VarT a_6989586621679027007) ]\r\n Nothing\r\n [ NormalC\r\n DFList_6989586621679027005\r\n [ ( Bang NoSourceUnpackedness NoSourceStrictness\r\n , VarT a_6989586621679027007\r\n )\r\n ]\r\n ]\r\n []\r\n]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/13617GHCi linker does not honor alignment of sections.2019-07-07T18:20:57ZRyan ScottGHCi linker does not honor alignment of sections.This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unf...This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unfortunately, I can't quite figure out a way to reproduce this bug without `cabal`, so I've put the source code at https://github.com/RyanGlScott/hmatrix-segfault. You can reproduce this bug by doing the following:
```
$ git clone https://github.com/RyanGlScott/hmatrix-segfault
$ git reset 2bfe38f964fca64dd776993c89ec59d35fb368a5
$ cd hmatrix-segfault/
$ cabal install
$ runghc exe/Main.hs
Access violation in generated code when reading ffffffffffffffff
```
Running `Main.hs` in GHCi crashes, whereas compiling it works:
```
$ ghc exe/Main.hs
$ ./exe/Main.exe
[1,1,1,1,1,1,1,1,1,1,1,1]
```
I've reproduced this with GHC 7.10.3, 8.0.2, and 8.2.1-rc1.
There are a couple of things that appear to be necessary to trigger the segfault:
1. You need to have `-O4` under `cc-options` in `hmatrix-segfault.cabal`.
1. You need to define the [FunCodeS](https://github.com/RyanGlScott/hmatrix-segfault/blob/2bfe38f964fca64dd776993c89ec59d35fb368a5/src/Internal/Vectorized.hs#L38) datatype.
Removing either of these things causes the program to work again under GHCi.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx- |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segfault in Windows GHCi involving C code compiled with -O4","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx-"],"type":"Bug","description":"This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unfortunately, I can't quite figure out a way to reproduce this bug without `cabal`, so I've put the source code at https://github.com/RyanGlScott/hmatrix-segfault. You can reproduce this bug by doing the following:\r\n\r\n{{{\r\n$ git clone https://github.com/RyanGlScott/hmatrix-segfault\r\n$ git reset 2bfe38f964fca64dd776993c89ec59d35fb368a5\r\n$ cd hmatrix-segfault/\r\n$ cabal install\r\n$ runghc exe/Main.hs\r\nAccess violation in generated code when reading ffffffffffffffff\r\n}}}\r\n\r\nRunning `Main.hs` in GHCi crashes, whereas compiling it works:\r\n\r\n{{{\r\n$ ghc exe/Main.hs\r\n$ ./exe/Main.exe\r\n[1,1,1,1,1,1,1,1,1,1,1,1]\r\n}}}\r\n\r\nI've reproduced this with GHC 7.10.3, 8.0.2, and 8.2.1-rc1.\r\n\r\nThere are a couple of things that appear to be necessary to trigger the segfault:\r\n\r\n1. You need to have `-O4` under `cc-options` in `hmatrix-segfault.cabal`.\r\n2. You need to define the [https://github.com/RyanGlScott/hmatrix-segfault/blob/2bfe38f964fca64dd776993c89ec59d35fb368a5/src/Internal/Vectorized.hs#L38 FunCodeS] datatype.\r\n\r\nRemoving either of these things causes the program to work again under GHCi.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/13616Old file used when later calls to GHC omit -dynamic-too2021-10-19T08:00:43ZJoachim Breitnermail@joachim-breitner.deOld file used when later calls to GHC omit -dynamic-tooThis may possibly only hurt few people who develop Plugins, but it is still quite annoying: If `ghc`, in `--make` mode, recompiles a plugin that it is going to use, but without `-dynamic-too`, it will create new `.dyn` and `.o` files, bu...This may possibly only hurt few people who develop Plugins, but it is still quite annoying: If `ghc`, in `--make` mode, recompiles a plugin that it is going to use, but without `-dynamic-too`, it will create new `.dyn` and `.o` files, but it will happily use the old `.dyn_hs` or `.dyn_o` files that are still lying around.
I guess the desired behavior is: If it determines that it needs the dynamically compiled version of some module, and it is recompiling the module, then it should complain instead of later either ungracefully falling over the missing `.dyn_o` file or – worse – using an old one.
This script reproduces the issue:
```
\#!/bin/bash
rm -f \*.o \*.hi \*.dyn_o \*.dyn_hi
cat \> Plugin.hs \<\<__END__
module Plugin where
import GhcPlugins
plugin :: Plugin
plugin = defaultPlugin { installCoreToDos = install }
install :: \[CommandLineOption\] -\> \[CoreToDo\] -\> CoreM \[CoreToDo\]
install _ _ = error "First version"
__END__
cat \> Code.hs \<\<__END__
{-\# OPTIONS_GHC -O -fplugin Plugin \#-}
module Code where
__END__
echo "No dynamic file found (fine, but the error message could be more helpful)"
ghc -package ghc Code.hs -fforce-recomp
echo "Compiling with -dynamic-too"
ghc -dynamic-too -package ghc Code.hs -fforce-recomp
cat \> Plugin.hs \<\<__END__
module Plugin where
import GhcPlugins
plugin :: Plugin
plugin = defaultPlugin { installCoreToDos = install }
install :: \[CommandLineOption\] -\> \[CoreToDo\] -\> CoreM \[CoreToDo\]
install _ _ = error "Second version"
__END__
echo "Recompiling without -dynamic-too, it still uses the old file"
ghc -package ghc Code.hs -fforce-recomp
echo "Recompiling with -dynamic-too, now it works"
ghc -dynamic-too -package ghc Code.hs -fforce-recomp
```
And here is the slightly redacted output:
```
$ ./repro.sh
No dynamic file found (fine, but the error message could be more helpful)
[1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o )
[2 of 2] Compiling Code ( Code.hs, Code.o )
<no location info>: fatal:
cannot find object file ‘./Plugin.dyn_o’
while linking an interpreted expression
Compiling with -dynamic-too
[1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o )
[2 of 2] Compiling Code ( Code.hs, Code.o )
ghc: panic! (the 'impossible' happened)
First version
Recompiling without -dynamic-too, it still uses the old file
[1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o )
[2 of 2] Compiling Code ( Code.hs, Code.o )
ghc: panic! (the 'impossible' happened)
First version
Recompiling with -dynamic-too, now it works
[1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o )
[2 of 2] Compiling Code ( Code.hs, Code.o )
ghc: panic! (the 'impossible' happened)
Second version
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Old file used when later calls to GHC omit -dynamic-too","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This may possibly only hurt few people who develop Plugins, but it is still quite annoying: If `ghc`, in `--make` mode, recompiles a plugin that it is going to use, but without `-dynamic-too`, it will create new `.dyn` and `.o` files, but it will happily use the old `.dyn_hs` or `.dyn_o` files that are still lying around.\r\n\r\nI guess the desired behavior is: If it determines that it needs the dynamically compiled version of some module, and it is recompiling the module, then it should complain instead of later either ungracefully falling over the missing `.dyn_o` file or – worse – using an old one.\r\n\r\nThis script reproduces the issue:\r\n{{{\r\n#!/bin/bash\r\n\r\nrm -f *.o *.hi *.dyn_o *.dyn_hi\r\n\r\ncat > Plugin.hs <<__END__\r\nmodule Plugin where\r\nimport GhcPlugins\r\nplugin :: Plugin\r\nplugin = defaultPlugin { installCoreToDos = install }\r\n\r\ninstall :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]\r\ninstall _ _ = error \"First version\"\r\n__END__\r\n\r\ncat > Code.hs <<__END__\r\n{-# OPTIONS_GHC -O -fplugin Plugin #-}\r\nmodule Code where\r\n__END__\r\n\r\necho \"No dynamic file found (fine, but the error message could be more helpful)\"\r\n\r\nghc -package ghc Code.hs -fforce-recomp\r\n\r\necho \"Compiling with -dynamic-too\"\r\n\r\nghc -dynamic-too -package ghc Code.hs -fforce-recomp\r\n\r\ncat > Plugin.hs <<__END__\r\nmodule Plugin where\r\nimport GhcPlugins\r\nplugin :: Plugin\r\nplugin = defaultPlugin { installCoreToDos = install }\r\n\r\ninstall :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]\r\ninstall _ _ = error \"Second version\"\r\n__END__\r\n\r\necho \"Recompiling without -dynamic-too, it still uses the old file\"\r\n\r\nghc -package ghc Code.hs -fforce-recomp\r\n\r\necho \"Recompiling with -dynamic-too, now it works\"\r\n\r\nghc -dynamic-too -package ghc Code.hs -fforce-recomp\r\n}}}\r\nAnd here is the slightly redacted output:\r\n{{{\r\n$ ./repro.sh \r\nNo dynamic file found (fine, but the error message could be more helpful)\r\n[1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o )\r\n[2 of 2] Compiling Code ( Code.hs, Code.o )\r\n<no location info>: fatal:\r\n cannot find object file ‘./Plugin.dyn_o’\r\n while linking an interpreted expression\r\n\r\nCompiling with -dynamic-too\r\n[1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o )\r\n[2 of 2] Compiling Code ( Code.hs, Code.o )\r\nghc: panic! (the 'impossible' happened)\r\n\tFirst version\r\n\r\nRecompiling without -dynamic-too, it still uses the old file\r\n[1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o )\r\n[2 of 2] Compiling Code ( Code.hs, Code.o )\r\nghc: panic! (the 'impossible' happened)\r\n\tFirst version\r\n\r\nRecompiling with -dynamic-too, now it works\r\n[1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o )\r\n[2 of 2] Compiling Code ( Code.hs, Code.o )\r\nghc: panic! (the 'impossible' happened)\r\n\tSecond version\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13615Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators2019-07-07T18:20:57ZpacakNondeterminism in ‘pure’ function w/ parallel evaluation & memo combinatorsThe example below uses in-place copies (mostly to fix dependencies
and to make it more self-contained) of `parallel` (modified),
`unordered-containers` (modified), and `hashable`. Its behavior is
nondeterministic, despite using only supp...The example below uses in-place copies (mostly to fix dependencies
and to make it more self-contained) of `parallel` (modified),
`unordered-containers` (modified), and `hashable`. Its behavior is
nondeterministic, despite using only supposedly pure operations.
Aforementioned aside, it only depends on `base` and `deepseq`, and there's
no `unsafePtrEq` involved at all. The affected `fromListWith` uses `foldl'`
to effect in-place `HashMap` updates using `unsafe{Thaw,Freeze}`.
I don't see how references to intermediate versions of `HashMap` could possibly leak
out, so in-place updates seem valid to me.
Strictifying (or even `rnf`ing) the arguments to `unsafeInsertWith` doesn't
help. The issue is reproducible with `-O0` on `HEAD` but not with `-O2`; On
1. 0.2 and 7.10.1, it can also be reproduced with `-O2`.
```
sum . map snd = sum . map snd . toList . fromListWith (+)
```
The above identity fails when the input contains values constructed using
*both* memo combinators and parallel evaluation strategies.
I have identified the in-place-update that needs to be replaced with
copy-and-update to make things work―patch `unsafeInsertWith.go` in `unordered-containers-0.2.8.0/Data/HashMap/Strict.hs`, under the `BitmapIndexed` pattern as follows:
```
- A.unsafeUpdateM ary i st'
- return t
+ let ary' = A.update ary i st'
+ return $ BitmapIndexed b ary'
```
Steps to reproduce:
```
git clone https://github.com/pacak/cuddly-bassoon && cd cuddly-bassoon
cabal new-build
dist-newstyle/build/gamebooksolver-0.1.0.0/build/gamebooksolver-solvebook02/gamebooksolver-solvebook02
```
This will either finish successfully producing no output, or will die
with an `error` from the `regroup` function in `src/Solver.hs`.
Your machine must have at least 2 CPU cores to reproduce the problem; also
it will not show up with `+RTS -N1`.
This issue was first reported here:
https://github.com/tibbe/unordered-containers/issues/1478.2.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/13614Rewrite rules not applied exhaustively when simplifying from plugin2019-07-07T18:20:58ZJoachim Breitnermail@joachim-breitner.deRewrite rules not applied exhaustively when simplifying from pluginConsider this program:
```
{-# OPTIONS_GHC -O -fplugin TestPlugin #-}
module Test where
foo :: Int -> Int
foo = id
{-# INLINE [0] foo #-}
{-# RULES
"foo1" [1] foo 1 = foo 2
"foo2" [1] foo 2 = foo 3
#-}
fun :: Int -> Int -> Int
fun =...Consider this program:
```
{-# OPTIONS_GHC -O -fplugin TestPlugin #-}
module Test where
foo :: Int -> Int
foo = id
{-# INLINE [0] foo #-}
{-# RULES
"foo1" [1] foo 1 = foo 2
"foo2" [1] foo 2 = foo 3
#-}
fun :: Int -> Int -> Int
fun = (+)
{-# NOINLINE fun #-}
test = foo 1 `fun` foo 2
```
I would expect that one run of the simplifier in phase `1` will turn this into
```
test = foo 3 `fun` foo 3
```
I am using this plugin to test this:
```
module TestPlugin where
import System.Exit
import Control.Monad
import GhcPlugins
import Simplify
import CoreStats
import SimplMonad
import FamInstEnv
import SimplEnv
-- Plugin boiler plate
plugin :: Plugin
plugin = defaultPlugin { installCoreToDos = install }
install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
install _ (simpl:xs) = return $ simpl : pass : xs
where pass = CoreDoPluginPass "Test" testPass
-- The plugin
testPass :: ModGuts -> CoreM ModGuts
testPass guts = do
let [expr] = [ e | NonRec v e <- mg_binds guts
, occNameString (occName v) == "test" ]
simplified_expression <- simplify guts expr
putMsg $
text "Test" $$
nest 4 (hang (text "Before" <> colon) 4 (ppr expr)) $$
nest 4 (hang (text "After" <> colon) 4 (ppr simplified_expression))
liftIO $ exitFailure
-- A simplifier
simplify :: ModGuts -> CoreExpr -> CoreM CoreExpr
simplify guts expr = do
dflags <- getDynFlags
let dflags' = dflags { ufVeryAggressive = True }
us <- liftIO $ mkSplitUniqSupply 's'
let sz = exprSize expr
rule_base <- getRuleBase
vis_orphs <- getVisibleOrphanMods
let rule_base2 = extendRuleBaseList rule_base (mg_rules guts)
let rule_env = RuleEnv rule_base2 vis_orphs
(expr', _) <- liftIO $ initSmpl dflags' rule_env emptyFamInstEnvs us sz $
simplExpr (simplEnv 1) >=> simplExpr (simplEnv 1) $
expr
return expr'
simplEnv :: Int -> SimplEnv
simplEnv p = mkSimplEnv $ SimplMode { sm_names = ["Test"]
, sm_phase = Phase p
, sm_rules = True
, sm_inline = True
, sm_eta_expand = True
, sm_case_case = True }
```
But I get:
```
$ ghc-head -package ghc Test.hs
[1 of 2] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o )
[2 of 2] Compiling Test ( Test.hs, Test.o )
Test
Before: fun (foo (GHC.Types.I# 1#)) (foo (GHC.Types.I# 2#))
After: fun (foo (GHC.Types.I# 2#)) (foo (GHC.Types.I# 3#))
```
If I however compile this without the plugin, and look at what’s happening with `-dverbose-core2core`, I observe this:
```
…
test :: Int
test = fun (foo (GHC.Types.I# 1#)) (foo (GHC.Types.I# 2#))
…
==================== Simplifier ====================
Max iterations = 4
SimplMode {Phase = 1 [main],
inline,
rules,
eta-expand,
case-of-case}
…
test :: Int
test = fun (foo (GHC.Types.I# 3#)) (foo (GHC.Types.I# 3#))
…
```
So what am I doing wrong in my plugin? Any help is appreciated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Rewrite rules not applied exhaustively when simplifying from plugin","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this program:\r\n{{{\r\n{-# OPTIONS_GHC -O -fplugin TestPlugin #-}\r\nmodule Test where\r\n\r\nfoo :: Int -> Int\r\nfoo = id\r\n{-# INLINE [0] foo #-}\r\n\r\n{-# RULES\r\n\"foo1\" [1] foo 1 = foo 2\r\n\"foo2\" [1] foo 2 = foo 3\r\n #-}\r\n\r\nfun :: Int -> Int -> Int\r\nfun = (+)\r\n{-# NOINLINE fun #-}\r\n\r\ntest = foo 1 `fun` foo 2\r\n}}}\r\n\r\nI would expect that one run of the simplifier in phase `1` will turn this into\r\n{{{\r\ntest = foo 3 `fun` foo 3\r\n}}}\r\n\r\nI am using this plugin to test this:\r\n{{{\r\nmodule TestPlugin where\r\n\r\nimport System.Exit\r\nimport Control.Monad\r\n\r\nimport GhcPlugins\r\nimport Simplify\r\nimport CoreStats\r\nimport SimplMonad\r\nimport FamInstEnv\r\nimport SimplEnv\r\n\r\n-- Plugin boiler plate\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin { installCoreToDos = install }\r\n\r\ninstall :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]\r\ninstall _ (simpl:xs) = return $ simpl : pass : xs\r\n where pass = CoreDoPluginPass \"Test\" testPass\r\n\r\n-- The plugin\r\n\r\ntestPass :: ModGuts -> CoreM ModGuts\r\ntestPass guts = do\r\n let [expr] = [ e | NonRec v e <- mg_binds guts\r\n , occNameString (occName v) == \"test\" ]\r\n simplified_expression <- simplify guts expr\r\n\r\n putMsg $\r\n text \"Test\" $$\r\n nest 4 (hang (text \"Before\" <> colon) 4 (ppr expr)) $$\r\n nest 4 (hang (text \"After\" <> colon) 4 (ppr simplified_expression))\r\n\r\n liftIO $ exitFailure\r\n\r\n-- A simplifier\r\n\r\nsimplify :: ModGuts -> CoreExpr -> CoreM CoreExpr\r\nsimplify guts expr = do\r\n dflags <- getDynFlags\r\n\r\n let dflags' = dflags { ufVeryAggressive = True }\r\n us <- liftIO $ mkSplitUniqSupply 's'\r\n let sz = exprSize expr\r\n\r\n rule_base <- getRuleBase\r\n vis_orphs <- getVisibleOrphanMods\r\n let rule_base2 = extendRuleBaseList rule_base (mg_rules guts)\r\n let rule_env = RuleEnv rule_base2 vis_orphs\r\n\r\n (expr', _) <- liftIO $ initSmpl dflags' rule_env emptyFamInstEnvs us sz $\r\n simplExpr (simplEnv 1) >=> simplExpr (simplEnv 1) $\r\n expr\r\n return expr'\r\n\r\nsimplEnv :: Int -> SimplEnv\r\nsimplEnv p = mkSimplEnv $ SimplMode { sm_names = [\"Test\"]\r\n , sm_phase = Phase p\r\n , sm_rules = True\r\n , sm_inline = True\r\n , sm_eta_expand = True\r\n , sm_case_case = True }\r\n}}}\r\n\r\nBut I get:\r\n\r\n{{{\r\n$ ghc-head -package ghc Test.hs\r\n[1 of 2] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o )\r\n[2 of 2] Compiling Test ( Test.hs, Test.o )\r\nTest\r\n Before: fun (foo (GHC.Types.I# 1#)) (foo (GHC.Types.I# 2#))\r\n After: fun (foo (GHC.Types.I# 2#)) (foo (GHC.Types.I# 3#))\r\n}}}\r\n\r\nIf I however compile this without the plugin, and look at what’s happening with `-dverbose-core2core`, I observe this:\r\n\r\n{{{\r\n…\r\ntest :: Int\r\ntest = fun (foo (GHC.Types.I# 1#)) (foo (GHC.Types.I# 2#))\r\n…\r\n==================== Simplifier ====================\r\n Max iterations = 4\r\n SimplMode {Phase = 1 [main],\r\n inline,\r\n rules,\r\n eta-expand,\r\n case-of-case}\r\n…\r\ntest :: Int\r\ntest = fun (foo (GHC.Types.I# 3#)) (foo (GHC.Types.I# 3#))\r\n…\r\n}}}\r\n\r\nSo what am I doing wrong in my plugin? Any help is appreciated.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13613Simplify fixIO2019-07-07T18:20:58ZDavid FeuerSimplify fixIONow that we have `noDuplicate#`, I think we can make `fixIO` much simpler, and perhaps also faster, using something like what we do for `ST`.
```hs
data Res a = Res (# State# RealWorld, a #)
fixIO f = IO $ \s ->
let Res r@(# _s', a #...Now that we have `noDuplicate#`, I think we can make `fixIO` much simpler, and perhaps also faster, using something like what we do for `ST`.
```hs
data Res a = Res (# State# RealWorld, a #)
fixIO f = IO $ \s ->
let Res r@(# _s', a #) = unIO (noDuplicate >> f a) s
in r
```
If `f` forks an `IO` thread demanding `a`, the `noDuplicate` should ensure that the computation is not re-entered, and the thread should wait for the main computation to complete.
So I believe, anyway. The comment about eager blackholing here is a bit vague and doesn't give an example.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Simplify fixIO","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Now that we have `noDuplicate#`, I think we can make `fixIO` much simpler, and perhaps also faster, using something like what we do for `ST`.\r\n\r\n{{{#!hs\r\ndata Res a = Res (# State# RealWorld, a #)\r\n\r\nfixIO f = IO $ \\s ->\r\n let Res r@(# _s', a #) = unIO (noDuplicate >> f a) s\r\n in r\r\n}}}\r\n\r\nIf `f` forks an `IO` thread demanding `a`, the `noDuplicate` should ensure that the computation is not re-entered, and the thread should wait for the main computation to complete.\r\n\r\nSo I believe, anyway. The comment about eager blackholing here is a bit vague and doesn't give an example.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1