December 2016 - ghc-tickets

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 02 Dec '16

02 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): The summary (for Windows): 1. I always used patched binutils and never used separate linker scripts, thus can't comment on potential problems with the latter. 2. On 64-bit GHC I don't use `-split-objs` at all and use `-split- sections` exclusively for almost a year and I never had any problems with this. The only '''important''' thing one should remember is that we sometimes need to supply `-opta-Wa,-mbig-obj` to GHC to make it build correct object files (I know 2 package which require this: `template- haskell` when building GHC itself and `haskell-src-exts`). One possible option is to always use this flag if `-split-sections` is used. 3. `-split-sections` doesn't introduce any noticeable overhead when compiling and thus is '''dramatically''' faster than `-split-objs` when building packages, it is slightly slower when linking final executables though. 4. 64-bit GHC itself can be built in release configuration with `-split- objs` replaced by `-split-sections` absolutely with no problems (only `-opta-Wa,-mbig-obj` should be added to `ghc-options` in `template- haskell` cabal file). 32-bit GHC building process is less smooth and requires a special handling of `template-haskell` package (one needs to recompile `Language.Haskell.TH.Syntax` module in profiling configuration with `-split-objs`). Overall, building release GHC itself with `-split- sections` is '''much''' faster than with `-split-objs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 02 Dec '16

02 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Scripts attached do section merging on Windows. Caveat: As far as I remember, when I worked on this (almost year ago) `cabal` (or was it GHC?) didn't respect linker flags when building library's prelinked object file (for GHCi). I may be wrong or `cabal` may be changed since that time, but if you will try to use attached linker scripts with existing binutils, please make sure `ld` receives the option, feeding the linker script to it. If this problem is still there, please ask `cabal` (or GHC?) maintainers to fix it. Also it may be a problem that we need use different linker scripts for different scenarios: "x" for building executables/dlls and "xr" for building prelinked object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 02 Dec '16

02 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by awson): * Attachment "scripts.tar.gz" added. Linker scripts for section merging on Windows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12495: GHC's configure script detects MADV_FREE when it shouldn't
by GHC 02 Dec '16

02 Dec '16

#12495: GHC's configure script detects MADV_FREE when it shouldn't -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: MADV_FREE | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In osDecommitMemory there is a [http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c1… #define] for MADV_FREE. The presence of MADV_FREE is detected by the [http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c1… configure] script, however merely testing for the presence of this symbol does not prove that MADV_FREE is supported by the kernel (which was [https://kernelnewbies.org/Linux_4.5#head- 42578a3e087d5bcc2940954a38ce794fe2cd642c introduced in 4.5]). On newer versions of GCC (e.g. 6.1.1 on Alpine Edge), [https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=981569c74cbb6bafa2dd… MADV_FREE is included in the compiler's header files], thus leading to a false positive. The impact of this bug is that when GHC is compiled with a more recent version of GCC, "unable to decommit memory: Invalid argument" errors will abound. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 02 Dec '16

02 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Well, I've updated [https://sourceware.org/bugzilla/show_bug.cgi?id=19254 relevant binutils ticket] with patches solving the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12909: Python 3.2 doesn't support Unicode literal syntax
by GHC 01 Dec '16

01 Dec '16

#12909: Python 3.2 doesn't support Unicode literal syntax -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- Simonpj noticed that the Python 3.2 interpreter on his Ubuntu 12.04 installation doesn't support Unicode literal syntax (e.g. `u'hello'`). Indeed it seems this syntax was dropped in Python 3 and later re- introduced in Python 3.3 (https://www.python.org/dev/peps/pep-0414/) At this point we have a decision to make: Either drop the uses of Unicode literals in the driver (and, consequently, support for Python 2) or keep things as they are and demand Python >3.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12735: Evaluate the feasibility of using lld for linking
by GHC 01 Dec '16

01 Dec '16

#12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | 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: -------------------------------------+------------------------------------- Our runtime system's linker a represents a significant amount of rather tricky code. We have in the past attempted to jettison it by moving to dynamic linking, although this lead to its own set of issues (see [DynamicLinkingDebate]). Another approach would be to let someone else implement our linker for us. While in the past linkers were rather monolithic things, today there exists LLVM's `lld` [http://lld.llvm.org/|linker] Like the other LLVM projects, its design is quite modular and can be used as a library. It seems likely that it could be made to do our bidding with enough effort. The question, of course, is whether this effort is greater than the effort we currently spend on the runtime linker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 01 Dec '16

01 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): @awson Please do whatever is easiest for you. If you don't want to bother with integrating your patches into upstream `binutils`, maybe someone else is, so please at least open source them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 01 Dec '16

01 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * cc: awson (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 01 Dec '16

01 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): awson: could GHC have the new linker script embedded into it, so that GHC can use it automatically? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0