- ghc-tickets - Haskell.org

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 21 Aug '17

21 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > That's a separate issue. It is indeed what OverloadedStrings is for. Perhaps we can have a new ticket for it. But we can't talk meaningfully about it until we settle the first issue: what are the primitive types and operations over them. There I think we have a preliminary consensus, with B# = ByteArray#. My intention is to add a way to let user choose which primitive types he/she wants. But if there's a must to fix a primitive type, `ByteArray#` may be better than `Addr#` since it can be cast into `Addr#` not vice- versa(at the cost of extra info-header and length words). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:94> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 21 Aug '17

21 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It's the ability to choose between Addr# or ByteArray#' or (# Int#, Addr# #), etc. that matters That's a separate issue. It is indeed what `OverloadedStrings` is for. Perhaps we can have a new ticket for it. But we can't talk meaningfully about it until we settle the first issue: what are the primitive types and operations over them. There I think we have a preliminary consensus, with `B#` = `ByteArray#`. Moreover, I think jscholl has a preliminary implementation (comment:74). jscholl: would you like to write up your design as a wiki page? Can you share it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:93> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 21 Aug '17

21 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > One issue with this is that we would gain a word of overhead for each string literal These are statically allocated literals. I have a hard time believing that a one-word increase in binary size for each string literal will make a noticeable difference to GHC's binary sizes. If we are agreed, let's do it! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:92> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14139: Kind signature
by GHC 20 Aug '17

20 Aug '17

#14139: Kind signature -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I don't understand the rules for kind signatures / CUSKs but this works {{{#!hs import Data.Singletons.Prelude data Some (f :: u ~> v) where Some :: Sing (x :: u) -> f @@ x -> Some f }}} but this doesn't? {{{#!hs import Data.Kind import Data.Singletons.Prelude data Some :: (u ~> v) -> Type where Some :: Sing (x :: u) -> f @@ x -> Some f -- • Expected kind ‘u ~> v’, but ‘f’ has kind ‘u ~> *’ -- • In the first argument of ‘Some’, namely ‘f’ -- In the type ‘Some f’ -- In the definition of data constructor ‘Some’ -- | -- 5 | Some :: Sing (x :: u) -> f @@ x -> Some f -- | ^ -- Failed, modules loaded: none. }}} I have to quantify over them for it to work `forall u v. (u ~> v) -> Type`, if this is expected I feel like the error message ought to be improved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14139> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 19 Aug '17

19 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I believe that one goal is > > > The ability to put a block of binary data in the program code, without heavy encoding. > > Is that a goal? Can we focus solely on that for a while? That is indeed a goal. Another in my mind equally-important goal is to be able to support constant-time length given the literals we write today. This is important for being able to efficiently implement things like `bytestring` `Builder` in terms of `memcpy`. > Or `B#` could be `ByteArray#`. That would have the major advantage of not adding a new type, and for sure we'd need to be able to turn it into a `ByteArray#`. So I like that, and it's what jscholl suggests in comment:74. One issue with this is that we would gain a word of overhead for each string literal (assuming we use `B#` to implement Haskell's `String`). I took some measurements a while back and found that short strings are quite common, so this may be a hard cost to accept. > I don't have clarity on how bytestring would want to convert a `ByteArray#` to a `ByteString`. That ought to be a constant time operation. I may be missing something but I don't believe this should pose any particular trouble. Afterall, a `ByteString` is essentially a `ForeignPtr` and some length/offset information. `byteArrayContents#` allows us to get the `Addr#` from a (pinned) `ByteArray#`, from which we can construct a `Ptr` and in turn a `ForeignPtr`. Since we are talking about static data `byteArrayContents#` should be safe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:91> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13636: Enable -Wcpp-undef
by GHC 19 Aug '17

19 Aug '17

#13636: Enable -Wcpp-undef -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- e5b3492f23c2296d0d8221e1787ee585331f726e tried (again) to enable `-Wcpp- undef` in `mk/warnings.mk`, {{{#!make SRC_HC_OPTS_STAGE1 += $(WERROR) #-Wcpp-undef SRC_HC_OPTS_STAGE2 += $(WERROR) #-Wcpp-undef }}} Unfortunately, this caused build failures in boot libraries on some platforms (e.g. `time` on Darwin). Resolve these and reenable `-Wcpp- undef`. An alternative would be to instead only add `-Wcpp-undef` to `GhcRtsHcOpts`, `GhcStage1HcOpts` and `GhcStage2HcOpts`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13636> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12155: Description of flags cut off
by GHC 19 Aug '17

19 Aug '17

#12155: Description of flags cut off -------------------------------------+------------------------------------- Reporter: mikail | Owner: Type: task | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Keywords: flags | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The description of the flags from pages 104 to 110 are cut off in the PDF version of the User Guide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13093: Runtime linker chokes on LLVM function on Windows
by GHC 19 Aug '17

19 Aug '17

#13093: Runtime linker chokes on LLVM function on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This error prevents the [http://hackage.haskell.org/package/llvm-general llvm-general] library from loading in GHCi on Windows. I don't know how to reproduce this error without using LLVM. First, you need to install LLVM. On Windows, you can install it with MSYS2: {{{ pacman -S mingw-w64-x86_64-llvm }}} Currently, this gives you LLVM-3.9, although I've reproduced it with LLVM-3.8 as well. Now define this Haskell file: {{{#!hs module Main (main) where import Foreign.C.Types newtype LLVMBool = LLVMBool CUInt deriving Show foreign import ccall unsafe "LLVMIsMultithreaded" isMultithreaded :: IO LLVMBool main :: IO () main = isMultithreaded >>= print }}} If you compile it, it works OK: {{{ $ ghc LLVM.hs -fforce-recomp $(llvm-config --libs) $(llvm-config --system- libs) -lstdc++-6 -lgcc_s_seh-1 [1 of 1] Compiling Main ( LLVM.hs, LLVM.o ) Linking LLVM.exe ... $ ./LLVM LLVMBool 1 }}} Or, if you're allergic to `llvm-config`: {{{ $ ghc LLVM.hs -fforce-recomp -lLLVMLTO -lLLVMObjCARCOpts -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMDebugInfoDWARF -lLLVMGlobalISel -lLLVMCoverage -lLLVMTableGen -lLLVMLineEditor -lLLVMOrcJIT -lLLVMMIRParser -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMObjectYAML -lLLVMLibDriver -lLLVMOption -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMDebugInfoCodeView -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMPasses -lLLVMipo -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMCodeGen -lLLVMTarget -lLLVMScalarOpts -lLLVMInstCombine -lLLVMInstrumentation -lLLVMTransformUtils -lLLVMMC -lLLVMBitWriter -lLLVMBitReader -lLLVMAnalysis -lLLVMProfileData -lLLVMCore -lLLVMSupport -lpsapi -lshell32 -lole32 -luuid -lstdc++-6 -lgcc_s_seh-1 [1 of 1] Compiling Main ( LLVM.hs, LLVM.o ) Linking LLVM.exe ... $ ./LLVM LLVMBool 1 }}} If you load it into GHCi, however, things go awry: {{{ $ ghci $(llvm-config --libs) $(llvm-config --system-libs) -lgcc_s_seh-1 GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from C:\Users\RyanGlScott\AppData\Roaming\ghc\ghci.conf Ok, modules loaded: Main (LLVM.o). > main ghc.exe: LLVM.o: unknown symbol `LLVMIsMultithreaded' }}} On GHC 8.0.1 and HEAD, it's a slightly different error: {{{ > main ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: LLVMIsMultithreaded This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13093> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13815: Support Windows big-obj format
by GHC 19 Aug '17

19 Aug '17

#13815: Support Windows big-obj format -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | 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): Phab:D3523 | Wiki Page: -------------------------------------+------------------------------------- By default, an object file can hold up to 65,536 (2^16) addressable sections. This is the case no matter which target platform is specified. /bigobj increases that address capacity to 4,294,967,296 (2^32). Most modules will never generate an .obj file that contains more than 65,536 sections. However, machine generated code, or code that makes heavy use of template libraries may require .obj files that can hold more sections. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #3474: Add a strict variant of iterate to Data.List
by GHC 19 Aug '17

19 Aug '17

#3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3870 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"8e5b6ec6566da57d15b0810a07902d9eac85cb79/ghc" 8e5b6ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e5b6ec6566da57d15b0810a07902d9eac85cb79" Add strict variant of iterate This closes the nearly-eight-year-old #3474. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3474#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0