October 2014 - ghc-tickets

[GHC] #8688: internal error: stg_ap_p_ret
by GHC 17 Nov '14

17 Nov '14

#8688: internal error: stg_ap_p_ret ------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- When in GHCi I get: <interactive>: internal error: stg_ap_p_ret (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug There is probably something wrong with the FFI binding I am testing; under other circumstances I get a segfault. But since I was asked to report this, here I am. Let me know if I can provide anything else. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8716: improve AMP join warning
by GHC 17 Nov '14

17 Nov '14

#8716: improve AMP join warning ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Any module that defines a top-level join gets this error: {{{ Local definition of ‛join’ clashes with a future Prelude name - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. }}} This file triggers the warning, but it will keep on working when Prelude exports join: {{{ module M1 (M.join) where join x = x }}} This file will break when Prelude exports join, but there is no warning currently given. {{{ module M2 where import M1 (join) f x = join }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8730: Invalid Unicode Codepoints in Char
by GHC 16 Nov '14

16 Nov '14

#8730: Invalid Unicode Codepoints in Char ------------------------------------+------------------------------------- Reporter: mdmenzel | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: unicode | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The surrogate range in Unicode is supposed to (as of Unicode 2.0, 1996) be a range of invalid code points yet, Data.Char allows the use of values in this range (in fact, it even gives them their own GeneralCategory). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8756: Test case concurrent/should_run/T5611 fails on Mac
by GHC 16 Nov '14

16 Nov '14

#8756: Test case concurrent/should_run/T5611 fails on Mac ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- On a fresh check out, test case concurrent/should_run/T5611 fails: {{{ Actual stderr output differs from expected: --- ./T5611.stderr 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stderr 2014-02-08 22:00:06.000000000 -0500 @@ -1 +0,0 @@ -T5611: user error (Exception delivered successfully) Actual stdout output differs from expected: --- ./T5611.stdout 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stdout 2014-02-08 22:00:06.000000000 -0500 @@ -1,2 +1,3 @@ child: Sleeping +child: Done waiting parent: Done throwing exception *** unexpected failure for T5611(normal) }}} I'm on Mac OS 10.8.5 with Xcode 4.6.1 (4H512). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8798: Missing symbols with -fprof-auto-calls
by GHC 16 Nov '14

16 Nov '14

#8798: Missing symbols with -fprof-auto-calls ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- To reproduce: in an empty environment (no packages installed), run {{{ cabal install --only-dependencies --enable-library-profiling --ghc-option =-fprof-auto-calls }}} for the attached test case. This will seem to work okay (no errors), but if you then do {{{ cabal configure --enable-executable-profiling --enable-library-profiling --ghc-option=-fprof-auto-calls }}} then {{{ cabal build }}} will fail with {{{ Building autocallsbug-0.1.0.0... Preprocessing executable 'autocallsbug' for autocallsbug-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/autocallsbug /autocallsbug-tmp/Main.p_o ) Linking dist/build/autocallsbug/autocallsbug ... Undefined symbols for architecture x86_64: "_attoparseczm0zi11zi1zi0_DataziAttoparsecziInternalziTypes_manyzimanyzuv_Cb_cc", referenced from: _sR1Q_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) _sR5p_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} (Haven't yet confirmed with 7.8RC1 because that failed to build on my system; reported separately.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC
by GHC 15 Nov '14

15 Nov '14

#9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC ----------------------------------+---------------------------------------- Reporter: ulysses4ever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I followed “First steps” section in [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). During the last step (make) it comes to the error: {{{ /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9192: Add sameByteArray#
by GHC 15 Nov '14

15 Nov '14

#9192: Add sameByteArray# ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We have `sameMutableByteArray#` so we ought to have `sameByteArray#` as well, allowing for cheap equality checks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9197: FFI types should be usable in foreign import decls without revealing representations
by GHC 15 Nov '14

15 Nov '14

#9197: FFI types should be usable in foreign import decls without revealing representations ------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is another go at #5529 but with, we hope, clearer and better arguments. The original FFI spec defined a whole bunch of FFI types that are acceptable in foreign import/export declarations, including lots of things defined in Foreign.C.*. The original spec defined these as abstract types. The original FFI spec also allowed for automatic newtype unwrapping in foreign declarations. In 2009 Simon PJ [pointed out http://www.haskell.org/pipermail/haskell-prime/2009-February/002726.html] that automatic newtype unwrapping breaks abstraction for user-defined types. In that same thread [I suggested http://www.haskell.org/pipermail /haskell-prime/2009-February/002727.html] that the breaking of abstraction for user types should be fixed, but that the intent of the FFI spec to have the FFI types as abstract should be kept. Manuel [argued http://www.haskell.org/pipermail/haskell-prime/2009-February/002729.html] that the C FFI types should actually not be abstract, and thus no special case for them was needed. On the basis of that thread the decision in #5529 was to only allow FFI decls to look through newtypes when the constructor is available, plus for a few types GHC uses to represent the C FFI types, like Int32 etc. Johan and I want to argue that it still makes sense as a user to not be forced into knowing the representation of the C FFI types to be able to use them. This is similar to but slightly weaker than the rationale of the FFI spec originally making those types abstract. Manuels argument is essentially that sometimes you need to know concrete types when those can change, e.g. CInt might be Int32 or Int64 and you should be free to depend on that difference. Manuel's argument is fine when the "concrete" representation exists as yet another portable type, as is the case for Int32. Of course we don't insist that the representation for Int or Int32 be exposed, in large part because they cannot have a Haskell implementation independent representation. The important point is Johan and I are defining/writing a portable low level ByteArray library that could be considered alongside the FFI's definition of some of the Foreign.* libraries: it defines and API for some low level types and functions but different Haskell implementations will implement them differently. For GHC we implement `data ByteArray = BA ByteArray#`. We want to make this an FFI type, in the same sense as the FFI spec defines the C types to be FFI types. (You could consider our library as a Haskell extension and implementations following this extension will support this type for FFI in a similar way to the FFI spec). Of course for this implementation of `ByteArray` the representation crosses the boundary into implementation dependent, unlike the case for `newtype CInt = CInt Int32` where both are still portable types. So, we think the right thing to do is to again be able to declare certain types (those defined in the FFI spec and its extensions) as being valid types to use in FFI decls, without their constructors being available. Thus users could choose to import `CInt` only (i.e. without its constructor) and use it. We are not arguing against Manuel's point that it's sometimes useful to not hide representations where that is possible (like for CInt being an Int32 or 64). So we are not asking that the C FFI types be made abstract again, just that it be possible to use them (and our new type) as FFI types without user access to the constrctor. For GHC, my suggestion for a reasonable way to do this is with a pragma. The pragma would say that this single-constrcutor single-field newtype or data is an FFI type, and that GHC may perform the usual newtype unwrapping even when the constructor is not in scope at the FFI decl site. We would then use this pragma on Int, Int32 and other core GHC (and FFI) types, and also on the various C FFI types. And finally, we would also do this on our ByteArray type. Note that it would have to cover data as well as newtype to be able to work for Int and other boxed wrappers of unboxed types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9286: ghc-7.9.20140707 fails testsuite on OS X (
by GHC 14 Nov '14

14 Nov '14

#9286: ghc-7.9.20140707 fails testsuite on OS X ( ----------------------------+---------------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: MacOS X testsuite | Type of failure: Building GHC failed Architecture: x86_64 | Test Case: T5435_dyn_asm T4801 T6048 (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Using ghc straight from the git repository, I just ran sh validate. The ghc that I used to build this new one was from https://github.com/ghcformacosx/ghc-dot-app (a neat packaging of GHC as it does not mess with system system files). This is on Yosemite DP3, XCode 6 Beta 3. {{{ OVERALL SUMMARY for test run started at Tue Jul 8 21:51:22 2014 BST 0:45:11 spent to go through 4039 total tests, which gave rise to 15863 test cases, of which 12161 were skipped 28 had missing libraries 3606 expected passes 65 expected failures 0 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T4801 [stat too good] (normal) perf/compiler T6048 [stat not good enough] (optasm) rts T5435_dyn_asm [bad stdout] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8701: Update libffi-tarballs to latest libffi
by GHC 14 Nov '14

14 Nov '14

#8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- libffi 3.0.14 contains fixes necessary for successful iOS (and probably ARM in general) cross-compilation. I've created a new archive that can be dropped in to replace the current libffi-tarballs archive here: https://github.com/ghc-ios/libffi- tarballs/blob/master/libffi-3.0.14.tar.gz?raw=true -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6