May 2015 - ghc-tickets

[GHC] #10260: last uses too much space with optimizations disabled
by GHC 06 May '15

06 May '15

#10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I know we don't worry too much about performance when optimizations are disabled, but `last [1..n]` using O(n) space when the naive definition would run in O(1) space is a bit too much I think. Can we split out the new definition to a separate function and use a rule to rewrite `last` to that function when optimizations are enabled? I'm not expert enough on the use of rules and inlining phases etc. to write the patch myself, but I think it should be simple. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9673: ghc-7.8.3 fails to build on aarch64
by GHC 06 May '15

06 May '15

#9673: ghc-7.8.3 fails to build on aarch64 -------------------------------+--------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+--------------------------------------- (I first mentioned this recently in ticket:7942#comment:42 but I thought better to open a new ticket for this.) I tried to build ghc-7.8.3 on aarch64 Linux (Fedora 21 development) with the patch from #7942, and ran into: {{{ "inplace/bin/ghc-cabal" copy libraries/haskell2010 dist-install "strip" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' 'v dyn ' Installing library in /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/haskell2010-1.1.2.0 "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" --force --global-package-db "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. rts-1.0: Warning: library-dirs: /usr/lib64/ghc-7.8.3/rts-1.0 doesn't exist or isn't a directory rts-1.0: Warning: include-dirs: /usr/lib64/ghc-7.8.3/include doesn't exist or isn't a directory rts-1.0: cannot find any of ["libHSrts.a","libHSrts.p_a","libHSrts- ghc7.8.3.so","libHSrts-ghc7.8.3.dylib","HSrts-ghc7.8.3.dll"] on library path (ignoring) "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg : "" Registering ghc-prim-0.3.1.0... "inplace/bin/ghc-cabal" register libraries/integer-gmp dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg : "" ghc-cabal: Installed package ID not registered: "ghc-prim-0.3.1.0-inplace" ghc.mk:901: recipe for target 'install_packages' failed Makefile:64: recipe for target 'install' failed make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 }}} The problem seems to be that the installed (dynlinked) ghc-pkg does give any output!! (eg "ghc-pkg --version" returns "", same for --help.) When I try the built binaries I find that ghc-7.8.3/utils/ghc-pkg/dist/build/tmp/ghc-pkg (which is statically linked) works normally (ie it outputs --help and --version) whereas $DESTDIR/$libdir/ghc-7.8.3/bin/ghc-pkg gives no output on stdout! A workaround is to build with DYNAMIC_GHC_PROGRAMS=NO (ticket:7942#comment:44) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9673> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #10369: arm binaries have an executable stack
by GHC 06 May '15

06 May '15

#10369: arm binaries have an executable stack -----------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+------------------------------------- Test `T703` is currently failing on on armhf/linux. The test result shows: {{{ GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0 }}} Arm compiles via LLVM, but x86_64 executbles compiled via LLVM do not have an executable stack. The other difference between the x86_64 and Arm is the Arm uses `ld.gold` as the linker. Sure enough, adding `-optl -Wl,-z,noexecstack` to the ghc command line fixes this, but a better solution is needed. This is probably also an issue on AArch64 which also uses the `ld.gold` linker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8444: Fix CPP issue with Xcode5 in integer-simple
by GHC 06 May '15

06 May '15

#8444: Fix CPP issue with Xcode5 in integer-simple -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 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: | -------------------------------------+------------------------------------- This works around a build failure with Xcode 5's version of clang, wherein writing WORD_SIZE_IN_BITS.0 results in "64 .0" (note the space). (this is for libraries/integer-simple) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8445: Fix Xcode5 CPP issue with compiler/deSugar/DsBinds.lhs and compiler/utils/FastString.lhs
by GHC 06 May '15

06 May '15

#8445: Fix Xcode5 CPP issue with compiler/deSugar/DsBinds.lhs and compiler/utils/FastString.lhs ----------------------------------+---------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- A tiny patch to shuffle some spaces around to allow Xcode 5's clang CPP to compile these files correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8493: Can't compile happy + ghc with clang's CPP
by GHC 06 May '15

06 May '15

#8493: Can't compile happy + ghc with clang's CPP ----------------------------------+---------------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries | Version: 7.7 (other) | Operating System: MacOS X Keywords: happy | Type of failure: Building GHC failed Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- On OS X MtnLion with Xcode 5: Compiling GHC fails early on because the GenericTemate outputted by happy is syntactically invalid. It is invalid because of tabs inserted into the template that cause the functions to have syntax / indenting errors. I attempted to install happy to patch it, but happy will not compile either because of the tabs. I think clang's CPP is inserting tabs into lines with > 8 spaces of indentation. Also the comment lines in the template of this form are invalid for clang and cause it to fail. {{{ # 5 comment }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8493> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #3699: Wildcards in type functions
by GHC 06 May '15

06 May '15

#3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: dalaing MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by jstolarek): dalaing, what is the status of your work? I ask because I have a student who would be interested in implementing this ticket but if you are actively working on this ticket we will look for something else. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3699#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 06 May '15

06 May '15

#2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by zilinc): I feel it's too late to object, so I'll ask a question instead. I'm developing a software, in which I use the `VersionTags` field to store the git commit hash in order to know under which git revision my software is compiled. It's implemented by a hook in `Setup.hs`. So that the `showVersion` function can print something like `MySoftware 2.3.0.0-ce78942aed`, which is really handy for development. With the new changes in GHC, is there anywhere that I can put this piece of info? Or are you going to create another field in `PackageDescription` to keep extra notes? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2496#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10387: toRational should error out on NaN and Infinity values for Double/Floats
by GHC 05 May '15

05 May '15

#10387: toRational should error out on NaN and Infinity values for Double/Floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The current implementation of `toRational` for `Float`/`Double` types accept `NaN` and `Infinity` values and produce results. For `Infinity` the result nicely maps back to `Infinity`: {{{#!hs Prelude> fromRational (toRational (1/0)) :: Double Infinity Prelude> fromRational (toRational (-1/0)) :: Double -Infinity Prelude> }}} But the same isn't true for NaNs: {{{#!hs Prelude> fromRational (toRational (0/0)) :: Double -Infinity }}} Also, these results are probably architecture specific. In any case, I think `toRational` should simply error out if it receives `NaN` or `Infinity`, as there are really no legitimate values we can map them to, even though we might be able to complete the round-trip correctly in case if infinities. The following just doesn't make sense: {{{#!hs Prelude> toRational (1/0) 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 % 1 }}} So, I propose the `toRational` instance for Float/Double's should simply recognize `NaN` and `Infinite` values and throw an error. [Note that this is also how the HW implementations for the corresponding conversions work, raising a floating-point-exception (in the unmasked case). See `CVTPS2PI`/`CVTPS2DQ` etc., for instance, in x86.] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10387> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10235: Get profiling info without stopping program
by GHC 05 May '15

05 May '15

#10235: Get profiling info without stopping program -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I frequently want to know profiling information for web servers in production. Unfortunately there doesn't seem to be a way to trigger this without stopping the program, which might annoy my users. My ideal would be to able to call "dumpProfile :: Filename -> IO()" and then call that from a timer thread. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3