July 2016 - ghc-tickets

[GHC] #12206: No exposed API to get full text of ErrMsg
by GHC 09 Oct '16

09 Oct '16

#12206: No exposed API to get full text of ErrMsg -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In GHC version 7.10.3 it was possible to get the full text of an error message by using the functions `ErrUtils.errMsgShortDoc` and `ErrUtils.errMsgExtraInfo`. But in GHC version 8.0.1 the code has changed. The full text of the error message is stored in the `ErrMsg` field `ErrUtils.errMsgDoc`, but this field is hidden, and there doesn't seem to be any API to access its contents. The only workaround I can find is to use `ErrUtils.pprLocErrMsg`, and then strip out the first line containing the location info, and then manually unindent the 4-space "hang". This is quite ugly. I suggest exporting `ErrUtils.errMsgDoc`, and then for that to be useful the fields of `ErrUtils.ErrDoc` will also be needed. Additionally, `ErrUtils.formatErrDoc` could be a nice bonus to have (and if exported would lessen the need for the `ErrDoc` fields). The GHC API changes on every GHC release, so since backwards compatibility is not an issue, it would seem that there is no need to have a carefully exposed API, and there is no danger in liberally exporting stuff that clients could potentially find useful. Thank you -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11970: Simplify Parent
by GHC 09 Oct '16

09 Oct '16

#11970: Simplify Parent -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This commit {{{ commit 96621b1b4979f449e873513e9de8d806257c9493 Associate pattern synonyms with types in module exports }}} added `PatternSynonym` to `RdrName.Parent`. That's a pretty heavy hammer. It forces us to add `IsPatSyn` to `AvailInfo`, including binary serialisation etc. And I think it's needed in precisely one place, namely `RnNames.findPatSyns`. Right? The caller of `findPatSyns` and the associated `lookupChildren` is jolly obscure and I don't fully understand it. I **think** the issue is this: * I want to allow an export item `T( K )`, where `K` is a pattern synonym, even though it's not really (yet) associated with `T`. I think the goal of this code was to reject the `K` if it's a data constructor. But we also have a **further** check in `tcExports` to check that `K` has the right type. Surely it'd be better to nuke this `PatternSynonym` and `IsPatSyn` stuff? Just use`isDataOcc` in the export lookup part. Then the `tcExport` check will object if you write an export item like `Either( Just )`. Fewer moving parts! Matthew, does this make sense? Might you look at it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9547: Empty constraint tuples are mis-kinded
by GHC 07 Oct '16

07 Oct '16

#9547: Empty constraint tuples are mis-kinded -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider {{{ -- If :: forall k. 'Bool -> k -> k -> k type family If cond tru fls where If True tru fls = tru If False tru fls = fls foo :: If True () (Eq a) => a -> a foo = error "urk" }}} This should work fine. But we get {{{ Foo.hs:8:21: The third argument of `If' should have kind `*', but `Eq a' has kind `Constraint' In the type signature for `foo': foo :: If True () (Eq a) => a -> a }}} Reason: GHC is treating the `()` unit tuple as of kind `*`. Reason is that in the `HsTupleTy` case of `tc_hs_type` in `TcHsType`, we see {{{ -- In the [] case, it's not clear what the kind is, so guess * }}} And that guess is plain wrong in this case. Unfortunately I don't see an easy fix, but it's plain wrong as-is. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12395: Misleading GHCi errors when package is installed
by GHC 07 Oct '16

07 Oct '16

#12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When a package is installed in a cabal sandbox/global package directory and code is loaded with GHCi when a file has been deleted, GHCi gives very misleading errors. First, if we don't install the package, we get the correct error/expected result: {{{ > mv B.hs B.hs.old > ghci Main.hs Main.hs:3:1: error: Failed to load interface for ‘B’ Use -v to see a list of the files searched for. Failed, modules loaded: A. }}} But if we first install the package, we get a very strange error: {{{ > mv B.hs.old B.hs > cabal install > mv B.hs B.hs.old > ghci Main.hs Main.hs:6:14: error: Ambiguous occurrence ‘str’ It could refer to either ‘A.str’, imported from ‘A’ at Main.hs:2:1-8 (and originally defined at A.hs:7:1-3) or ‘B.str’, imported from ‘B’ at Main.hs:3:1-8 (and originally defined in ‘A’) Failed, modules loaded: A. }}} I'm using GHC 8.0.1, cabal-install-1.24.0.0, and Cabal Library-1.24.0.0. This is Very Annoying because I use this process to minimize examples. For example, when I want to simplify code by removing a module, I just delete it and then rely on GHCi to tell me what I need to update. Anyone not aware of this bug would be totally confused by the error, and even though I do know about the bug, the error is completely unhelpful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12130: ghc: panic! (the 'impossible' happened): find_tycon Block []
by GHC 06 Oct '16

06 Oct '16

#12130: ghc: panic! (the 'impossible' happened): find_tycon Block [] -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just tried building yesod-simple template project with nightly-2016-05-29 snapshot and some extra-deps package, and it seems to fail due to {{{$(widgetFile ...)}}} yesod template haskell clause. It was same on linux and windows, and when I remove handler ghc fails at Application module (and seems also due to template haskell). {{{ ~/yt> stack build ... yt-0.0.0: configure Configuring yt-0.0.0... yt-0.0.0: build Preprocessing library yt-0.0.0... [1 of 9] Compiling Settings ( Settings.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings.o ) [2 of 9] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings/StaticFiles.o ) [3 of 9] Compiling Import.NoFoundation ( Import/NoFoundation.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import/NoFoundation.o ) [4 of 9] Compiling Foundation ( Foundation.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Foundation.o ) [5 of 9] Compiling Import ( Import.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import.o ) [6 of 9] Compiling Handler.Common ( Handler/Common.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Common.o ) [7 of 9] Compiling Handler.Home ( Handler/Home.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Home.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Block [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 179 action(s). -- While building package yt-0.0.0 using: /home/jeiea/.stack/setup-exe-cache/x86_64-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:yt exe:yt --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10163: Export typeRepKinds in Data.Typeable
by GHC 04 Oct '16

04 Oct '16

#10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc3 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{TypeRep}}} has a {{{[KindRep]}}} field internally, {{{Data.Typeable}}} should export {{{typeRepKinds}}} (alongside {{{typeRepTyCon}}} and {{{typeRepArgs}}}, which are currently exported) to allow users to access it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11054: GHC on Windows could not use more than 64 logical processors
by GHC 04 Oct '16

04 Oct '16

#11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found that GHC runtime does not take advantage of processor groups under Windows. So it cannot use more than 64 logical processors (2x 18 core physical + HT). This is Reddit thread about: https://www.reddit.com/r/haskell/comments/3q1r0o/ghc_on_numa_72_core_2_proc… MSDN link https://msdn.microsoft.com/en- us/library/windows/desktop/dd405503(v=vs.85).aspx -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #11987: Allow record wildcards with pattern synonyms
by GHC 02 Oct '16

02 Oct '16

#11987: Allow record wildcards with pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With pattern synonym `pattern Point {x, y} = (x, y)` we can write {{{ >>> let { x = 1; y = 2 } in Point { x = x, y = y } (1, 2) }}} {{{ >>> let { x = 1; y = 2 } in Point { x, y } (1, 2) }}} but record wildcards ain't workin {{{#!hs >>> let { x = 1; y = 2 } in Point {..} <interactive>:342:25-36: error: Pattern synonym ‘Point’ used as a data constructor }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11792: Optimised unsafe FFI call can get wrong argument
by GHC 02 Oct '16

02 Oct '16

#11792: Optimised unsafe FFI call can get wrong argument -------------------------------------+------------------------------------- Reporter: Szunti | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attached a simple test case. It should print 7457, but the C function is called with 0 as the third argument. If I compile with -O0 or omit the unsafe keyword in the FFI import it works as it should. In gdb disassembly looks to me as edx (the place for third argument on 64-bit) is set to 7457, then the opaquify is inlined, but it doesn't preserve edx and then third_arg is called with the zeroed edx. ---------------- Specs ------------- 64-bit Archlinux with arch-haskell repo gcc -v: {{{ Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto- wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-5-20160209/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with- bugurl=https://bugs.archlinux.org/ --enable- languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable- threads=posix --enable-libmpx --with-system-zlib --with-isl --enable- __cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install- libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 5.3.0 (GCC) }}} ghc compile output: {{{ Glasgow Haskell Compiler, Version 7.10.3, stage 2 booted by GHC version 7.10.3 Using binary package database: /usr/lib/ghc-7.10.3/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181 wired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181 wired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Main.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2016-04-05 14:24:20.801997492 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude, import Data.Word] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Main.hs Created temporary directory: /tmp/ghc1541_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( Main.hs, Main.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 317, types: 387, coercions: 3} *** Core Linted result of Desugar (after optimization): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 261, types: 290, coercions: 14} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 216, types: 262, coercions: 18} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 216, types: 262, coercions: 18} *** Core Linted result of Simplifier: *** Specialise: Result size of Specialise = {terms: 216, types: 262, coercions: 18} *** Core Linted result of Specialise: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 274, types: 305, coercions: 18} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 407, types: 388, coercions: 70} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 463, types: 375, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 430, types: 362, coercions: 25} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 426, types: 363, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 426, types: 363, coercions: 25} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 310, types: 291, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 248, types: 217, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Simplifier: *** Float inwards: Result size of Float inwards = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Float inwards: *** Called arity analysis: Result size of Called arity analysis = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Called arity analysis: *** Simplifier: Result size of Simplifier = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Simplifier: *** Demand analysis: Result size of Demand analysis = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 369, types: 283, coercions: 25} *** Core Linted result of Worker Wrapper binds: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 354, types: 266, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 354, types: 266, coercions: 25} *** Core Linted result of Simplifier: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}): *** Common sub-expression: Result size of Common sub-expression = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Common sub-expression: *** Float inwards: Result size of Float inwards = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Float inwards: *** Simplifier: Result size of Simplifier = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Simplifier: *** Tidy Core: Result size of Tidy Core = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Tidy Core: writeBinIface: 18 Names writeBinIface: 81 dict entries *** CorePrep: Result size of CorePrep = {terms: 654, types: 379, coercions: 25} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeGen: *** Assembler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -x assembler -c /tmp/ghc1541_0/ghc_2.s -o Main.o Upsweep completely successful. *** Deleting temp files: Deleting: /tmp/ghc1541_0/ghc_3.c /tmp/ghc1541_0/ghc_2.s /tmp/ghc1541_0/ghc_1.s Warning: deleting non-existent /tmp/ghc1541_0/ghc_3.c Warning: deleting non-existent /tmp/ghc1541_0/ghc_1.s link: linkables are ... LinkableM (2016-04-05 15:42:11.288210053 UTC) Main [DotO Main.o] Linking Main ... *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_4.c -o /tmp/ghc1541_0/ghc_5.o -I/usr/lib/ghc-7.10.3/include *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_7.s -o /tmp/ghc1541_0/ghc_8.o -I/usr/lib/ghc-7.10.3/include *** Linker: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash- size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -o Main Main.o Test.o -L/usr/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM -L/usr/lib/ghc-7.10.3/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/usr/lib/ghc-7.10.3/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/usr/lib/ghc-7.10.3/rts /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_8.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM -lHSinteger- gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -lgmp -lm -lrt -ldl link: done *** Deleting temp files: Deleting: /tmp/ghc1541_0/ghc_10.rsp /tmp/ghc1541_0/ghc_9.rsp /tmp/ghc1541_0/ghc_8.o /tmp/ghc1541_0/ghc_7.s /tmp/ghc1541_0/ghc_6.rsp /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_4.c *** Deleting temp dirs: Deleting: /tmp/ghc1541_0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11792> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12186: GHC compiled executable incompatible with 3rd party software
by GHC 02 Oct '16

02 Oct '16

#12186: GHC compiled executable incompatible with 3rd party software -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been trying to work on a library that allows Haskell to call into .Net code, but there's a major show stopper in that the .Net runtime starting with version 4.0, doesn't like the executable files that GHC produces. I've managed to reduce a test case to not actually depend on using Haskell, but just using GHC to compile a C file, and that C file being nothing but a dumb wrapper around a small dll. The resulting executable exhibits the incorrect behaviour: {{{ > stack exec ghc -- main.c -no-hs-main > main 1 2 3 4 5 6 ICLRRuntimeHost Start failed w/hr 0x80004005 }}} Then I can also use GCC on the intermediate object file that was created, and produce an executable that exhibits the correct behaviour: {{{ > stack exec gcc -- main.o -o main2.exe > main2 1 2 3 4 5 6 7 8 }}} I've put a copy of the test case here: https://gitlab.com/tim-m89/DotNetHostingTest -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15