- ghc-tickets - Haskell.org

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

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > E.g. turn foo (# a, b, c #) into foo a b c Yes. That's the easy part (see `RepType.repType`), the problem is returning tuples, it needs support from the code generator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:48> 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 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): After switching to {{{(# Int#, Addr# #)}}}, I have a sort-of working implementation. The builtin rules seem to work, rewriting string literals from user-code works and has access to the length, but ghci wouldn't even start up. Maybe I can take a look this evening into it, but if I understand unboxed tuples correctly, it should be possible to just flatten them if they appear in an argument position, right? E.g. turn {{{ foo (# a, b, c #) }}} into {{{ foo a b c }}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:47> 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 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I didn't follow the whole thread but yeah, if you want to compile string literals to unboxed tuples (`(# len, ptr #)`) it'd be a problem for GHCi as the bytecode interpreter/compiler can't handle unboxed tuple returns. (it has some special cases for handling primops that return state tokens in an unboxed tuple) We had briefly discussed doing bytecode generation after unarise in the mailing list (https://mail.haskell.org/pipermail/ghc- devs/2016-July/012502.html see Simon's response). I don't understand native calling conventions good enough to comment, but maybe we can add one more special case in the bytecode compiler to handle `(# len, ptr #)` returns, like the special cases for returning `(# RealWorld#, a #)` etc. (search for `isUnboxedTupleCon` in `ByteCodeGen.hs`) I'm willing to work on extending unboxed tuple support in the bytecode interpreter, but I don't have any concrete proposals right now -- I need to study native calling conventions for returning tuples first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:46> 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 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: osa1 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:45> 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 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The Unarise pass removes unboxed tuple binders and arguments, so it would be passed as two separate arguments. However, unarise is currently part of SimplStg, so GHCi doesn't get to take advantage of it, I don't know how hard that is to change. Maybe @osa1 or @simonpj would know. Backwards compatibility is a separate issue, we can always introduce new APIs instead of breaking old ones, I doubt there are serious problems here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:44> 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 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): Wouldn't that generate something like {{{unpackCString# (# 3#, "abc"# #)}}} for {{{"abc"}}}? And if I just typed "abc" in ghci, wouldn't it fail as ghci can not handle unboxed tuples? Beside from that, it should work, but then I could also just try to change {{{unpackCString#}}} to have type {{{Addr# -> Int# -> [Char]}}}, avoiding the tuple. This would of course break backwards compatibility, as would an unboxed tuple, and I wanted to see if I could avoid that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:43> 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 02 Aug '16

02 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Doesn't it work to have string literals be of type `(# Int#, Addr# #)` (see comment:38)? The unboxed tuple will be passed as two arguments, but in Core you can name the unboxed tuple and pass it around as a single entity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12450: Option to suppress GHCi output "Failed, modules loaded"
by GHC 02 Aug '16

02 Aug '16

#12450: Option to suppress GHCi output "Failed, modules loaded" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- For projects with lots of modules, the "modules loaded" message can be considerably long. For example: {{{ Failed, modules loaded: Distribution.Client.Check, Distribution.Client.Run, Distribution.Client.Tar, Distribution.Client.Types, Distribution.Client.Win32SelfUpgrade, Distribution.Client.Utils, Paths_cabal_install, Distribution.Client.BuildReports.Types, Distribution.Client.Dependency.Types, Distribution.Client.Init.Types, Distribution.Solver.Types.ConstraintSource, Distribution.Solver.Types.Settings, Distribution.Client.GlobalFlags, Distribution.Client.HttpUtils, Distribution.Client.Security.HTTP, Distribution.Solver.Types.PackageIndex, Distribution.Solver.Types.ComponentDeps, Distribution.Solver.Types.OptionalStanza, Distribution.Solver.Types.PackageFixedDeps, Distribution.Solver.Types.SourcePackage, Distribution.Solver.Types.LabeledPackageConstraint, Distribution.Solver.Types.PackageConstraint, Distribution.Client.World, Distribution.Client.FetchUtils, Distribution.Client.GZipUtils, Distribution.Client.Init.Licenses, Distribution.Client.Init.Heuristics, Distribution.Client.Compat.Process, Distribution.Client.JobControl, Distribution.Client.Compat.ExecutablePath, Distribution.Client.Compat.Semaphore, Distribution.Client.ParseUtils, Distribution.Client.Compat.FilePerms, Distribution.Client.Haddock, Distribution.Client.InstallPlan, Distribution.Client.SolverInstallPlan, Distribution.Client.BuildReports.Anonymous, Distribution.Client.BuildReports.Storage, Distribution.Solver.Types.PkgConfigDb, Distribution.Solver.Types.SolverPackage, Distribution.Solver.Types.SolverId, Distribution.Solver.Types.ResolverPackage, Distribution.Solver.Modular, Distribution.Client.PackageUtils, Distribution.Solver.Types.DependencyResolver, Distribution.Solver.Types.InstalledPreference, Distribution.Solver.Types.PackagePath, Distribution.Solver.Types.PackagePreferences, Distribution.Solver.Types.Progress, Distribution.Solver.Types.Variable, Distribution.Solver.Modular.Assignment, Distribution.Solver.Modular.ConfiguredConversion, Distribution.Solver.Modular.IndexConversion, Distribution.Solver.Modular.Log, Distribution.Solver.Modular.Package, Distribution.Solver.Modular.Solver, Distribution.Solver.Modular.Builder, Distribution.Solver.Modular.Cycles, Distribution.Solver.Modular.Dependency, Distribution.Solver.Modular.Explore, Distribution.Solver.Modular.Index, Distribution.Solver.Modular.Message, Distribution.Solver.Modular.Preference, Distribution.Solver.Modular.Validate, Distribution.Solver.Modular.Linking, Distribution.Solver.Modular.PSQ, Distribution.Solver.Modular.Tree, Distribution.Solver.Modular.Flag, Distribution.Solver.Modular.Version, Distribution.Solver.Modular.ConflictSet, Distribution.Solver.Modular.Var, Distribution.Solver.Modular.Configured, Distribution.Solver.Modular.LabeledGraph, Distribution.Client.ProjectPlanning.Types, Distribution.Client.DistDirLayout, Distribution.Client.PackageHash, Distribution.Client.RebuildMonad, Distribution.Client.Glob, Distribution.Client.FileMonitor, Distribution.Client.Utils.Json. *Distribution.Client.Check> }}} It would be nice if there were a way to suppress this message. If there already is a way, it would be nice if GHCi mentioned this method when the module list gets long. See also https://stackoverflow.com/questions/11509201/how-can-i-suppress- failed-modules-loaded-in-ghci -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8473: Generate table of cost-centre numbers with source locations
by GHC 01 Aug '16

01 Aug '16

#8473: Generate table of cost-centre numbers with source locations ------------------------------------+------------------------------------- Reporter: lars_e_krueger | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | 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: 7105 | ------------------------------------+------------------------------------- .prof files contain a cost centre number, which I assume is cc_key from CostCentre.lhs. It would be immensely helpful if the compiler creates a simpe table. This way, one could look up the number in .prof, check the table and the exact source location. It would also help with #7105, I think. Suggestion for the format: {{{ no. file begin end 1 main.hs 127:7 128:14 }}} Meaning: Cost centre 1 is in file main.hs, begins at line 127, character 7 and ends at line 128, character 14. If somebody points me in the right direction, and the whole thing is not too complicated, I can try my hand at implementing it myself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12391: LANGUAGE CPP messes up parsing when backslash like \\ is at end of line (eol)
by GHC 31 Jul '16

31 Jul '16

#12391: LANGUAGE CPP messes up parsing when backslash like \\ is at end of line (eol) -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: CPP | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE CPP #-} import Data.List as List main = putStrLn $ "not nice" List.\\ "hot mice" }}} fails with recent ghc (I tried >= 7.8). {{{ Not in scope: ‘List.\’ }}} This problem occurred in a larger context, see https://travis-ci.org/agda/agda/jobs/144514733 It can be traced back to the use of cpp as preprocessor: {{{ $ cpp BackslashAtEOL.hs # 1 "BackslashAtEOL.hs" # 1 "<built-in>" 1 # 1 "<built-in>" 3 # 328 "<built-in>" 3 # 1 "<command line>" 1 # 1 "<built-in>" 2 # 1 "BackslashAtEOL.hs" 2 {-# LANGUAGE CPP #-} import Data.List as List main = putStrLn $ "not nice" List.\ "hot mice" }}} In contrast, cpphs would work correctly here: {{{ $ cpphs BackslashAtEOL.hs #line 1 "BackslashAtEOL.hs" {-# LANGUAGE CPP #-} import Data.List as List main = putStrLn $ "not nice" List.\\ "hot mice" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2