#7730: :info and polykinds
--------------------------------------------+------------------------------
Reporter: monoidal | Owner: archblob
Type: bug | Status: new
Priority: normal | Milestone: 7.10.1
Component: Compiler (Type checker) | Version: 7.6.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets: #8776
--------------------------------------------+------------------------------
Comment (by archblob):
I have implemented what we have discussed in comment 28 as
{{{
data IfaceType = .... | IfaceTyConApp IfaceTyCon [IfaceTcArg] | ...
data IfaceTcArg
= ITC_Type IfaceType
| ITC_Kind IfaceKind
}}}
because as I understood it all we want are tags, so I have found this
easier to work with than ad hoc lists, please correct me if I am wrong.
I also saw that you have changed the way we print foralls, so I will
implement that approach in this case too.
We will also have to add extra information to one of
{{{IfaceClosedSynFamilyTyCon}}} or {{{IfaceSyn}}} constructors in order to
print closed type families the way we do now, but this should not be a
problem.
I have run the tests and the implementation works except when printing
qualified names, for example:
{{{ data Int = GHC.Types.I# GHC.Prim.Int# }}} prints like {{{data Int = I#
GHC.Prim.Int#}}} this is T8469, and we have more of the same for ghci051
with
{{{
-data Ghci1.T = A | ... -- Defined at <interactive>:3:10
-data Ghci4.T = B | ... -- Defined at <interactive>:6:12
+data T = A | ... -- Defined at <interactive>:3:10
+data T = B | ... -- Defined at <interactive>:6:12
}}}
I will look into this after I sorted out all the other stuff, but in the
mean time any suggestions would be nice.
I wrote this as a progress update, and if everything goes well i'll have
the patch ready in a couple of days.
Andrei
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:35>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#6018: Injective type families
-------------------------------+-------------------------------------------
Reporter: lunaris | Owner: simonpj
Type: feature | Status: new
request | Milestone: 7.10.1
Priority: normal | Version: 7.4.1
Component: Compiler | Keywords: TypeFamilies, Injective
Resolution: | Architecture: Unknown/Multiple
Operating System: | Difficulty: Unknown
Unknown/Multiple | Blocked By:
Type of failure: | Related Tickets: #4259
None/Unknown |
Test Case: |
Blocking: |
-------------------------------+-------------------------------------------
Comment (by ocharles):
It's a little hard to say whether or not injective type families would
actually help with what I'm doing - it could well be that I don't just
understand this type level magic enough! However, in a few cases where
I've got stuck I've moved things to a GADT to witness the relation between
types instead, which I believe does get me injectivity and from that
points things seemed to "just work" - albeit requiring a bit more effort.
I'll keep my eyes out, and try and provide examples here if I find
anything concrete.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#6018: Injective type families
-------------------------------+-------------------------------------------
Reporter: lunaris | Owner: simonpj
Type: feature | Status: new
request | Milestone: 7.10.1
Priority: normal | Version: 7.4.1
Component: Compiler | Keywords: TypeFamilies, Injective
Resolution: | Architecture: Unknown/Multiple
Operating System: | Difficulty: Unknown
Unknown/Multiple | Blocked By:
Type of failure: | Related Tickets: #4259
None/Unknown |
Test Case: |
Blocking: |
-------------------------------+-------------------------------------------
Comment (by simonpj):
ollie, acowley: if you have a real-life use case for injective type
families, do give the details here. Currently we don't have many
compelling examples.
Thanks
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:23>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9072: RankNTypes composition now requires ImpredicativeTypes
-------------------------------------+-------------------------------------
Reporter: gelisam | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type | Version: 7.8.2
checker) | Operating System: Unknown/Multiple
Keywords: | Type of failure: GHC rejects
Architecture: Unknown/Multiple | valid program
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
-------------------------------------+-------------------------------------
{{{
{-# LANGUAGE RankNTypes #-}
instantiateId :: (forall a. a -> a) -> Int -> Int
instantiateId f = f
passes :: [Int] -> [Int]
passes = map (instantiateId id)
-- Couldn't match type ‘a0 -> a0’ with ‘forall a. a -> a’
fails :: [Int] -> [Int]
fails = (map . instantiateId) id
}}}
works with ghc 7.6,
fails with ghc 7.8,
works with ghc 7.8 + `ImpredicativeTypes`.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9072>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9076: GHC.Exts docs don't contain all primops
------------------------------------+-------------------------------------
Reporter: tibbe | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Documentation | Version: 7.8.2
Keywords: | Operating System: Unknown/Multiple
Architecture: Unknown/Multiple | Type of failure: None/Unknown
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
------------------------------------+-------------------------------------
I would expect the docs for `GHC.Exts`:
https://www.haskell.org/ghc/docs/7.8.2/html/libraries/base-4.7.0.0/GHC-
Exts.html
to contain all the primops from `GHC.Prim`:
http://hackage.haskell.org/package/ghc-prim-0.3.1.0/docs/GHC-Prim.html
as `GHC.Exts` is the recommended module to import the primops from.
However, `GHC.Exts` are missing loads of the primops.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9076>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#703: all binaries built by ghc have executable stacks
----------------------------+----------------------------------------------
Reporter: duncan | Owner: ezyang
Type: merge | Status: new
Priority: normal | Milestone: 6.6.1
Component: | Version: 7.6.3
Compiler (NCG) | Keywords:
Resolution: | Architecture: Unknown/Multiple
Operating System: Linux | Difficulty: Moderate (less than a day)
Type of failure: | Blocked By:
None/Unknown | Related Tickets:
Test Case: N/A |
Blocking: |
----------------------------+----------------------------------------------
Comment (by ezyang):
Jens reported to me that 7.8 appears to fix the problem on 64-bit as well.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/703#comment:35>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8935: Obscure linker bug leads to crash in GHCi
------------------------------------+-------------------------------------
Reporter: simonmar | Owner: simonmar
Type: bug | Status: new
Priority: high | Milestone: 7.8.2
Component: Runtime System | Version: 7.6.3
Keywords: | Operating System: Unknown/Multiple
Architecture: Unknown/Multiple | Type of failure: GHCi crash
Difficulty: Rocket Science | Test Case:
Blocked By: | Blocking:
Related Tickets: |
------------------------------------+-------------------------------------
I have a build of GHC (with `DYNAMIC_GHC_PROGRAMS=NO`) that exhibits the
following crash:
{{{
$ ghc -e 'System.Environment.getEnvironment'
<segfault>
}}}
I tracked it down, eventually, to a bad reference to the symbol `environ`
from `__hscore_environ` in `libraries/base/includes/HsBase.h`. Somehow,
`environ` had got linked to the wrong address.
Lots more investigation lead me to discover this: `internal_dlsym()` in
`Linker.c` tries to look up a symbol in all the different shared libraries
we have loaded so far, one by one. (see
be497c202b790999c3fd0ddc4a4176b8cf6acf7e). Unfortunately, this seems to
break things in my case. Here's a simple test program that works on
Ubuntu 12.04:
{{{
#include <dlfcn.h>
#include <stdio.h>
char *so = "/usr/lib/x86_64-linux-gnu/libgmp.so";
char *so2 = "/usr/lib/x86_64-linux-gnu/libpthread.so";
extern char**environ;
int main(int argc, char *argv[])
{
void *deflt, *hdl;
deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL);
printf("environ = %p\n", &environ);
printf("dlsym(deflt, \"environ\") = %p\n", dlsym(deflt,"environ"));
hdl = dlopen(so, RTLD_LAZY);
printf("dlsym(\"libgmp\", \"environ\") = %p\n", dlsym(hdl,"environ"));
hdl = dlopen(so2, RTLD_LAZY);
printf("dlsym(\"libpthread\", \"environ\") = %p\n",
dlsym(hdl,"environ"));
}
}}}
And the output:
{{{
environ = 0x601040
dlsym(deflt, "environ") = 0x601040
dlsym("libgmp", "environ") = 0x2aaaab290568
dlsym("libpthread", "environ") = 0x601040
}}}
Note that the value we get from looking up `environ` in `libgmp` is
different to the others. The correct value is `0x601040`. gdb thinks
that `0x2aaaab290568` is also `environ`:
{{{
(gdb) p4 0x2aaaab290568
0x2aaaab290580 <buflen.9817>: 0x0
0x2aaaab290578: 0x0
0x2aaaab290570 <miss_F_GETOWN_EX>: 0x0
0x2aaaab290568 <environ>: 0x0
}}}
but note that it contains zero. The real one is:
{{{
(gdb) p4 0x601040
0x601058: 0x0
0x601050 <dtor_idx.6533>: 0x0
0x601048 <completed.6531>: 0x0
0x601040 <environ@@GLIBC_2.2.5>: 0x7fffffffe268
}}}
In GHC we're loading `libgmp` when we load the `integer-gmp` package, and
this causes future references to `environ` to go wrong.
I've locally fixed this by changing `internal_dlsym` to `dlsym`, but since
there was a reason to make this change in the first place I haven't pushed
it to master. Suggestions welcome.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8935>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9065: Segfault in a memory-heavy program
----------------------------------+----------------------------------
Reporter: rotsor | Owner: simonmar
Type: bug | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 7.6.3
Keywords: | Operating System: Linux
Architecture: x86_64 (amd64) | Type of failure: Runtime crash
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
----------------------------------+----------------------------------
I've got a program compiled with GHC 7.6.3 crashing with "Segmentation
fault". It does not crash with GHC 7.8.2 so the bug might have been fixed
already.
This is the backtrace I'm getting from gdb:
{{{
#0 0x00000000004a0450 in alloc_mega_group ()
#1 0x00000000004a0930 in allocGroup.part.1 ()
#2 0x00000000004c3c00 in alloc_todo_block ()
#3 0x00000000004c3d73 in todo_block_full ()
#4 0x0000000000403df9 in evacuate ()
#5 0x00000000004051e4 in scavenge_block ()
#6 0x00000000004bf785 in scavenge_loop ()
#7 0x00000000004a16c5 in GarbageCollect ()
#8 0x0000000000499d6f in scheduleDoGC.isra.21 ()
#9 0x000000000049a81d in scheduleWaitThread ()
#10 0x000000000049e1be in real_main ()
#11 0x000000000049e2bc in hs_main ()
#12 0x0000000000418a8b in main ()
}}}
The problem only triggers when I run the program on large input values: it
uses 7Gb of memory and dies after 7 minutes of runtime.
The version compiled with 7.8.2 exhibits similar memory usage pattern, but
successfully completes within 15 minutes.
Compiler command line I use:
{{{
ghc -O2 -rtsopts eu468
}}}
RTS command line:
{{{
./eu468 +RTS -K1000000000
}}}
The program in question is eu468.hs at
https://github.com/Rotsor/euler.git.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9065>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
