March 2015 - ghc-tickets

[GHC] #9315: Weird change in allocation numbers of T9203
by GHC 26 Aug '15

26 Aug '15

#9315: Weird change in allocation numbers of T9203 ------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While trying to improve our handle on allocation numbers, I’m stuck with the test case T9203. On some machines, it allocates roughly 95747304 bytes (this includes travis and my laptop), on others 42946176 bytes (e.g. on the machine where I monitor benchmark performance). All machines are 64 bit Linux machines. The output of `-ddump-simpl`, `-ddump-stg` and `-ddump-cmm` is identical (up to variable names). Even `-ddump-asm` looks the same, besides some jump target reordering. The binary runs too small to get a heap profile. I’m a bit stuck here: What can be the cause for these differences? (BTW, if have an up-to-date GHC tree, can you report the number you get? Run `make -C testsuite VERBOSE=4 TEST=9203` for that.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9315> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported"
by GHC 26 Aug '15

26 Aug '15

#9932: GHC fails to build when cross compiling for mingw with the message "Threads not supported" -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Keywords: Cross compiling | Operating System: Linux Architecture: x86 | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: 9542 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm trying to build a mingw32 cross compiler. I configured with `./configure --target=x86_64-x64-mingw32`, then I built with `make -j 1`. The build then fails with the message ` # error "Threads not supported"` followed by some other errors. (The last part of the make log is attached) To bypass #9542, I deleted the following lines from utils/hsc2hs/Main.hs: {{{ #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) #include "../../includes/ghcconfig.h" #endif }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9932> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9257: CC_CLANG_BACKEND not reconfigured during bindist install
by GHC 26 Aug '15

26 Aug '15

#9257: CC_CLANG_BACKEND not reconfigured during bindist install -------------------------------------+------------------------------------- Reporter: MtnViewMark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: clang | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Installing GHC Difficulty: Moderate (less | failed than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- 1) build GHC is built on a machine with clang -- project.mk ends up with the macro CC_CLANG_BACKEND=1 2) make binary-dist on that machine 3) bring that bindist to a machine that doesn't use clang 4) unpack the bindist, ./configure, make install This error ensues: cc1: error: unrecognized command line option "-Wno-invalid-pp-token" cc1: error: unrecognized command line option "-Wno-unicode" The problem rests in that there is on gcc invocation during that make install: /usr/bin/gcc -E ... rts/package.conf.in -o rts/dist/package.conf.install.raw This call is picking up arguments from RAWCPP_FLAGS, set in mk/config.mk, based on CC_CLANG_BACKEND, set in mk/project.mk... which was computed at build time. carter has hypothesized that adding the macro FP_CC_LLVM_BACKEND to distrib/configure.ac.in might fix this. In theory that will cause the config file that is bunded into the bindist to recompute the CC_CLANG_BACKEND flag at dist config time. However, this may not work because the only file that emits CC_CLANG_BACKEND is project.mk and that doesn't seem to get re-written during dist time config. -- so something else will be needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8
by GHC 24 Aug '15

24 Aug '15

#8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8 -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Changing type signature of comparison primops from `Bool` to `Int#` in GHC 7.8 (see #6135) caused a problem: type signatures of functions might be different for the bootstrapping compiler (if it is older than 7.8) than they are for the stage1 compiler. In order to solve this problem I introduced a compatibility module [[GhcFile(compiler/utils/ExtsCompat46)]] that provides different definition of primops for older versions of GHC (`__GLASGOW_HASKELL__ <= 706`) and different for newer versions (`__GLASGOW_HASKELL__ > 706`). However, once we set minimal version of GHC required for bootstrapping to be 7.8, we can (and should!) remove that compatibility module and go back to using GHC.Exts. This ticket is a reminder that we should do this after we release GHC 7.10 or 7.12. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8484: Compile-time panic
by GHC 20 Aug '15

20 Aug '15

#8484: Compile-time panic ----------------------------------+--------------------------------------- Reporter: Taymon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I attempted to build a program (using make) and got the following output: {{{ ghc -odir binaries -hidir binaries --make Main.hs -optl-w ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): While parsing "/home/taymonbeal/.ghc/x86_64-linux-7.6.3/package.conf.d/package.cache": too few bytes. Failed reading at byte position 8 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make: *** [build] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9381: Implement rdynamic
by GHC 18 Aug '15

18 Aug '15

#9381: Implement rdynamic -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: feature request | facundo.dominguez Priority: normal | Status: new Component: Compiler | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Difficulty: Unknown | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: 7015 | None/Unknown | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently ghc ignores the `-rdynamic` flag. With a small effort it can be used as a synonym of `-optl -rdynamic` in linux and `-optl -export-all-symbols` in windows/mingw32. In other platforms, similar translations must be possible to get the symbols of an executable exported. This feature would improve usability of an upcoming implementation of #7015. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9903: GHCi produces a cryptic message when using HPC
by GHC 13 Aug '15

13 Aug '15

#9903: GHCi produces a cryptic message when using HPC -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Keywords: hpc | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: #9878, #9762 ? | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following test produces an impolite response from GHCi {{{ $ cat t.hs g :: Int g = 1 + 1 $ ghc-stage2 --interactive t.hs -fhpc GHCi, version 7.9.20141217: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( t.hs, interpreted ) Ok, modules loaded: Main. *Main> g ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141217 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc25774_0/ghc25774_5.so: undefined symbol: _hpc_tickboxes_Main_hpc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It has been noted elsewhere (#9878) that these kinds of messages are better avoided. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9218: Upgrade the version of MinGW shipped with GHC
by GHC 13 Aug '15

13 Aug '15

#9218: Upgrade the version of MinGW shipped with GHC ------------------------------------+--------------------------------- Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3390 | ------------------------------------+--------------------------------- The Windows binary distribution of GHC incorporates a version of MinGW which has not been updated for several releases and is now out-of-date. It should be upgraded. The previous time this was done appears to correlate with ticket #3390. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python
by GHC 12 Aug '15

12 Aug '15

#9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python -------------------------------------------+---------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------+---------------------------- The released Windows 64 tarball available at https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown- mingw32.tar.xz includes the following under `mingw/bin`: * gfortran * gcj * python27.dll * The whole Python 2.7 standard library (`mingw/bin/lib`) These files have probably been included by mistake. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9143: feature request: way to set actual program argv
by GHC 12 Aug '15

12 Aug '15

#9143: feature request: way to set actual program argv ----------------------------------------------+---------------------------- Reporter: joeyhess | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Linux Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It's not currently possible to write a program with ghc that changes its argv, so as to change what the program name/parameters appear to be in ps. An example of a program that does this is sshd, which arranges for the process name to say which user it's serving. For example, "sshd: joey [priv]" I'd like to be able to write such programs using haskell too. Also, I have a haskell program that, due to the way it is executed, has a really horrible display in ps: /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker /android-git-annex- builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker /android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64 -linux-gnu/audit:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv /usr/local/propellor/propellor That's enough motivation for me to dig into this. :) In rts/RtsMain.c, progargv is set to point to argv. However, it's static, so this cannot be (ab)used from the FFI to change argv. So, a minimal change would be to make progargv not be static, and perhaps give it a more formal name or minimal FFI binding. A GHC-specific library could then use this to modify argv. The haskell interface I'm considering would be: displayArgv :: [String] -> IO () It would need to truncate strings to fit within the available argv space. (This would not affect the argv used by System.Environment, which is a copy of argv.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6