December 2015 - ghc-tickets

[GHC] #11240: Simplifier ticks exhausted on Y combinator
by GHC 21 Dec '15

21 Dec '15

#11240: Simplifier ticks exhausted on Y combinator -------------------------------------+------------------------------------- Reporter: sweirich | 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: -------------------------------------+------------------------------------- The code from this stackoverflow question: https://programmers.stackexchange.com/questions/215712/type-checking-and- recursive-types-writing-the-y-combinator-in-haskell-ocaml i.e. {{{#!hs newtype Mu a = Roll { unroll :: Mu a -> a } fix :: (a -> a) -> a fix = \f -> (\x -> f (unroll x x)) $ Roll (\x -> f (unroll x x)) }}} produces the following output when compiled with GHC 7.10.2 or 7.10.3: {{{ sweirich$ ghc --make Mu.hs [1 of 1] Compiling Mu ( Mu.hs, Mu.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone a_sml To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 4962 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code compiles with newtype replaces by data. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10814: Eliminate some ambiguity for IsString [a]
by GHC 21 Dec '15

21 Dec '15

#10814: Eliminate some ambiguity for IsString [a] -------------------------------------+------------------------------------- Reporter: dolio | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The libraries list resolved to make a modification to the `String` instance for `IsString` to resolve certain ambiguous cases. One example is: {{{#!hs "hello" ++ " world" }}} This case can be resolved by making the instance: {{{#!hs instance (a ~ Char) => IsString [a] where ... }}} rather than: {{{#!hs instance IsString [Char] where ... }}} as the former matches only based on the head being `[a]`, and subsequently determines `a ~ Char`, rather than only matching when other factors cause the head to be fully resolved to `[Char]`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11019: ApiAnnotations: Make all RdrName occurences Located
by GHC 21 Dec '15

21 Dec '15

#11019: ApiAnnotations: Make all RdrName occurences Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment the API Annotations can only be used on the `ParsedSource`, as there are changes made to the `RenamedSource` that prevent it from being used to round trip source code. It is possible to build a map from every `Located Name` in the `RenamedSource` from its location to the `Name`, which can then be used when resolved names are required when changing the `ParsedSource`. However, there are instances where the identifier is not located, specifically {{{#!hs (GHC.VarPat name) (GHC.HsVar name) (GHC.UserTyVar name) (GHC.HsTyVar name) }}} Replace each of the `name` types above with `(Located name)` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #4914: FPU initialization required again
by GHC 19 Dec '15

19 Dec '15

#4914: FPU initialization required again ------------------------------------------------+------------------------- Reporter: aruiz | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.2.1 Component: Compiler (NCG) | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect result at runtime | Test Case: Blocked By: | Blocking: ------------------------------------------------+------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"34eaf2b8d699c49ba367f26840052c8c9aa031b1/ghc" 34eaf2b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34eaf2b8d699c49ba367f26840052c8c9aa031b1" Fix two occurences of `x86_HOST_ARCH` The proper name for the define is `i386_HOST_ARCH` One was introduced back in 2011 via 035b8ebb5405efbcbfd3474821a877add1feca1e / #4914 and the other one more recently via 4905b83a2d448c65ccced385343d4e8124548a3b We may want to add some validation to catch such typos early on... Reviewed By: erikd Differential Revision: https://phabricator.haskell.org/D1664 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4914#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform
by GHC 19 Dec '15

19 Dec '15

#10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.11 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, ghc-prim is using GCC's {{{__builtin_ctz(ll)/clz(ll)}}} functions to implement functionality to count leading or trailing zeros in provided integer type variable. The problem with those GCC's builtins is that on platform which does not implement either of the operation in ISA, such function call can't be replaced by simple ISN, but needs to be replaced by the call to the libgcc library which then implements the missing operation in generic C. In ghc- prim you can already see a workaround for missing *ll functions on i386. The problem is that generic SPARC (v9) does not provide ISNs in its ISA to implement those builtins effectively so any call to builtins above is replaced by the call to the libgcc. The inserted functions calls are {{{__ctzsi2/__ctzdi2/__clzsi2/__clzdi2}}} in this case. Unfortunately this makes a lot of GHCi testcases (if not all!) failing with the error: {{{ ghc-stage2: /home/karel/src/obj-ghc-sparc-reg_ncg- head-2015-04-07-debug/libraries/ghc-prim/dist-install/build/HSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3.o: unknown symbol `__clzdi2' ghc-stage2: unable to load package `ghc-prim-0.4.0.0' }}} Please note, this happens only on platforms which does not support shared libs for GHC. On platforms with GHC shared libs support, ghc-prim is shared library which is correctly linked against the libgcc shared library and such error does not happen. (example Solaris/i386). Unfortunately we can't link ghc-prim*.o with libgcc -- it does effectively nothing so there are two solution for this issue IMHO: 1) on problematic platform implement hs_ctz*/hs_clz* functions in pure C without usage of GNU C builtin functions. or 2) enforce linking of shared libgcc with produced application binary. Such linking needs to be enforced with -shared-libgcc parameter passed to the GNU C in linking step and also by usage of either builtins in the application C code (not library code). My experimental code below shows that this is possible (tested on Solaris/SPARC). Please note that by default on static platform, the static version of libgcc is used and this does not help here. Also please note that usage of builtin in let say RTS library does not help either. I've tested RtsMain.c. The reason is the same like why it's not working in ghc-prim. We can't link *.o or *.a against shared libgcc. {{{ diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index c86667c..7c615d1 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1651,6 +1651,7 @@ mkExtraObjToLinkIntoBinary dflags = do | gopt Opt_NoHsMain dflags = Outputable.empty | otherwise = vcat [ text "#include \"Rts.h\"", + text "#include <stdio.h>", text "extern StgClosure ZCMain_main_closure;", text "int main(int argc, char *argv[])", char '{', @@ -1662,6 +1663,10 @@ mkExtraObjToLinkIntoBinary dflags = do Just opts -> ptext (sLit " __conf.rts_opts= ") <> text (show opts) <> semi, text " __conf.rts_hs_main = rtsTrue;", + text " printf(\"ctz(argc): %d\\n\", __builtin_ctz(argc));", text " return hs_main(argc,argv,&ZCMain_main_closure,__conf);", char '}', char '\n' -- final newline, to keep gcc happy }}} of course this is just a proof of concept. For real code we would need some place to save the result of the called builtin to prevent GCC from removing the call as an unused value. I guess one added value in {{{__conf}}} just for this case should do the job here. I'm free to implement either of those two solutions or even completely different one, I just need to know your preference in this case. BTW: I'm ccing people from #9340 which looks really related to this issue. If you are not interested in this issue discussion, please un-cc yourself. Thanks! Karel PS: as this is IMHO general issue, I'm not setting SPARC/Solaris as Architecture/OS here... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10334> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11211: Please add initial platform support for sparc64
by GHC 19 Dec '15

19 Dec '15

#11211: Please add initial platform support for sparc64 --------------------------------+---------------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Other | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Hello! I have successfully bootstrapped ghc for sparc64 on Debian unstable by cross-compiling it on amd64, then installing it manually into a build root and rebuild the Debian package. Unfortunately, the buildds can currently neither compile ghc itself nor any Haskell packages as gcc always passes "-relax" to the GNU linker which will fail as ghc passes "-Wl,-r" [1]: "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl- pthread -package-db libraries/bootstrapping.conf -this-package-key termi_6iVf4EBnOgfIaaOCLRs8jl -hide-all-packages -i -ilibraries/terminfo/. -ilibraries/terminfo/dist-boot/build -ilibraries/terminfo/dist- boot/build/autogen -Ilibraries/terminfo/dist-boot/build -Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/. -optP-include -optPlibraries/terminfo/dist- boot/build/autogen/cabal_macros.h -package-key base_HQfYBxpPvuw8OunzQu6JGM -Wall -XHaskell2010 -no-user-package-db -rtsopts -odir libraries/terminfo/dist-boot/build -hidir libraries/terminfo/dist- boot/build -stubdir libraries/terminfo/dist-boot/build -c libraries/terminfo/./System/Console/Terminfo/Base.hs -o libraries/terminfo /dist-boot/build/System/Console/Terminfo/Base.o /usr/bin/ld: --relax and -r may not be used together collect2: error: ld returned 1 exit status make[3]: *** [libraries/terminfo/dist- boot/build/System/Console/Terminfo/Base.o] Error 1 libraries/terminfo/ghc.mk:3: recipe for target 'libraries/terminfo/dist- boot/build/System/Console/Terminfo/Base.o' failed This issue has already been fixed in ghc but that was for sparc only and not sparc64 [2]. Thus, in order to be able to apply the same fix from [2], ghc needs to add sparc64 to its list of known architectures (currently "sparc64" matches to "ArchUnknown" in aclocal.m4") and then extend the fix from [2] to match *both* sparc *and* sparc64 (please don't drop sparc here). In particular, I suggest adding sparc64 in the same way that Alpha, Mipseb and Mipsel were added [3], thus matching "sparc64" to "ArchSPARC64", then extending the if-clause from [4] to set "-Wl,-no-relax" for *both* ArchSPARC *and* ArchSPARC64. Thanks, Adrian > [1] https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc64&ver=7.10.3-… > [2] https://ghc.haskell.org/trac/ghc/ticket/3791 > [3] https://git.haskell.org/ghc.git/commitdiff/9756690fe7aa26aee6955d0b720377d5… > [4] https://git.haskell.org/ghc.git/commitdiff/3b322660f82d0c7c4f7d02523367ebd0… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #449: Very big integer arithmetic crashes GHCi on Windows and Mac
by GHC 19 Dec '15

19 Dec '15

#449: Very big integer arithmetic crashes GHCi on Windows and Mac -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.4.2 Component: Runtime System | Version: 6.4.1 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: simonmar (added) * failure: => Runtime crash Comment: Indeed. This is fixed in GMP 6.1.0, see #7655. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/449#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode
by GHC 19 Dec '15

19 Dec '15

#10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: hsc2hs | Version: 7.11 Keywords: cross- | Operating System: Unknown/Multiple compiling | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #10070 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Attempting to cross-compile from linux to windows (after an in-progress fix to #10070) and ran into: {{{ libraries/haskeline/System/Console/Haskeline/Backend/Win32.hsc:170 directive let cannot be handled in cross-compilation mode }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4340: Add alignment to hsc2hs template
by GHC 19 Dec '15

19 Dec '15

#4340: Add alignment to hsc2hs template -------------------------------------+------------------------------------- Reporter: mitar | Owner: RyanGlScott Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: hsc2hs/T4340 Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Phab:D1436 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => hsc2hs/T4340 * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4340#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4340: Add alignment to hsc2hs template
by GHC 19 Dec '15

19 Dec '15

#4340: Add alignment to hsc2hs template -------------------------------------+------------------------------------- Reporter: mitar | Owner: RyanGlScott Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Phab:D1436 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"2cc5b607df27e702541985f7c4c987806c4ec2a1/ghc" 2cc5b607/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cc5b607df27e702541985f7c4c987806c4ec2a1" Documentation, tests for hsc2hs's new #alignment macro Adds two tests (one for Trac #4340 and one for Trac #10272), as well as advice on how to fix your code if `hsc2hs` emits warnings with GHC 8.0 due to a redefinition of `#alignment`. (I also put the advice in the [GHC 8.0 Migration Guide](https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0).) Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D1663 GHC Trac Issues: #4340, #10272 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4340#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0