#7241: GHC-7.6.1 panics on template haskell code
---------------------------------------+-----------------------------------
Reporter: akamaus | Owner: Yuras
Type: bug | Status: new
Priority: normal | Milestone: 7.8.3
Component: Template Haskell | Version: 7.6.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Compile-time crash | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets:
---------------------------------------+-----------------------------------
Changes (by Yuras):
* owner: simonpj => Yuras
Comment:
So, the comment added in
changeset:d8d798b1b33ab0593ed03f193360b8725ba2c2ba is not fully correct.
`findLocalDupsRdrEnv` doesn't catch this particular case because duplicate
`Name`s are totally identical, including `SrcSpan`.
I'll prepare a patch to emit error in case of duplicate GRE. The test case
from #8932 will produce two errors, but I think it is ok. Definitely
better then obscure panic.
Please let me know if I'm going in wrong direction.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7241#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4213: LLVM: Add support for TNTC to LLVM compiler suite
-------------------------------------+------------------------------------
Reporter: dterei | Owner: dterei
Type: feature request | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler (LLVM) | Version: 6.13
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by bgamari):
I have the beginning of a patch for symbol offset support here,
https://github.com/bgamari/llvm/compare/symbol-offset#diff-
c532266337d9a5b54a3b1dc8c25df12fR551.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9139: Using lift with StateT and Maybe on GHCI
------------------------------------+----------------------------
Reporter: Jefffrey | Owner:
Type: bug | Status: new
Priority: low | Milestone:
Component: GHCi | Version: 7.6.3
Keywords: | Operating System: MacOS X
Architecture: Unknown/Multiple | Type of failure: Other
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
------------------------------------+----------------------------
I was playing around with `StateT` and `Maybe` today and I run the
following two commands (consider that `TC` == `import qualified
Control.Monad.Trans.Class as TC`:
{{{
ghci> let g = TC.lift Just [3, 4] :: StateT [Int] Maybe Int
}}}
which led to a:
{{{
<interactive>:54:9:
Couldn't match kind `* -> *' with `*'
Expected type: [t0] -> StateT [Int] Maybe Int
Actual type: [t0] -> StateT [Int] Maybe Int
Kind incompatibility when matching types:
[t_i] :: * -> *
[t0] :: *
The function `TC.lift'ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-apple-darwin):
kindFunResult
<<details unavailable>>
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
and
{{{
> let g = TC.lift Just (1, [3, 4]) :: StateT [Int] Maybe Int
}}}
which led to:
{{{
<interactive>:55:9:
Couldn't match kind `* -> *' with `*'
Expected type: (t0, [t1]) -> StateT [Int] Maybe Int
Actual type: (t0, [t1]) -> StateT [Int] Maybe Int
Kind incompatibility when matching types:
(t_i, [t_l]) :: * -> *
(t0, [t1]) :: *
The function `TC.lift'ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-apple-darwin):
kindFunResult
<<details unavailable>>
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
I'm just doing what the last line asked me. :)
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9139>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4213: LLVM: Add support for TNTC to LLVM compiler suite
-------------------------------------+------------------------------------
Reporter: dterei | Owner: dterei
Type: feature request | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler (LLVM) | Version: 6.13
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by bgamari):
Replying to [comment:13 altaic]:
> Not necessarily, I think. Sure, the symbols point to the beginning of
the prefix data rather than the function body, however twiddling the
symbol table is a lot easier than mangling the whole assembly file.
Coincidentally, using the LLVM API allows us mutable access to the symbol
table among other things.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4213: LLVM: Add support for TNTC to LLVM compiler suite
-------------------------------------+------------------------------------
Reporter: dterei | Owner: dterei
Type: feature request | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler (LLVM) | Version: 6.13
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by awson):
I'm extremely sorry for a kind of OT. There is another LLVM/infotable
related ticket, which I don't know how to solve
[https://ghc.haskell.org/trac/ghc/ticket/8974 without the mangler]. Could
you, please, look into it and check if we can fix that without mangler or,
perhaps, understand what a feature we could ask LLVM people to introduce.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4213: LLVM: Add support for TNTC to LLVM compiler suite
-------------------------------------+------------------------------------
Reporter: dterei | Owner: dterei
Type: feature request | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler (LLVM) | Version: 6.13
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by altaic):
Not necessarily, I think. Sure, the symbols point to the beginning of the
prefix data rather than the function body, however twiddling the symbol
table is a lot easier than mangling the whole assembly file.
Coincidentally, using the LLVM API allows us mutable access to the symbol
table among other things.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4213: LLVM: Add support for TNTC to LLVM compiler suite
-------------------------------------+------------------------------------
Reporter: dterei | Owner: dterei
Type: feature request | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler (LLVM) | Version: 6.13
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by bgamari):
Looking at the semantics of LLVM's prefix data concept, it seems like it
doesn't map terribly well on to our use-case. Namely, the `prefix`
attribute allows you to prepend arbitrary data to the beginning of the
symbol's definition. While we would want LLVM to place the symbol's
address after info table, naive use of prefix data would produce symbols
pointing at the beginning of each function's info table.
The documentation suggests that this is supposed to be worked around by
beginning the prefix data with a trampoline to jump to the true beginning
of the symbol. Given we already have a hack that works, I don't see any
good reason to implement this hack.
However, when used with another pending LLVM
[feature](http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html)
allowing an offset to be applied to a symbol's address prefix data will
become much more useful. I suggest we hold off on using LLVM's prefix data
until this has been implemented. Unfortunately, it seems that the proposal
is more than a year old with no activity but I can try to resuscitate it.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4213: LLVM: Add support for TNTC to LLVM compiler suite
-------------------------------------+------------------------------------
Reporter: dterei | Owner: dterei
Type: feature request | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler (LLVM) | Version: 6.13
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case: | Blocked By:
Blocking: | Related Tickets:
-------------------------------------+------------------------------------
Comment (by altaic):
I just had a look at the llvm codegen and this looks pretty simple to
implement. If I've got some time in the next couple days, I may have a
crack at it.
On a related note, is there any interest in using the llvm api directly in
the back end? If so, I can write up another ticket for that. I suspect
that it would result in a bit of a speed up. The easiest method would be
to depend on one of the llvm bindings, though I don't know if that's
acceptable in ghc.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
