July 2014 - ghc-tickets

[GHC] #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_
by GHC 18 Oct '14

18 Oct '14

#9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D99 -------------------------------------+------------------------------------- During normal course of action in `real_main` a process is terminated with a call to {{{#!hs shutdownHaskellAndExit(exit_status, 0 /* !fastExit */); }}} which is defined as {{{#!hs void shutdownHaskellAndExit(int n, int fastExit) { if (!fastExit) { // even if hs_init_count > 1, we still want to shut down the RTS // and exit immediately (see #5402) hs_init_count = 1; // we're about to exit(), no need to wait for foreign calls to return. hs_exit_(rtsFalse); } stg_exit(n); } }}} However, when we call `forkProcess`, the child process does ''not'' terminate in this manner, but instead calls {{{#!hs hs_exit(); // clean up and exit stg_exit(EXIT_SUCCESS); }}} instead, where `hs_exit` is defined as {{{#!hs void hs_exit(void) { hs_exit_(rtsTrue); // be safe; this might be a DLL } }}} Crucially, this means that, unlike the parent, the child process ''does'' wait for foreign calls to be terminated (it calls `hs_exit_` with `rtsTrue` instead of `rtsFalse`). I don't see a reason why the child process should terminate in a different manner to the parent, so I propose to change this so that `forkProcess` calls `shutdownHaskellAndExit`, just like `real_main` does. Incidentally, this is the immediate cause for https://ghc.haskell.org/trac/ghc/ticket/9284 , although the patch proposed in this ticket is not sufficient to solve the problems with termination of the I/O manager in the general case (but I will let Andreas explain that in more detail :). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9340: Implement new `clz` inline primop
by GHC 18 Oct '14

18 Oct '14

#9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 (CodeGen) | Differential Revisions: Keywords: primop clz | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- From a draft for #9281, I had to use a C FFI and using a gcc/clang `__builtin` to get access to the [http://en.wikipedia.org/wiki/Find_first_set CLZ instruction]: {{{#!hs -- | Compute base-2 log of 'Word#' -- -- This is internally implemented as count-leading-zeros machine instruction. foreign import ccall unsafe "integer_gmp_word_log2" wordLog2# :: Word# -> Int# }}} {{{#!c HsWord integer_gmp_word_log2(HsWord x) { #if (SIZEOF_HSWORD) == (SIZEOF_INT) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clz(x) : -1; #elif (SIZEOF_HSWORD) == (SIZEOF_LONG) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzl(x) : -1; #elif (SIZEOF_HSWORD) == (SIZEOF_LONG_LONG) return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzll(x) : -1; #else # error unsupported SIZEOF_HSWORD #endif } }}} Since a `clz`-like operation should be available on most cpus GHC should expose that as a primop ({{{clz# :: Word# -> Int#}}}). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8683: add "cpp program" and "cpp program options" to settings file
by GHC 14 Oct '14

14 Oct '14

#8683: add "cpp program" and "cpp program options" to settings file ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- so theres a pretty clear consensus that we need to move away from using our c compiler for CPP, so should we add that info to the settings file? I propose adding the following fields to the settings file: "use c compiler cpp", which can have either "YES" or "NO". If "YES", the settings file indicated C compiler is used unless the c compiler selection is overrided by ghc at runtime via -pgmc or -pgmp(p?) if "NO", then the "cpp program" and "cpp program options" fields would be used, unless overridden by -pgmp there'd be some associated patched in the compiler/main/DriverPipeline.hs too i think, but relatively minimal. this would make it much easier to distributed a GHC with its own CPP tool that works -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 69

[GHC] #9356: scanl does not participate in stream fusion
by GHC 07 Oct '14

07 Oct '14

#9356: scanl does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- nomeata came up with a fusing version of a strict `scanl'` in a comment on #9345. It's not entirely clear to me whether that's entirely safe, but a non-strict version of it for `scanl` would be, as both a good producer and good consumer, presumably made efficient using the same sorts of magic used in HEAD for `foldl`. The strict `scanl'` is obviously safe to write as a good consumer; only the production side remains to be proved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc-citeproc
by GHC 07 Oct '14

07 Oct '14

#8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc- citeproc ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It's mostly a http://www.haskell.org/pipermail/ghc- devs/2014-March/004363.html rechecked on ghc-7.8.1: I attempted to leave original packages as-is. Steps to reproduce: {{{ $ cd /tmp/ $ wget -c http://code.haskell.org/~slyfox/selfcontained-eater- ghc-7.8-rc2.tar.gz $ tar -xzf selfcontained-eater-ghc-7.8-rc2.tar.gz $ cd selfcontained-eater-ghc-7.8-rc2 $ ./mk.sh ... [279 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) stack overflow: use +RTS -K<size> to increase it }}} I did prepare this testcase for ghc-7.6.3 where it failed only on last 452 module. '''./mk.sh''' is a dumb script calling '''ghc -O2''' + cabal-generated bits. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|>
by GHC 07 Oct '14

07 Oct '14

#8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------+------------------------------------------------- Reporter: | Owner: joelteon | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- To reproduce, install a pre-`0.11.2.1` version of attoparsec. This bug was worked around in 0.11.2.1 by removing the `INLINE` on `plus` in attoparsec. With this test program: {{{#!haskell {-# LANGUAGE OverloadedStrings #-} import Control.Applicative import Data.Attoparsec.Text import Data.Text (Text) parser :: Parser Text parser = string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" main :: IO () main = parseTest parser "a" }}} and using GHC 7.8.1.rc2: Compiling using `-O2`, GHC tops out at ~1GB of RAM and takes 25s. Using `-O0`, GHC takes 0.47s and uses <150MB of RAM. Compare this with GHC 7.6.3: Compiling using `-O2`, GHC uses <150MB and takes 3.7s. Memory usage is similar with `-O0` although compile time goes down to 0.36s. An extreme version of this bug can be found in the `thyme` package here: https://github.com/liyang/thyme/blob/master/src/Data/Thyme/Format.hs#L589-L…. Compiling that module with an unfixed attoparsec makes GHC use all available memory and stall out, forcing kill -9. Replacing the function body with `undefined` makes the package compile as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8852> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8790: rts: unrust 'libbfd' debug symbols parser
by GHC 05 Oct '14

05 Oct '14

#8790: rts: unrust 'libbfd' debug symbols parser ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- For quite a long while you might have seen such ./configure output: {{{ checking bfd.h usability... yes checking bfd.h presence... yes checking for bfd.h... yes ... checking for bfd_uncompress_section_contents in -lbfd... no }}} which means very interesting debug bit in rts (+RTS -Di) is disabled. It's because most of functions in bfd.h are actually macros, thus test fails: config.log: {{{ configure:9545: checking for bfd_uncompress_section_contents in -lbfd configure:9570: x86_64-pc-linux-gnu-gcc -o conftest -march=corei7-avx -mtune=corei7-avx -O2 -pipe -fdiagnostics-show-option -frecord-gcc- switches -ggdb3 -march=corei7-avx -march=corei7-avx -m tune=corei7-avx -mtune=corei7-avx -ggdb3 -fno-stack-protector -Wa,-- noexecstack -Wa,--noexecstack -fno-stack-protector -Wl,-O1 -Wl,--as- needed -Wl,--hash-style=gnu -Wl,--hash-size=31 -Wl,--r educe-memory-overheads conftest.c -lbfd -liberty >&5 /tmp/portage/dev-lang/ghc-7.6.3-r1/temp/ccCEvDZ7.o: In function `main': /tmp/portage/dev-lang/ghc-7.6.3-r1/work/ghc-7.6.3/conftest.c:99: undefined reference to `bfd_uncompress_section_contents' }}} We don't use that function anyways, thus i've picked '''bfd_init'''. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8374: `tcIfaceGlobal (local): not found` while compiling
by GHC 29 Sep '14

29 Sep '14

#8374: `tcIfaceGlobal (local): not found` while compiling ----------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- On commit fa3ffb43144eadc406031110b01ba3dc4f9bd94e on compiling on ARM, ``` "rm" -f libraries/integer-gmp/dist-install/build/libHSinteger- gmp-0.5.1.0.a.contents "/usr/bin/ld" -r -o libraries/integer-gmp/dist-install/build/HSinteger- gmp-0.5.1.0.o libraries/integer-gmp/dist-install/build/GHC/Integer.o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Prim.o libraries /integer-gmp/dist-install/build/GHC/Integer/Logarithms.o libraries /integer-gmp/dist-install/build/GHC/Integer/Logarithms/Internals.o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.o libraries /integer-gmp/dist-install/build/cbits/gmp-wrappers.o libraries/integer- gmp/dist-install/build/cbits/cbits.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20130924 for arm-unknown-linux): tcIfaceGlobal (local): not found: base:GHC.Base.$fMonadIO{v r1} [(02K, Identifier ‛base:GHC.Base.fail{v 02K}’), (02L, Identifier ‛base:GHC.Base.>>={v 02L}’), (02M, Identifier ‛base:GHC.Base.>>{v 02M}’), (02N, Identifier ‛base:GHC.Base.fmap{v 02N}’), (02O, Identifier ‛base:GHC.Base.return{v 02O}’), (28, Class ‛base:GHC.Base.Monad{tc 28}’), (2a, Class ‛base:GHC.Base.Functor{tc 2a}’), (36r, Type constructor ‛base:GHC.Base.Opaque{tc 36r}’), (36u, Type constructor ‛base:GHC.Base.String{tc 36u}’), (rB, Data constructor ‛base:GHC.Base.O{d rB}’), (rD, Identifier ‛base:GHC.Base.<${v rD}’), (rhP, Identifier ‛base:GHC.Base.O{v rhP}’), (ri5, Data constructor ‛base:GHC.Base.D:Functor{d ri5}’), (rit, Identifier ‛base:GHC.Base.$dm<${v rit}’), (riv, Identifier ‛base:GHC.Base.D:Functor{v riv}’), (riX, Data constructor ‛base:GHC.Base.D:Monad{d riX}’), (rjw, Identifier ‛base:GHC.Base.$dm>>{v rjw}’), (rjx, Identifier ‛base:GHC.Base.$dmfail{v rjx}’), (rjz, Identifier ‛base:GHC.Base.D:Monad{v rjz}’)] ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 36

[GHC] #8115: GHC 64-bit build failures with LLVM
by GHC 28 Sep '14

28 Sep '14

#8115: GHC 64-bit build failures with LLVM ------------------------------------+--------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- When using LLVM 2.9, 3.1 or 3.4svn on Windows with the 64-bit GHC from the downloads page (http://www.haskell.org/ghc/download_ghc_7_6_3) to compile this simple program; {{{ main = print "Hello!" }}} I get these errors; {{{ Kyle@kyle-laptop /c/Users/Kyle/Desktop$ ghc -fllvm -fforce-recomp test.hs [1 of 1] Compiling Main ( test.hs, test.o ) C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s: Assembler messages: C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:2: Error: junk at end of line, first unrecognized character is `,' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:3: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:3: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:7: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:7: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:10: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:10: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:17: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:17: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:19: Error: junk at end of line, first unrecognized character is `,' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:20: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:20: Error: junk at end of line, first unrecognized character is `c' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:24: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:24: Error: junk at end of line, first unrecognized character is `c' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:26: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:26: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:31: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:31: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:34: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:34: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:41: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:41: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:43: Error: junk at end of line, first unrecognized character is `,' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:44: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:44: Error: junk at end of line, first unrecognized character is `M' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:50: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:50: Error: junk at end of line, first unrecognized character is `M' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:53: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:53: Error: junk at end of line, first unrecognized character is `M' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:61: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:61: Error: junk at end of line, first unrecognized character is `M' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:63: Error: junk at end of line, first unrecognized character is `,' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:64: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:64: Error: junk at end of line, first unrecognized character is `Z' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:69: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:69: Error: junk at end of line, first unrecognized character is `Z' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:72: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:72: Error: junk at end of line, first unrecognized character is `Z' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:80: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:80: Error: junk at end of line, first unrecognized character is `Z' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:82: Error: junk at end of line, first unrecognized character is `"' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:85: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:85: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:91: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:91: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:95: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:95: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:137: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:137: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:140: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:140: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:146: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:146: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:150: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:150: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:192: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:192: Error: junk at end of line, first unrecognized character is `s' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:195: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:195: Error: junk at end of line, first unrecognized character is `M' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:202: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:202: Error: junk at end of line, first unrecognized character is `M' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:207: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:207: Error: junk at end of line, first unrecognized character is `M' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:250: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:250: Error: junk at end of line, first unrecognized character is `M' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:253: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:253: Error: junk at end of line, first unrecognized character is `Z' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:260: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:260: Error: junk at end of line, first unrecognized character is `Z' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:266: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:266: Error: junk at end of line, first unrecognized character is `Z' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:308: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:308: Error: junk at end of line, first unrecognized character is `Z' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:310: Warning: .type pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:310: Error: junk at end of line, first unrecognized character is `_' C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:315: Warning: .size pseudo-op used outside of .def/.endef ignored. C:\Users\Kyle\AppData\Local\Temp\ghc6708_0\ghc6708_0.s:315: Error: junk at end of line, first unrecognized character is `_' }}} Invocation is `ghc -fllvm test.hs`. ghc --info: {{{ Kyle@kyle-laptop /c/Users/Kyle/Desktop$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","$topdir/../mingw/bin/gcc.exe") ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl ,--reduce-memory-overheads") ,("ar command","$topdir/../mingw/bin/ar.exe") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","$topdir/touchy.exe") ,("dllwrap command","$topdir/../mingw/bin/dllwrap.exe") ,("windres command","$topdir/../mingw/bin/windres.exe") ,("perl command","$topdir/../perl/perl.exe") ,("target os","OSMinGW32") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.6.3") ,("Booter version","7.6.1") ,("Stage","2") ,("Build platform","x86_64-unknown-mingw32") ,("Host platform","x86_64-unknown-mingw32") ,("Target platform","x86_64-unknown-mingw32") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","C:\\Program Files\\Haskell Platform\\2013.2.0.0\\lib") ,("Global Package DB","C:\\Program Files\\Haskell Platform\\2013.2.0.0\\lib\\package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory- overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ] }}} No output binary is produced. Same llvm used with 32-bit ghc works smoothly to compile the same program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9191: Semi-exported names
by GHC 27 Sep '14

27 Sep '14

#9191: Semi-exported names --------------------------------------+------------------------------------ Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: --------------------------------------+------------------------------------ It's generally inadvisable to add exports to a well-known module because they may clash with existing code using the module and importing it in its entirety. As a work-around, I propose allowing a module to export a name that will only be visible in a module that lists it explicitly. Something approximately like module Foo (a, b, explicit c) simply import Foo would not bring c into scope, but import Foo (c) would bring in c (and nothing else). To get everything, we could use something like import Foo revealing (c) and to be a bit picky, import Foo hiding (a) revealing (c). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5