March 2014 - ghc-tickets

[GHC] #8750: Invalid identifier generated with Template Haskell not rejected
by GHC 13 Nov '14

13 Nov '14

#8750: Invalid identifier generated with Template Haskell not rejected --------------------------+------------------------------------------------ Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: | Operating System: Unknown/Multiple Template Haskell | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I wrote Template Haskell code that generates this declaration: {{{ data (:+Sym1) (a:: Nat) (b :: TyFun Nat Nat) }}} `(:+Sym1)` is not a valid identifier and this declaration fails when I simply put it in a source file and try to compile it. However I get no errors when this definition is generated from Template Haskell. Not sure if this is intended behaviour or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8427: GHC accepts invalid program because of EPS poisoning
by GHC 10 Nov '14

10 Nov '14

#8427: GHC accepts invalid program because of EPS poisoning -------------------------------------+------------------------------------- Reporter: errge | 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: GHC accepts Difficulty: Moderate (less | invalid program than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Assume the following setup: - compiling in batch mode (`--make`), - package klassz, module Class contains the class "Class a" and the data "Data", - package klassz, module A contains an (orphan) instance "Class Data", - package main, module AImporter just imports A, - package main, module B imports only Class, but uses the instance (invalidly); then - if package main, module Main imports B, later imports AImporter; then it compiles; - if package main, module Main imports AImporter, later imports B, then it doesn't compile. The attached tgz contains this setup. `diff -u main-docompile main- nocompile` shows that the only difference between the two main directories is the order of import statements. The language definitely doesn't accept compilation success to depend on import ordering, therefore this is a bug. My current understanding is that the issue is that this code should never compile, both mains should be rejected, since module B imports only the class, but not the instance. The issue is that the EPS is only ever increased, never decreased between compilation of different modules in a single batch compilation. This naïve approach causes the instances to be loaded and then never unloaded, so it can be magically found when compiling the invalid B module. The current code can be found in [[GhcFile(compiler/iface/LoadIface.hs)]] line 280. I propose to instead of always loading ifaces into the EPS directly, introduce a proper cache for interfaces, that contains parsed up interface data in a `ModuleEnv`. Then we can start up with an empty EPS at the beginning of the compilation of every unit and quickly merge info from this cache. I guess the majority of time is the file reading IO and the parsing, not the merging of multiple interface files together. I also think that these kind of issues will get more and more prominent as people start to use parallel cabal and ghc, because if compilation of the attached example program is randomly parallelized, then in some cases it will build, some cases it won't. Any opinions, alternative fix ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #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] #8623: Strange slowness when using async library with FFI callbacks
by GHC 06 Nov '14

06 Nov '14

#8623: Strange slowness when using async library with FFI callbacks ------------------------------+-------------------------------------------- Reporter: | Owner: simonmar JohnWiegley | Status: new Type: bug | Milestone: 7.8.1 Priority: normal | Version: 7.6.3 Component: Runtime | Operating System: MacOS X System | Type of failure: Runtime performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I've attached a Haskell and a C file, when compiled as such: ghc -DSPEED_BUG=0 -threaded -O2 -main-is SpeedTest SpeedTest.hs SpeedTestC.c You should find that with 7.4.2, 7.6.3 or a recent build of 7.8, building with SPEED_BUG=0 produces an executable that takes more than a second to run, while building with SPEED_BUG=1 runs very quickly. I've also attached the Core for both scenarios. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8