February 2013 - ghc-tickets

[GHC] #7612: Automatically start the haskell runtime in DllMain on windows -shared
by GHC 12 Apr '13

12 Apr '13

#7612: Automatically start the haskell runtime in DllMain on windows -shared ----------------------------+----------------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: ----------------------------+----------------------------------------------- On Windows DllMain is called when a dll is loaded into a process via LoadLibrary (or even when it's loaded as a regular dependency). Currently a stub, such as this, is required to be linked with all haskell dll compilations on windows that plan to have their functions called from non-haskell origins; {{{ #include <windows.h> #include <Rts.h> EXTFUN(__stginit_Adder); static char* args[] = { "ghcDll", NULL }; /* N.B. argv arrays must end with NULL */ BOOL STDCALL DllMain ( HANDLE hModule , DWORD reason , void* reserved ) { if (reason == DLL_PROCESS_ATTACH) { /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */ startupHaskell(1, args, __stginit_Adder); return TRUE; } return TRUE; } }}} see outdated documentation, but still mostly applicable: http://www.haskell.org/ghc/docs/5.04/html/users_guide/win32-dlls- foreign.html I personally think this is a tad silly and could be easily improved. Ideally, DllMain should automatically detect if the runtime is running, and if not, automatically start it up so that the dll's ordinals can all be called freely. This could be a stub automatically added by ghc when the windows -shared is used. An extension to this would be to add a pragma/flag to allow people to execute code inside DllMain (dllMain, a pragma, maybe?) after the runtime has started. One extremely easy way to do this would be to assume main as being :: Int -> IO Int where the first bound argument is the attach reason when windows -shared is used. This would GREATLY improve how easy it is to call haskell dll's from other languages, even .net origins, etc. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x))
by GHC 12 Apr '13

12 Apr '13

#7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)) -----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I’m moving the discussion from http://www.haskell.org/pipermail/glasgow-haskell- users/2013-January/023522.html (with reply at http://www.haskell.org/pipermail/glasgow-haskell- users/2013-January/023531.html) here, as a reminder for myself to work on it someday: Short summary: a rule "map (\x -> x) = id" will not match "map id" because the latter has (in Core) an application of a type variable, despite the matcher looking through the definition of id. Doing beta-reduction (of type applications) in the matcher could fix this. I’ll attach a test case. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7610: Cross compilation support for LLVM backend
by GHC 12 Apr '13

12 Apr '13

#7610: Cross compilation support for LLVM backend ------------------------------------+--------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: 7608 ------------------------------------+--------------------------------------- Top level bug to track supporting cross compilation in LLVM backend. Mostly this shouldn't be too bad but I haven't tried it and know of at least a few significant issues. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #7608: Triple not passed to LLVM when cross-compiling
by GHC 12 Apr '13

12 Apr '13

#7608: Triple not passed to LLVM when cross-compiling ------------------------------------+--------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.6.1 | Keywords: cross-compiling llvm Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- First found in http://www.haskell.org/pipermail/cvs- ghc/2012-December/079115.html When cross-compiling to a different architecture, LLVM is not informed what architecture we are building for, and so generates code for the host architecture instead. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #7604: System.Directory.canonicalizePath "" behaviour differs between platforms
by GHC 12 Apr '13

12 Apr '13

#7604: System.Directory.canonicalizePath "" behaviour differs between platforms ------------------------------------+--------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: T4113 Blockedby: | Blocking: Related: | ------------------------------------+--------------------------------------- On Linux, `System.Directory.canonicalizePath ""` gives an exception. On OS X, it returns the current directory. In a `System.Directory` function, we should consistently do one or the other. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7596: Opportunity to improve CSE
by GHC 12 Apr '13

12 Apr '13

#7596: Opportunity to improve CSE ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ In `nofib/spectral/mandel2`, the function `check_perim` calls `point_colour` on various arguments. After inlining `point_colour` there is the opportunity to CSE among the sub-expressions the inlinings create. In GHC 7.6, the join point didn't have a "one-shot" flag, so the full laziness pass floated these sub-expressions out, and they got CSEd. As part of Ilya's new demand analyser changes, we get the "one-shot" flag right, so don't MFE those sub-expressions, so they aren't CSEd. As a result, allocation on `mandel2` increases slightly (4.2%). The solution is, I think, to do something a bit like like `CorePrep` before CSE. At the moment if we have {{{ case f (I# y) of { (a,b) -> case g (I# y) of { (p,q) -> ... }} }}} we stuipdly don't CSE that `(I# y)` even though it is manifestly sharable. Somehow we should. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7593: Unable to print exceptions of unicode identifiers
by GHC 12 Apr '13

12 Apr '13

#7593: Unable to print exceptions of unicode identifiers ----------------------------------------------+----------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- I suspect this is windows specific but I'm not certain (I couldn't reproduce it with an older ghc on osx). Here is an example of the problem: {{{ $ ghcii.sh GHCi, version 7.6.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude λ> ⇒ <interactive>:2:1: parse error on input `*** Exception: <stderr>: hPutChar: invalid argument (invalid character) }}} On other platforms the message looks more like: parse error on input `=>' (not the automatic translation from ⇒ to =>, I think that's a separate bug related to the unicode symbols extension) On windows my ghc is version 7.6.1. On OSX (where I could NOT reproduce the exception), my ghc is 7.4.1. I don't know if the GHC version matters. I strongly suspect this is a windows unicode issue. GHC gives similar behavior to ghci, for example on this input: {{{ ⇒ = 1 }}} ghc tries to give an error message but throws an exception printing ⇒. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7576: Building happy -- setup: internal error: evacuate: strange closure type 2122076
by GHC 12 Apr '13

12 Apr '13

#7576: Building happy -- setup: internal error: evacuate: strange closure type 2122076 --------------------------+------------------------------------------------- Reporter: datenwolf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I'm running a Gentoo system and use the haskell overlay. The Gentoo- Haskell folks strongly advise using their provided packages instead of cabal-install. When I try to emerge (=install) [dev- haskell/happy-1.18.10](http://www.haskell.org/happy/) the build process aborts with the message {{{ >>> Compiling source in /var/tmp/portage/dev- haskell/happy-1.18.10/work/happy-1.18.10 ... ./setup build setup: internal error: evacuate: strange closure type 2122076 (GHC version 7.6.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /var/tmp/portage/dev-haskell/happy-1.18.10/temp/environment: line 878: 23486 Aborted ./setup "$@" }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7570: GHC's ./configure script should check for ncurses
by GHC 12 Apr '13

12 Apr '13

#7570: GHC's ./configure script should check for ncurses -----------------------------+---------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When building GHC, the configure script will not check for ncurses, even though it is required for the build of terminfo. Without it installed, the build fails mid-way in with: {{{ checking for stdint.h... yes checking for unistd.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking curses.h usability... no checking curses.h presence... no checking for curses.h... no configure: error: in `/home/linaro/code/ghc/libraries/terminfo': configure: error: curses headers could not be found, so this package cannot be built See `config.log' for more details }}} I think that configure should check for ncurses immediately so you don't accidentally lack a dependency. It's just annoying. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7570> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7629: segmentation fault in compiled program, involves gtk, selinux
by GHC 09 Apr '13

09 Apr '13

#7629: segmentation fault in compiled program, involves gtk, selinux --------------------------+------------------------------------------------- Reporter: wgmitchener | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.4.2 | Keywords: segmentation fault, multithreading, selinux, gtk Os: Linux | Architecture: x86 Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I wrote a multithreaded GUI program for a research project using gtk2hs, and it works fine on fedora 17, which uses ghc 7.0.4. It crashes almost as soon as it starts when compiled and run on fedora 18 (ghc 7.4.1). There's a message on the console that it was killed because of a segmentation fault and that's about all it tells me. I tracked down the code that causes crash, and it seems to happen because I add an action to the gtk loop: timeoutAddFull action ... and the crash happens when the action runs the first time. I thought it was a bug in ghc 7.4.1, because I found a bug report that talks about a crash involving STM and multithreading, and supposedly was fixed in 7.4.2. So I set up a virtual machine and installed fedora 18 then upgraded it to rawhide to try my program under 7.4.2. But, the same crash happens on my rawhide machine. However, it happened that I had to disable selinux on my rawhide machine using the boot command line because something started going wrong, still not sure what (hey, it's rawhide). Now my program does not crash. I just tested this on my fedora 18 laptop (still ghc 7.4.1) using both the version compiled on fedora 18 and the files from where I compiled it on rawhide: when I disable selinux, my program runs fine, but when it's enabled (even if set to permissive rather than enforcing) my program seg faults. There's nothing useful in /var/log/messages, no indication of what selinux is unhappy about. I did find this: http://www.haskell.org/pipermail /haskell-cafe/2007-August/031120.html but at least in that problem, there was a definite error message about memory mapping, and I'm not getting one. So as best I can tell, ghc 7.4.1&2 must both be doing something strange, maybe marking some piece of memory as data instead of code, maybe when performing calls to gtk, maybe in building thunks for use by timeoutAddFull, and eventually triggering a security problem. My original program is huge. The problem must be some unexpected interaction between ghc's newer run time systems, gtk, and selinux. I'm attaching the smallest test case I could concoct and the build command. When you run the resulting program, it does nothing for about 2 seconds, then the action to print "tick" runs, and it crashes. I'm filing the bug here because it might be a problem in the ghc runtime. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29