May 2016 - ghc-tickets

[GHC] #11950: Eventlog should include delimiters showing when the process writes to the .eventlog file
by GHC 19 May '16

19 May '16

#11950: Eventlog should include delimiters showing when the process writes to the .eventlog file -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | 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: -------------------------------------+------------------------------------- Quoting a comment I just added at https://ghc.haskell.org/trac/ghc/wiki/EventLog#Limitations : > Event logging can produce "observer effects". In particular, programs can pause while writing to the `.eventlog` file. These display in Threadscope as periods of 100% CPU use with no obvious cause. This effect is exacerbated by heavy use of debug tools which expand the eventlog file, such as `Trace.traceMarkerIO`. (This effect was at least seen on OS X. In an extreme case, a program doing nothing but writing 200,000 trace markers, which took 120 ms to run, showed a single 10ms pause in the middle to write them to the `.eventlog` file. These periods were shown to be due to writing the `.eventlog` file by using `dtruss -a`, which shows long periods of `write_nocancel` syscalls, writing to the `.eventlog` file opened earlier with `open_nocancel`.) This behavior caused a few hours of investigation for us. It would make it much more obvious what is happening if this behavior were logged in the eventlog. Specifically, I would like for the eventlog to include a "starting writing eventlog file" event at the start of each of these periods, and a "stopped" event at the end of each period. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11950> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11946: Provide a `make uninstall` target
by GHC 19 May '16

19 May '16

#11946: Provide a `make uninstall` target -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): | Wiki Page: -------------------------------------+------------------------------------- Currently there is no clean way to uninstall GHC built from source. The makefiles should provide an uninstall target that allows this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12051: -.-> is accepted as a data constructor
by GHC 19 May '16

19 May '16

#12051: -.-> is accepted as a data constructor -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- {{{ data A = (-.->) Int }}} Is accepted by GHC without any complaints but `-.->` is not a valid data constructor as it doesn't start with a `:`. Anyone have any ideas about what is going on here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11808: nofib's cryptarithm1 regresses due to deferred inlining of Int's Ord operations
by GHC 19 May '16

19 May '16

#11808: nofib's cryptarithm1 regresses due to deferred inlining of Int's Ord operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit d1179c4bff6d05cc9e86eee3e2d2cee707983c90 [[https://perf.haskell.org/ghc/#revision/d1179c4bff6d05cc9e86eee3e2d2cee70798…]] causes a ~5% regression in runtime in nofib's `cryptarithm1` benchmark. Need to work out why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11808> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11805: Ability to use record fields for automatic derivation of user-defined classes.
by GHC 19 May '16

19 May '16

#11805: Ability to use record fields for automatic derivation of user-defined classes. -------------------------------------+------------------------------------- Reporter: Tientuine | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- I propose that the compiler be empowered to automatically derive a user- defined class when a data type has fields that match (in both name and type) methods sufficient for a minimal complete definition of the class. (There is some overlap between this idea and the much larger and more contentious issue of extensible records generally.) I am relatively new to Haskell, but have quickly run into the problem of field namespacing. As a simple example, suppose we are creating a game with data types for Room and Item, and values of each of these types will have a short name and a long description (possibly among other fields not detailed here). Currently, we must name our fields differently, as in: {{{#!hs -- ugh! prefixing the field names is ugly and tedious data Room = Room { rname :: String, rdescribe :: String, item :: Maybe Item } data Item = Item { iname :: String, idescribe :: String, value :: Int } }}} Classes seem a natural solution to this problem, but then we must either have superfluous field names or drop the use of field names altogether: {{{#!hs -- extracting a common interface as a class makes sense type Desc d where name :: d -> String describe :: d -> String -- but now we either keep the ugly prefixed fields or drop fields entirely data Room = Room String String (Maybe Item) data Item = Item String String Int -- furthermore, it is tedious to implement these trivial observers instance Desc Room where name (Room n _ _) = n describe (Room _ d _) = d instance Desc Item where name (Item n _ _) = n describe (Item _ d _) = d }}} My proposal is to allow the compiler to rely on fields in order to automatically derive a user-defined class. This solves a couple of problems in a way that (I hope) is not excessively complex to implement. Such a feature would allow us to write code like the following: {{{#!hs -- class as a common interface still feels natural type Desc d where name :: d -> String describe :: d -> String -- now we get shared field names and let the compiler do some of the work data Room = Room { name :: String, describe :: String, item :: (Maybe Item) } deriving Desc data Item = Item { name :: String, describe :: String, value :: Int } deriving Desc }}} Obviously, there are a couple of restrictions here: * fields of the same name in different records must have the same type * fields of the same name in different records are still ambiguous (no different than the current situation) if we do //not// derive a class that declares those field names * this is //not// intended to be a general solution for either extensible records or deriving classes automatically, it is very limited in scope P.S. This is my first Ticket and attempt to get involved in the community, and I'm not yet sure of the correct tags to use. Please be gentle. :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11429: Make unrecognised `-W` flags a warning rather than an error
by GHC 19 May '16

19 May '16

#11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 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: Design/Warnings -------------------------------------+------------------------------------- Currently, it's a fatal error to pass GHC a warning flag it doesn't recognise: {{{ $ ghc-8.1.20160111 -Wfoobar -c foobar.hs ghc: unrecognised flag: -Wfoobar Usage: For basic information, try the `--help' option. }}} However, in order to gain more flexibility adding/removing warning flags without requiring users to carefully guard which flags a given GHC version supports, it was suggested to make GHC more tolerating in case of unrecognised warning flags (which may either have been removed, or not yet available in the current GHC version). Specifically, I propose the following: 1. Handle `-Wno-<token>` or `-W<token>` for an unknown `<token>` as a warning rather than an error 2. This warning gets its own token `unrecognised-warning-flag` (turned on by default), so that it can be controlled via the general warning facilities as well: - `-Wno-unrecognised-warning-flag` turns off such warnings - `-Wunrecognised-warning-flag` turns on such warnings explicitly - `-Werror=unrecognised-warning-flag` (once we have #11219) emulates the old behaviour - various other combinations with warning-sets, `-Werror` specifications -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11782: Teach ghc-pkg to read multiple registrations from command line
by GHC 19 May '16

19 May '16

#11782: Teach ghc-pkg to read multiple registrations from command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: ghc-pkg | 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: -------------------------------------+------------------------------------- ghc-pkg register and ghc-pkg update should take files/stdin streams which consist of multiple packages separated by `----`. ghc-pkg will operate atomically: either all of the registrations succeed or none are performed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10671: inplace/bin/ghc-stage1 doesn't respect --with-ld override
by GHC 19 May '16

19 May '16

#10671: inplace/bin/ghc-stage1 doesn't respect --with-ld override -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Building ghc 7.10.1 on RHEL 5.8. I need to override the old system linker which lacks features and performance. I get stage1 built but then it forgets the override. Configure: ./configure --prefix=/home/cavtools/opt/ghc-7.10.1 --with- ld=/home/cavtools/64/pkg/bin/gld --with-ar=/home/cavtools/64/pkg/bin/gar --with-ranlib=/home/cavtools/64/pkg/bin/granlib settings: [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", ""), ("Haskell CPP command","/usr/bin/gcc"), ("Haskell CPP flags","-E -undef -traditional "), ("ld command", "/home/cavtools/64/pkg/bin/gld"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/home/cavtools/64/pkg/bin/gar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/bin/perl"), ("target os", "OSLinux"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] inplace/lib/settings: [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", ""), ("Haskell CPP command","/usr/bin/gcc"), ("Haskell CPP flags","-E -undef -traditional "), ("ld command", "/home/cavtools/64/pkg/bin/gld"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/home/cavtools/64/pkg/bin/gar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/bin/perl"), ("target os", "OSLinux"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] Failure looks like: "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -H32m -O -this-package-key ghcpr_8TmvWUcS1U1IKHT0levwg3 -hide-all- packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist- install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries /ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/autogen/cabal_macros.h -package-key rts -this-package-key ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist- install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist- install/build/GHC/IntWord64.p_o -dyno libraries/ghc-prim/dist- install/build/GHC/IntWord64.dyn_o /usr/bin/ld: unrecognized option '--build-id=none' /usr/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status But why are you using /usr/bin/ld? I told you not to use /usr/bin/ld! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11780: GHC stage-2 build fails with "relocation R_X86_64_PC32 against `exitStaticPtrTable' can not be used when making a shared object"
by GHC 19 May '16

19 May '16

#11780: GHC stage-2 build fails with "relocation R_X86_64_PC32 against `exitStaticPtrTable' can not be used when making a shared object" -------------------------------------+------------------------------------- Reporter: zadarnowski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On very old versions of CentOS (5.x) running GCC 4.1.2, GHC fails to build with the following error: {{{ /usr/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation R_X86_64_PC32 against `exitStaticPtrTable' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value }}} This appears to be caused by #pragma GCC visibility push(hidden) in BeginPrivate.h. Removing the HAS_VISIBILITY_HIDDEN macro from mk/config.h results in a successful build. BeginPrivate.h contains a comment which seems to indicate similar problem occurs with GCC 4.2.1 on FreeBSD. I suggest that the #if directive in {Begin,End}Private.h be changed to cover both systems, by enabling visibility pragmas only on GCC versions higher than 4.2 as follows: {{{ #if defined(HAS_VISIBLITY_HIDDEN) && (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2) }}} Old versions of CentOS are still prolific in enterprise environments so it would be great for advocacy reasons to get that fix into the next release of GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 18 May '16

18 May '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"13e40f998e15a626a4212bde0987ddbc98b3f56f/ghc" 13e40f99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13e40f998e15a626a4212bde0987ddbc98b3f56f" Kill varEnvElts in tcPragExpr I had to refactor some things to take VarSet instead of [Var], but I think it's more precise this way. Test Plan: ./validate Reviewers: simonmar, simonpj, austin, bgamari, goldfire Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2227 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0