October 2014 - ghc-tickets

[GHC] #8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table`
by GHC 18 Nov '14

18 Nov '14

#8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table` ----------------------------------+--------------------------------------- Reporter: jloos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I'm not sure if and how far the ghc-7.6.3 support for OS X is planned, but I hit a (possible) linker error with 7.6.3. I installed a homebrew gcc-4.8 and changed the ghc config to use it. I tried to compile the [http://hackage.haskell.org/package/bindings-GLFW bindings-GLFW] package, which was successful, and run `cabal test` on it, which fails with following error: {{{ final link ... ghc: lookupSymbol failed in relocateSection (relocate external) dist/build/HSbindings-GLFW-3.0.3.o: unknown symbol `__objc_empty_vtable' linking extra libraries/objects failed }}} After some research I discovered that this symbol (surely just the first which fails) is part of the Objective-C Runtime. The /usr/lib/libobjc.dylib exports this symbol. In desperation I think I nearly reached the google quota with my research, further steps I tried: Explicitly link the libobjc lib {{{ ghci -lobjc dist/build/HSbindings-GLFW-3.0.3.o -framework Foundation -framework Cocoa -framework IOKit }}} With the same result as above: {{{ GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) dist/build/HSbindings-GLFW-3.0.3.o ... done Loading object (dynamic) /usr/lib/libobjc.dylib ... done Loading object (framework) IOKit ... done Loading object (framework) Cocoa ... done Loading object (framework) Foundation ... done final link ... ghc: lookupSymbol failed in relocateSection (relocate external) dist/build/HSbindings-GLFW-3.0.3.o: unknown symbol `__objc_empty_vtable' linking extra libraries/objects failed }}} I found a [https://github.com/mxcl/homebrew/issues/23687 homebrew issue] related to gcc and the Apple switch from libstdc++to libc++ in 10.9 and i tried to force linking with explicit `-stdlib=libstdc++` in the cabal file (ld-options). But i guess this issue isn't related to the `__objc_***` problem, just tried it in desperation. Last week I managed to build ghc HEAD with clang bootstrapped with 7.4.6: the new linker mechanic seems to resolves this problem in a way (sadly some other packages aren't jet compatible with 7.8) So I'm not sure if this report is okay, if not, pardon me :) I'm aware of the problems with the current ghc-7.6.3 and the the changes OS X 10.9 brings with it (according to reddit/haskell cafe). The current suggestions is to not use the XCode-5.0.1/clang together with ghc-7.6.3. So I tried gcc from homebrew. I know that 7.8 will bring better linker capabilities, maybe there are just some flags to fix this specific problem with 7.6.3...? I didn't find it. So I thought it's better to report it. If further informations are required, I will try to provide them as fast as possible but I will have to downgrade to 10.8 tomorrow around 6 a.m. UTC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention)
by GHC 18 Nov '14

18 Nov '14

#9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I stumbled across the problem of LLVM 3.2 builds seemingly randomly crashing on my Mac. After quite a bit of investigation I found that the source of the problem was somewhere in the `base` library (`span` to be precise), where it encountered Cmm like follows: {{{ cp7n: if ((Sp + -56) < SpLim) goto cp8c; else goto cp8d; ... cp8d: I64[Sp - 40] = block_cp7g_info; _smKL::P64 = P64[R1 + 7]; _smKO::P64 = P64[R1 + 15]; _smKP::P64 = P64[R1 + 23]; _smL0::P64 = P64[R1 + 31]; R1 = R2; P64[Sp - 32] = _smKL::P64; P64[Sp - 24] = _smKO::P64; P64[Sp - 16] = _smKP::P64; P64[Sp - 8] = _smL0::P64; Sp = Sp - 40; if (R1 & 7 != 0) goto up8R; else goto cp7h; up8R: call block_cp7g_info(R1) args: 0, res: 0, upd: 0; ... }}} which leads LLVM 3.2 to produce the following assembly: {{{ _smL1_info: ## @smL1_info ## BB#0: ## %cp7n pushq %rbp movq %rsp, %rbp movq %r14, %rax movq %rbp, %rcx leaq -56(%rcx), %rdx cmpq %r15, %rdx jae LBB160_1 ... LBB160_1: ## %cp8d leaq _cp7g_info(%rip), %rdx movq %rdx, -40(%rcx) vmovups 7(%rbx), %ymm0 vmovups %ymm0, -32(%rcx) addq $-40, %rcx testb $7, %al je LBB160_4 ## BB#2: ## %up8R movq %rcx, %rbp movq %rax, %rbx popq %rbp vzeroupper jmp _cp7g_info ## TAILCALL }}} So here LLVM has figured out that it can use `vmovups` in order to move 4 words at the same time. However, there is a puzzling side effect: All of sudden we have a `pushq %rbp` at the start of the function with a matching `popq %rbp` at the very end. This overwrites the stack pointer update (`movq %rcx, %rbp`) and - unsurprisingly - causes the program to crash rather quickly. My interpretation is that LLVM 3.2 erroneously thinks that AVX instructions are incompatible with frame pointer elimination. The reasoning is that this is exactly the kind of code LLVM generates if we disable this "optimisation" (`--disable-fp-elim`). Furthermore, disabling AVX instructions (`-mattr=-avx`) fixes the problem - LLVM falls back to the less efficient `movups`, with `pushq $rbp` vanishing as well. Finally, this bug seems to happen exactly with LLVM 3.2, with 3.3 upwards generating correct code. My proposed fix would be to add `-mattr=-avx` to the `llc` command line by default for LLVM 3.2. This issue might be related to #7694. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknowns archs
by GHC 18 Nov '14

18 Nov '14

#9185: glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknowns archs -------------------------+------------------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Linux Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Stg.h defines _BSD_SOURCE which glibc 2.20 deprecates with warnings in favour of _DEFAULT_SOURCE. Since the verbose warning is output for every ghc invocation when building it is rather annoying and induces testsuite failures. The warning look like this: {{{ In file included from /usr/include/math.h:26:0: 0, from /usr/lib64/ghc-7.6.3/include/Stg.h:65, from /tmp/ghc783_0/ghc783_0.hc:3: /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ^ }}} Solution/workaround is to define "_DEFAULT_SOURCE" and that works. I asked in https://bugzilla.redhat.com/show_bug.cgi?id=1067110#c13 about how best to fix Stg.h and got the answer to just add _DEFAULT_SOURCE. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9578: Quoting issue in configure.ac
by GHC 18 Nov '14

18 Nov '14

#9578: Quoting issue in configure.ac -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Building hour) | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Some ghc invocations in configure.ac are not properly quoted, causing ./configure to spew errors if there are spaces in the path. See attached patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9713: Update comment about C helper for dynamic exports.
by GHC 18 Nov '14

18 Nov '14

#9713: Update comment about C helper for dynamic exports. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- The offending comment is in {{{compiler/deSugar/DsForeign.lhs}}}. The RTS API has changed so that {{{rts_evalIO}}} takes a capability as its first argument; so make the comment reflect reality. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9644: mapMaybes documentation contains some gibberish
by GHC 18 Nov '14

18 Nov '14

#9644: mapMaybes documentation contains some gibberish -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- "If it just Just b, [...]" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6
by GHC 18 Nov '14

18 Nov '14

#8511: GHCi Startup Crash with GHC 7.6.3 / HP 2013.2.0.0 64bit on OS X 10.6 ----------------------------------+------------------------------- Reporter: blitzcode | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- A couple of HP / GHC releases later this bug still seems to exist: http://ghc.haskell.org/trac/ghc/ticket/6138 32bit works fine, 64bit GHCi crashes frequently on startup, even with XCode 4.1 installed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread
by GHC 18 Nov '14

18 Nov '14

#8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread ------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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: | ------------------------------------+------------------------------------- It would be useful to be able to retrieve the label set by the labelThread function. For instance, a logging / tracing system could output a human readable string for the thread the trace originated from instead of just the thread ID. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES`
by GHC 18 Nov '14

18 Nov '14

#8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | 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: | ------------------------------------+------------------------------------- In order to save contributor’s time, and in order to run the test suite faster, I suggest to not builds haddock and its dependencies (xhtml, anything else?) if `HADDOCK_DOCS=YES` is specified. The change is rather simple: {{{ diff --git a/ghc.mk b/ghc.mk index dd91a82..b0f93a0 100644 --- a/ghc.mk +++ b/ghc.mk @@ -437,7 +437,9 @@ REGULAR_INSTALL_PACKAGES += compiler endif REGULAR_INSTALL_PACKAGES += $(addprefix libraries/,$(PACKAGES_STAGE2)) +ifeq "$(HADDOCK_DOCS)" "YES" PACKAGES_STAGE1 += xhtml +endif ifeq "$(Windows_Target)" "NO" ifneq "$(TargetOS_CPP)" "ios" PACKAGES_STAGE1 += terminfo @@ -652,8 +654,10 @@ BUILD_DIRS += libraries/integer-gmp/gmp BUILD_DIRS += libraries/integer-gmp/mkGmpDerivedConstants endif +ifeq "$(HADDOCK_DOCS)" "YES" BUILD_DIRS += utils/haddock BUILD_DIRS += utils/haddock/doc +endif BUILD_DIRS += compiler BUILD_DIRS += utils/hsc2hs BUILD_DIRS += utils/ghc-pkg }}} and it does not affect validate runs, as validate has `HADDOCK_DOCS` set to `YES`. If this is introduced, I suggest to annotate these two with a tag in packages, so that one can run `./sync-all get --no-haddock`, similar to `--no-dph`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8544: Auto-Reference ticket-related branches in tickets
by GHC 18 Nov '14

18 Nov '14

#8544: Auto-Reference ticket-related branches in tickets ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: | ------------------------------------+------------------------------------- This has two possible implementations (and both are useful and can complement each other): * Add a new field to the description „Related branch“. If for ticket #1234 there is a branch matching `T1234` (usually something like `wip/T1234`), link it from there. * When such a branch is created or deleted, post a message to the ticket. This way subscribers know about a possible ongoing implementation, and can review it. These should link somewhere I believe `https://ghc.haskell.org/trac/ghc/log/ghc?rev=<branchname>` is the most useful link. If the link is part of the „branch created“ message, it will become dangling after the branch is closed (presumably because the feature was merged; then the actually commits, if they reference the bug, will be auto-linked). I don’t think this is a problem. But if that is a problem, only put the link in the “Related branches” field, and clear it when the branch is deleted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2