April 2014 - ghc-tickets

[GHC] #8672: :browse and roles on typefamilies
by GHC 10 Nov '14

10 Nov '14

#8672: :browse and roles on typefamilies -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- :browse on `ghci tests/ghci.debugger/scripts/T8557.hs` outputs a weird looking line: {{{ type role Sing nominal data family Sing (a :: k) type role T8557.R:Sing[]a nominal <-- data instance Sing a = SNil }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory]
by GHC 09 Nov '14

09 Nov '14

#9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory] -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: smartos illumos | Operating System: Solaris lndir sdist | Type of failure: Building GHC Architecture: Unknown/Multiple | failed Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- It appears that source for lndir was intentionally included in utils and customized to handle .git directories: http://git.haskell.org/ghc.git/blobdiff/c629bd1539b1865cc28ce053234595e7aeb… This ignoring of .git directories has been in the upstream lndir.c since 2009: http://cgit.freedesktop.org/xorg/util/lndir/tree/lndir.c However, lndir is not installed by default (on Ubuntu or SmartOS) and is not listed in the tools required to build: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools It does not appear to be built during the sync, boot, or make steps of a GHC build. Here is an excerpt: {{{ /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] ghc.mk:1117: recipe for target 'sdist-ghc-prep' failed gmake[1]: *** [sdist-ghc-prep] Error 127 Makefile:64: recipe for target 'sdist' failed gmake: *** [sdist] Error 2 }}} Here is a detailed log: http://haskell.inf.elte.hu/builders/smartos-x86_64-head/19/16.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8699: Multiple test faliures on 32-bit Linux systems.
by GHC 07 Nov '14

07 Nov '14

#8699: Multiple test faliures on 32-bit Linux systems. ----------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- I ran validate with HEAD (e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19) on 3 different 32-bit Linux boxes and I'm seeing different failures on each one. I was advised on IRC to create a ticket with all the failures. The first and third box are using the binary of 7.6.3 provided on the GHC site. I had to link libgmp.so.3 to libgmp.so.10 on both of these in order to get it to install properly. Please ask about any info that I have not provided below! First box: {{{Linux misaki 3.12.3-gentoo #2 SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.0 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.0, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 16 Oct 14 04:24 /usr/lib/libgmp.so.10 -> libgmp.so.10.1.3 lrwxrwxrwx 1 root root 12 May 31 2013 /usr/lib/libgmp.so.3 -> libgmp.so.10 }}} The full log is at [1]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.Cabal haddock.base" OVERALL SUMMARY for test run started at Sun Jan 26 03:26:36 2014 GMT 0:19:58 spent to go through 3883 total tests, which gave rise to 15172 test cases, of which 11625 were skipped 28 had missing libraries 3458 expected passes 58 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) }}} As discussed on the mailing list, the Haddock numbers still need tweaking even after Austin updated them the other day. T1969 failure seems to come and go. ---- Second box: {{{Linux yuuki 3.11.4-gentoo #1 SMP Tue Oct 8 00:19:37 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} I installed the bootstrapping compiler on this box from Gentoo's package manager so I'm not sure how gmp is linked here. I can retry by boostrapping from binary and linking libgmp.3 to libgmp.10 (like the other boxes did) for consistency. The version of this complier is 7.6.3-r1. The full log is at [2]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.compiler T7859" OVERALL SUMMARY for test run started at Sun Jan 26 03:34:47 2014 GMT 0:12:04 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3453 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) runghc T7859 [bad stderr] (normal) }}} A different Haddock perf failure, T1969 seems to have failed again and a totally new failure, T7859. ---- Third box: {{{Linux lenalee 3.11.4-gentoo #1 SMP Mon Oct 7 19:19:00 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 9 Jan 26 02:42 /usr/lib/libgmp.so.3 -> libgmp.so lrwxrwxrwx 1 root root 16 Nov 20 11:54 /usr/lib/libgmp.so -> libgmp.so.10.1.3 }}} The full log is at [3]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="hsc2hs004 T3837 haddock.compiler haddock.base T3307 environment001 T1969 gadt23 Capi_Ctype_001 Capi_Ctype_002" OVERALL SUMMARY for test run started at Sun Jan 26 03:28:47 2014 GMT 0:10:37 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3446 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 10 unexpected failures Unexpected failures: ../../libraries/base/tests/IO T3307 [bad stderr] (normal) ../../libraries/base/tests/IO environment001 [bad stderr] (normal) ffi/should_run Capi_Ctype_001 [bad stderr] (normal) ffi/should_run Capi_Ctype_002 [bad stderr] (normal) gadt gadt23 [bad stderr] (normal) hsc2hs T3837 [bad stderr] (normal) hsc2hs hsc2hs004 [bad stderr] (normal) perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) }}} Whole plethora of failures! Haddock numbers again and a bunch of other stuff. Considering how close 7.8 is, I think these should be looked at (especially that last set doesn't look too good). I notice that over 2000 more tests were skipped on the first box (this is my day-to-day use computer). How are the tests to be skipped determined? [1]: http://fuuzetsu.co.uk/misc/validate-misaki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [2]: http://fuuzetsu.co.uk/misc/validate-yuuki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [3]: http://fuuzetsu.co.uk/misc/validate-lenalee- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8828: allow fully applied type families in instance heads
by GHC 07 Nov '14

07 Nov '14

#8828: allow fully applied type families in instance heads ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi, it would be nice if the following example were acceptable: {{{ {-# LANGUAGE FlexibleInstances, TypeFamilies, TypeSynonymInstances #-} data X a = X a type family TX a type instance TX a = X a instance Show (TX Int) }}} But ghc complains that it cannot substitute the instance of TX: {{{ ts.hs:6:10: Illegal type synonym family application in instance: TX Int In the instance declaration for ‛Show (TX Int)’ }}} A more practical (but not self-contained) example involving extensible records looks http://lpaste.net/100436 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8812: Make *_stub.c files available again
by GHC 07 Nov '14

07 Nov '14

#8812: Make *_stub.c files available again ------------------------------------+------------------------------------- Reporter: ralphb | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- In our project we would like to link Haskell functions into C++ code. In principle this works fine using FFI. An additional constraint, however, is that we need to generate and link the object files ourselves. Alas, ghc no longer keeps the *_stub.c files around. (And fishing for files in /tmp is not a viable solution.) I would like to propose an additional command line switch to keep *_stub.c files, as previous compiler versions did by default. (Note that there is an older, similar request #7463, but our use case is much broader than that and not limited to unregistered compilation.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8829: GHC HEAD/7.8 fails to build on Solaris 10
by GHC 07 Nov '14

07 Nov '14

#8829: GHC HEAD/7.8 fails to build on Solaris 10 ----------------------------+---------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- Just to record this issue for further reference. Solaris 10 provides GCC 3.4.3 as a free compiler. Unfortunately compilation of GHC with this compiler fails with: {{{ gmake -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc- Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc- Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc- Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc- Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc- DCOMPILING_RTS -optc-DNOSMP -optc-DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno- strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc- fno-omit-frame-pointer -optc-g -optc-O0 -optc-DRtsWay=\"rts_thr_debug\" -static -optc-DTHREADED_RTS -optc-DDEBUG -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0 -c rts/sm/GC.c -o rts/dist/build/sm/GC.thr_debug_o /usr/ccs/bin/as: "/var/tmp//cclWYYHx.s", line 17827: error: statement syntax /usr/ccs/bin/as: "/var/tmp//cclWYYHx.s", line 17827: error: statement syntax /usr/ccs/bin/as: "/var/tmp//cclWYYHx.s", line 17827: error: statement syntax gmake[1]: *** [rts/dist/build/sm/GC.thr_debug_o] Error 1 gmake: *** [all] Error 2 }}} the problem analysis so far reveals that the problematic assembler code looks: {{{ 17826 .byte 0x3 17827 .word %r_tls_dtpoff32(gct) 17828 .byte 0xe0 }}} which seems to be kind of wrong. When I tested this with Solaris 11.1 GCC 4.5.2 I've not able to reproduce this error so I guess this is kind of miscompilation in GCC 3.4.3. Actually this is Solaris 10 update 11 distributed GCC: {{{ $ gcc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with- ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable- shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) }}} so that may serve as kind of known issue on sparc/solaris 10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8829> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8843: Maverick GHC --make problem - linking problem
by GHC 07 Nov '14

07 Nov '14

#8843: Maverick GHC --make problem - linking problem ----------------------------------+--------------------------------------- Reporter: teuffy | 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: | ----------------------------------+--------------------------------------- Hi when I runghc code_x.hs --> program is running when I ghc --make code_x.hs --> I got this error message. Do you know where the problem is coming from? Undefined symbols for architecture x86_64: "_iconv", referenced from: _hs_iconv in libHSbase-4.6.0.1.a(iconv.o) (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding11_info, _base_GHCziIOziEncodingziIconv_iconvEncoding10_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _hs_iconv_open , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding5_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding10_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure ) "_iconv_close", referenced from: _hs_iconv_close in libHSbase- 4.6.0.1.a(iconv.o) (maybe you meant: _hs_iconv_close) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.6.0.1.a(iconv.o) (maybe you meant: _hs_iconv_open) "_locale_charset", referenced from: _localeEncoding in libHSbase-4.6.0.1.a(PrelIOUtils.o) ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(dyn) test
by GHC 06 Nov '14

06 Nov '14

#8921: ghc-stage2 fails with ld: fatal: library -lrt: not found on topHandler02(dyn) test -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- On SmartOS ghc-stage2 crashes with an error when trying to run the topHandler02(dyn) test: ld: fatal: library -lrt: not found Tracing this with the following DTrace script to stop ghc-stage2 at the point of launching ld: '''~/exit_on_ld.d''': {{{ #!/usr/sbin/dtrace -s #pragma D option destructive syscall::exec*:entry /copyinstr(arg0) == "/usr/bin/ld"/ { trace(pid); stop(); system("pargs %d", pid); exit(0); } }}} This let me observe the command-line arguments to ld: In ssh session A I started DTrace: {{{ chmod +x ~/exit_on_ld.d ~/exit_on_ld.d }}} In a ssh session B I started the topHandler02(dyn) test manually with no output redirection: {{{ cd ~/ghc/libraries/base/tests && '/root/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o topHandler02 topHandler02.hs -O -prof -static -auto-all -threaded }}} In ssh session A I observed the ld call (ghc-stage2 is now frozen by stop): {{{ CPU ID FUNCTION:NAME 3 5167 exece:entry 9186691866: /opt/local/gcc47/libexec/gcc/x86_64-sun-solaris2.11/4.7.3/collect2 -R/opt/local argv[0]: /opt/local/gcc47/libexec/gcc/x86_64-sun- solaris2.11/4.7.3/collect2 argv[1]: -R/opt/local/lib/ argv[2]: -Y argv[3]: P,/lib/amd64:/usr/lib/amd64:/opt/local/lib/ argv[4]: -Qy argv[5]: -o argv[6]: topHandler02.o argv[7]: -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3 argv[8]: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../../x86_64-sun-solaris2.11/lib/amd64 argv[9]: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../amd64 argv[10]: -L/lib/amd64 argv[11]: -L/usr/lib/amd64 argv[12]: -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../../x86_64-sun-solaris2.11/lib argv[13]: -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../.. argv[14]: -R/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64 argv[15]: -R/opt/local/gcc47/lib/amd64 argv[16]: -lrt argv[17]: -r argv[18]: /tmp/ghc91814_0/ghc91814_6.o argv[19]: /tmp/ghc91814_0/ghc91814_5.o }}} I was then able to run them in isolation with GHC's temp files present on disk: {{{ # /opt/local/gcc47/libexec/gcc/x86_64-sun-solaris2.11/4.7.3/collect2 -R/opt/local/lib/ -Y P,/lib/amd64:/usr/lib/amd64:/opt/local/lib/ -Qy -o topHandler02.o -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../.. -R/opt/local/gcc47/x86_64-sun- solaris2.11/lib/amd64 -R/opt/local/gcc47/lib/amd64 -lrt -r /tmp/ghc91814_0/ghc91814_6.o /tmp/ghc91814_0/ghc91814_5.o ld: fatal: library -lrt: not found ld: fatal: file processing errors. No output written to topHandler02.o collect2: error: ld returned 1 exit status }}} If I omit '''-lrt''' from the arguments it succeeds (on Illumos-based systems, including SmartOS, librt is a passthrough to libc): {{{ # /opt/local/gcc47/libexec/gcc/x86_64-sun-solaris2.11/4.7.3/collect2 -R/opt/local/lib/ -Y P,/lib/amd64:/usr/lib/amd64:/opt/local/lib/ -Qy -o topHandler02.o -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/opt/local/gcc47/lib/gcc/x86_64-sun-solaris2.11/4.7.3/../../../../x86_64 -sun-solaris2.11/lib -L/opt/local/gcc47/lib/gcc/x86_64-sun- solaris2.11/4.7.3/../../.. -R/opt/local/gcc47/x86_64-sun- solaris2.11/lib/amd64 -R/opt/local/gcc47/lib/amd64 -r /tmp/ghc91814_0/ghc91814_6.o /tmp/ghc91814_0/ghc91814_5.o # echo $? 0 }}} No errors are emitted and the exit code is 0 (good). I would like to conditionally omit '''-lrt''' from the ld arguments. Where do I need to look for where ghc-stage2 populates the arguments to ld? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8962: compile hang and memory blowup when using profiling and optimization
by GHC 06 Nov '14

06 Nov '14

#8962: compile hang and memory blowup when using profiling and optimization -------------------------+------------------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.8.1-rc2 Component: | Operating System: Linux Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: x86_64 (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- When I try to compile the following files: {{{ -- Vectorize.hs {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE TypeOperators #-} module Vectorize ( GVectorize(..) ) where import GHC.Generics import Data.Vector ( Vector ) import qualified Data.Vector as V gvlength :: GVectorize f => f a -> Int gvlength = V.length . gvectorize . (gempty `asFunctorOf`) where asFunctorOf :: f a -> f b -> f a asFunctorOf x _ = x class GVectorize f where gdevectorize :: Vector a -> f a gvectorize :: f a -> Vector a gempty :: f () instance (GVectorize f, GVectorize g) => GVectorize (f :*: g) where gdevectorize v0s | V.length v0s < n0 = error $ show n0 | otherwise = f0 :*: f1 where f0 = gdevectorize v0 f1 = gdevectorize v1 n0 = gvlength f0 (v0,v1) = V.splitAt n0 v0s gvectorize (f :*: g) = gvectorize f V.++ gvectorize g gempty = gempty :*: gempty instance GVectorize f => GVectorize (M1 i c f) where gdevectorize = M1 . gdevectorize gvectorize = gvectorize . unM1 gempty = undefined -- M1 gempty instance GVectorize Par1 where gdevectorize _ = undefined gvectorize = V.singleton . unPar1 gempty = undefined -- Par1 () }}} {{{ -- Woo.hs {-# OPTIONS_GHC -Wall #-} {-# Language DeriveGeneric #-} module Woo ( Woo(..) , devectorize ) where import GHC.Generics import Data.Vector ( Vector ) import Vectorize ( GVectorize(..) ) data Woo a = MkWoo { x00 :: a , x01 :: a , x02 :: a , x03 :: a , x04 :: a , x05 :: a , x06 :: a , x07 :: a , x08 :: a , x09 :: a , x10 :: a , x11 :: a , x12 :: a , x13 :: a , x14 :: a , x15 :: a , x16 :: a , x17 :: a , x18 :: a , x19 :: a , x20 :: a , x21 :: a } deriving (Generic1) devectorize :: Vector a -> Woo a devectorize = to1 . gdevectorize }}} with `ghc -O2 -prof -fprof-auto-calls Woo.hs`, GHC seems to hang on Woo.o and the memory usage steadily creeps up (I killed it at 5GB after about 5 minutes). I don't think this is #7068 / #7898 / #8960 because `-fno-spec-constr` doesn't fix it and the end of the -v3 output is: {{{ ... ... *** SpecConstr: Result size of SpecConstr = {terms: 89,855, types: 125,614, coercions: 138,597} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 428,416, types: 555,965, coercions: 855,101} Result size of Simplifier = {terms: 428,386, types: 555,815, coercions: 626,125} *** Tidy Core: Result size of Tidy Core = {terms: 428,386, types: 555,815, coercions: 626,125} writeBinIface: 190 Names writeBinIface: 495 dict entries *** CorePrep: Result size of CorePrep = {terms: 533,584, types: 600,927, coercions: 626,125} *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: }}} and then about another 100 lines of `*** CPSZ:` before it hangs. Removing either the optimization or profiling flags fixes the bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8975: Troubling build warning with GHC 7.8.1 on Mavericks
by GHC 06 Nov '14

06 Nov '14

#8975: Troubling build warning with GHC 7.8.1 on Mavericks ----------------------------------+------------------------------ Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------ When building with gcc 4.8, I see this non-fatal error in the build log: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name time-1.4.2 -hide-all-packages -i -ilibraries/time/. -ilibraries/time/dist-install/build -ilibraries/time/dist- install/build/autogen -Ilibraries/time/dist-install/build -Ilibraries/time /dist-install/build/autogen -Ilibraries/time/include -optP- DLANGUAGE_Rank2Types -optP-DLANGUAGE_DeriveDataTypeable -optP- DLANGUAGE_StandaloneDeriving -optP-include -optPlibraries/time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package deepseq-1.3.0.2 -package old-locale-1.0.0.6 -Wall -XHaskell2010 -XCPP -XRank2Types -XDeriveDataTypeable -XStandaloneDeriving -O2 -no-user- package-db -rtsopts -odir libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir libraries/time/dist- install/build -split-objs -dynamic-too -c libraries/time/./Data/Time/Calendar/Days.hs -o libraries/time/dist- install/build/Data/Time/Calendar/Days.o -dyno libraries/time/dist- install/build/Data/Time/Calendar/Days.dyn_o /usr/local/src/ghc-7.8.1/libraries/base/dist- install/build/Data/Typeable/Internal.hi Declaration for mkTyConApp Unfolding of Data.Typeable.Internal.mkTyConApp: Failed to load interface for ‘GHC.Fingerprint’ There are files missing in the ‘base’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name time-1.4.2 -hide-all-packages -i -ilibraries/time/. -ilibraries/time/dist-install/build -ilibraries/time/dist- install/build/autogen -Ilibraries/time/dist-install/build -Ilibraries/time /dist-install/build/autogen -Ilibraries/time/include -optP- DLANGUAGE_Rank2Types -optP-DLANGUAGE_DeriveDataTypeable -optP- DLANGUAGE_StandaloneDeriving -optP-include -optPlibraries/time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package deepseq-1.3.0.2 -package old-locale-1.0.0.6 -Wall -XHaskell2010 -XCPP -XRank2Types -XDeriveDataTypeable -XStandaloneDeriving -O2 -no-user- package-db -rtsopts -odir libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir libraries/time/dist- install/build -split-objs -dynamic-too -c libraries/time/./Data/Time/Clock/Scale.hs -o libraries/time/dist- install/build/Data/Time/Clock/Scale.o -dyno libraries/time/dist- install/build/Data/Time/Clock/Scale.dyn_o /usr/local/src/ghc-7.8.1/libraries/base/dist- install/build/Data/Typeable/Internal.hi Declaration for mkTyConApp Unfolding of Data.Typeable.Internal.mkTyConApp: Failed to load interface for ‘GHC.Fingerprint’ There are files missing in the ‘base’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name time-1.4.2 -hide-all-packages -i -ilibraries/time/. -ilibraries/time/dist-install/build -ilibraries/time/dist- install/build/autogen -Ilibraries/time/dist-install/build -Ilibraries/time /dist-install/build/autogen -Ilibraries/time/include -optP- DLANGUAGE_Rank2Types -optP-DLANGUAGE_DeriveDataTypeable -optP- DLANGUAGE_StandaloneDeriving -optP-include -optPlibraries/time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package deepseq-1.3.0.2 -package old-locale-1.0.0.6 -Wall -XHaskell2010 -XCPP -XRank2Types -XDeriveDataTypeable -XStandaloneDeriving -O2 -no-user- package-db -rtsopts -odir libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir libraries/time/dist- install/build -split-objs -dynamic-too -c libraries/time/./Data/Time/Clock/UTC.hs -o libraries/time/dist- install/build/Data/Time/Clock/UTC.o -dyno libraries/time/dist- install/build/Data/Time/Clock/UTC.dyn_o }}} I don't know if this is actually a problem or not, but since it doesn't cause make to fail, it possible that it may not have been noticed yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8975> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2