September 2017 - ghc-tickets

[GHC] #12769: ghc: internal error: stg_ap_pp_ret
by GHC 22 Jun '18

22 Jun '18

#12769: ghc: internal error: stg_ap_pp_ret ----------------------------------------+---------------------------------- Reporter: kinnla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- appeared when building a project on macOS Sierra: https://github.com/Potregon/while/blob See attached log file (told me to report the bug) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11958: Improved testing of cross-compiler
by GHC 22 Jun '18

22 Jun '18

#11958: Improved testing of cross-compiler -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: task | Status: new Priority: low | Milestone: 8.2.1 Component: Test Suite | Version: 7.10.3 Keywords: cross-compile | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is already possible to build cross compiler eg from x86_64/linux to armhf/linux or arm64/linux, but there is currently no way to run the test suite. However, at least for the host and targets above, it should be possible to run the test executables under the Qemu user space emulation. I know this works, because in my own personal jenkins build instance, I test exactly this by doing (for x86_64/linux to amr64/linux cross): {{{ echo -e 'main :: IO ()\nmain = putStrLn "Hello World"\n' > hello-world.hs inplace/bin/ghc-stage1 hello-world.hs -o hello-world test $(file hello-world | grep -c 'ARM aarch64, version 1') -eq 1 ./hello-world }}} The linux machine I run the above test on is x86_64/linux but has Qemu and `binfmt` stuff set up so that it can run some foreign binaries. For instance, if GHC worked as a Linux to Windows cross-compiler the resulting windows binaries should work under Wine. To get this working, I suspect that just about all the required work is in the build system. Not sure if it might not be better to wait until the Shake based build system is in better shape. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13724: Clamping of llvm llc to -O1 and -O2
by GHC 22 Jun '18

22 Jun '18

#13724: Clamping of llvm llc to -O1 and -O2 -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (LLVM) | 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: -------------------------------------+------------------------------------- We currently clamp the optimization level of llvm llc (3.9 and 4.0) within `[1,2]`. The reason is that with `-O0`, the naive register allocator can topple over with {{{ Error while trying to spill R1 from class GPR: Cannot scavenge register without an emergency spill slot! }}} and with `-O3` the `llvm::SelectionDAGISel::LowerArguments` may break, when compiling `rts/HeapStackCheck.cmm` with the stage1 ghc. {{{ 0 llc 0x0000000102ae63e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 llc 0x0000000102ae69a6 SignalHandler(int) + 358 2 libsystem_platform.dylib 0x00007fffc23f4b3a _sigtramp + 26 3 libsystem_c.dylib 0x00007fffc226498b __vfprintf + 17876 4 llc 0x00000001029d5123 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) + 5699 5 llc 0x0000000102a21a35 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3381 6 llc 0x0000000102a202b1 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1457 7 llc 0x0000000101bdc474 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20 8 llc 0x00000001025573a6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 134 9 llc 0x000000010274fb12 llvm::FPPassManager::runOnFunction(llvm::Function&) + 498 10 llc 0x000000010274fd23 llvm::FPPassManager::runOnModule(llvm::Module&) + 67 11 llc 0x00000001027501b8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 920 12 llc 0x000000010195f075 compileModule(char**, llvm::LLVMContext&) + 12133 13 llc 0x000000010195bf0b main + 491 14 libdyld.dylib 0x00007fffc21e5235 start + 1 Stack dump: 0. Program arguments: llc -O3 -mtriple=arm-unknown-linux-gnueabihf -enable-tbaa /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module '/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"' }}} `opt` and `llc` should respect `-opt_lo` and `-opt_lc`, such that `-opt_lc=-O3` can be used to validate the behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13240: Make it easier to find builds we may want to cancel
by GHC 22 Jun '18

22 Jun '18

#13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Trac & Git | 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: -------------------------------------+------------------------------------- I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples: 1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest. 2. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific. 3. Only documentation files have changed. Building these on one platform should be sufficient. 4. A differential was closed by a commit. Only the most recent build will be useful, if that. It would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13205: Run `validate --slow` during CI at least sometimes.
by GHC 22 Jun '18

22 Jun '18

#13205: Run `validate --slow` during CI at least sometimes. -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- We really should run `validate --slow` at times. It would catch #13204. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10059: :i doesn't work for ~
by GHC 22 Jun '18

22 Jun '18

#10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs Prelude> :set -XTypeOperators Prelude> :i (~) <interactive>:1:2: parse error on input ‘~’ Prelude> :k (~) (~) :: k -> k -> Constraint }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14023: Split up glasgow_exts.rst
by GHC 20 Jun '18

20 Jun '18

#14023: Split up glasgow_exts.rst -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | 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: -------------------------------------+------------------------------------- The `docs/users-guide/glasgow_exts.rst` is crazy large. This makes it difficult to navigate both while editing and reading. It should probably be split up into multiple files along the top-level headings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14283: Remove the special case for tagToEnum# in the code generator?
by GHC 19 Jun '18

19 Jun '18

#14283: Remove the special case for tagToEnum# in the code generator? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- The only remaining primop (aside from `unsafeCoerce#` and `seq`) that produces an enumeration type is `tagToEnum#`. There is some magic in the code generator to make garbage collection relating to this work as it has historically. We want to get rid of the special case. Simply removing it altogether actually does seem to work, but the code we generate likely isn't quite the same. The challenge here is that (despite what I thought earlier) we definitely ''can'' end up in code generation, under certain circumstances, with {{{#!hs case tagToEnum# @t x of ... }}} How does this happen? After all, in `caseRules` we carefully remove every case on `tagToEnum#` and `dataToTag#` applications! The trouble comes when CorePrep puts everything in A-normal form. Strict function applications are transformed into `case` forms, so {{{#!hs f (tagToEnum# x) }}} will become {{{#!hs case tagToEnum# x of y DEFAULT -> f y }}} Suddenly we have that ugly case! Hmph. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13944: Introduce synchronized FFI
by GHC 19 Jun '18

19 Jun '18

#13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | 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): | Wiki Page: -------------------------------------+------------------------------------- During hacking on ghc I/O libraries, i find an [https://github.com/winterland1989/stdio/tree/master/bench/diskIO interesting situation], to summarize: There're some FFI calls that vary a lot in time duration, this makes unsafe FFI bad because it make GC hard to synchronize all capacities. OTOH safe FFI 's overhead is too large to justify its usage. After some though i think we should Introduce a new FFI type, let call it `synchronized` for now, it should: 1. Have the same requirement as safe FFI of what kind of argument we can pass, e.g. pinned ByteArray, pass by value primitive type, etc. 2. It works like unsafe FFI call by directly jump to c code using current capacity's stack. 3. It should mark current capacity GC ready, and doesn't participate next GC. The point is that if a FFI call doesn't need GC guarantee, then it shouldn't stop GC running. The next GC will not be running with all threads, but that's not too terrible since it doesn't scale too much anyway. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13709: Drop GCC Driver
by GHC 19 Jun '18

19 Jun '18

#13709: Drop GCC Driver ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The original reason for the Windows GCC driver was to correct hard-coded paths in the GCC build from the `msys` project. The `msys2` builds we now exclusively use no longer have these issues. Which means 90% of the reason for the driver is gone. Given the recent issues with the driver. We can/should simplify things and drop it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8