- ghc-tickets - Haskell.org

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 16 Sep '13

16 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by Edward Z. Yang <ezyang@…>): In [changeset:7520b9775cf57b61208f68a7233449763007ee2f/testsuite]: {{{ #!CommitTicketReference repository="testsuite" revision="7520b9775cf57b61208f68a7233449763007ee2f" T5435 test improvements, see #5435 for details. Signed-off-by: Edward Z. Yang <ezyang(a)mit.edu> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 16 Sep '13

16 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by Edward Z. Yang <ezyang@…>): In [changeset:85a9e2468dc74b9e5ccde0dd61be86219fd323a2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85a9e2468dc74b9e5ccde0dd61be86219fd323a2" Run ctors initializers backwards, see #5435. Signed-off-by: Edward Z. Yang <ezyang(a)mit.edu> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2507: quotation characters in error messages
by GHC 16 Sep '13

16 Sep '13

#2507: quotation characters in error messages -------------------------------------+------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #2811,#3398 -------------------------------------+------------------------------------ Comment (by simonpj): I've been putting up with the same goop in my emacs buffer for some time; thanks for the incantations to add to my `.emacs`, Richard. If this happens a lot, a flag to get rid of the unicode quotes would be a Good Thing. (It could be a static flag I guess.) Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2507#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8296: Patch: new primops for byte range copies ByteArray# <-> Addr#
by GHC 15 Sep '13

15 Sep '13

#8296: Patch: new primops for byte range copies ByteArray# <-> Addr# ------------------------------------+------------------------------------- Reporter: duncan | 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: | ------------------------------------+------------------------------------- Currently we have: * `copyByteArray#` for `ByteArray#` to `MutableByteArray#` * `copyMutableByteArray#` for `MutableByteArray#` to `MutableByteArray#` This patch adds primops for similar cases involving `Addr#`s, that is pointers to pinned or foreign memory. * `copyByteArrayToAddr#` for `ByteArray#` to `Addr#` * `copyMutableByteArrayToAddr#` for `MutableByteArray#` to `Addr#` * `copyAddrToByteArray#` for `Addr#` to `MutableByteArray#` These are not covered by the existing primops of course, and are useful because `ByteArray#`s are a bit special, sometimes being unpinned, and being aligned, and being so primitve/built-in. It's true we could use FFI import of memcpy using the GHC's FFI extension to turn `ByteArray#` into a pointer on the C side. However we don't do that for the existing primops and we're following the same pattern here. (Good reasons for them all to be primops: abstracts the backend/platform better, can take advantage of known allignment and size info). In particular, these primops would be useful in the impl of low level libs like bytestring, text, array, binary etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8296> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 15 Sep '13

15 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by ezyang): Just checked: MingW g++ only generates a single entry in ctors per compilation unit, so they'll get it right. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 15 Sep '13

15 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by ezyang): While fixing this, I found a few more bugs, which are going to be a bit annoying to fix: * The current dynamic test is really a test for loading a static library that happens to be PIC'd. We need to explicitly use addDLL to load a shared library. In fact, we can run a statically linked executable and still load a DLL. * But we can't reuse this test for Windows, because on Linux/Mac OS X, addDLL requires a file extension, while on Windows, we must omit it. So we need two tests here. * Also, on Windows, when I pass `-dynamic` when building the C DLL causes errors like `C:/Users/ezyang/Dev/ghc-init/inplace/mingw/bin/ld.exe: cannot find -lHSbase-4.7.0.0-ghc7.7.20130905`; no problem, just omit the flag. But this is harmless on Linux, so maybe there is a bug here. * With the dynamic test working, I found that actually, `ctors` is reversed, so I need to revert the behavior back to the reversed version. (I had it that way originally, but flipped it due to the buggy test case) * Then I found out that, actually, the order MingW GCC compiles `__attribute__(constructor)` to run is reverse of how it compiles it on Linux. I think this might be a bug, but I couldn't find anywhere where GCC said that they were going to run in any specific order. But this means to keep the test cases consistent, we need to manually lay out the ctors section ourself. No problem, so we need two tests: one for a C compilation, and one for a assembly compilation (with all of the various ways an initializer can be spelled). Obviously this doesn't apply to Mach-O. * Then I wondered, "Well, what happens if there are both ctors and init_array and init; is there a prescribed order these should run in, or is it just the order they show up in the sections?" Well, the dynamic linker will guidance here. * I also tried to induce ordering with priority, but I found out that GCC compiles constructor priority by tacking on a number to the name of the ctors section; I didn't write support for that but maybe I should. * And then Anders pointed out to me that in C++, the order of constructors in the compilation unit is guaranteed, and it seems unlikely GCC would use priority to manage that, so that would be an easy way to find out if MingW GCC was buggy; but if it is buggy, what can we do? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7723: iOS patch no 12: Itimer.c doesn't work on iOS
by GHC 15 Sep '13

15 Sep '13

#7723: iOS patch no 12: Itimer.c doesn't work on iOS --------------------------------------+--------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Other | Architecture: arm Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------- Changes (by StephenBlackheath): * status: new => patch Comment: lukexi has determined that the change we made here is not necessary in the current version of Xcode, so I've prepared & attached a patch to revert it. This is a simple reversion generated like this: {{{ stephen-blackheaths-mac-mini:ghc blackh$ git diff e7817396e8ec5c45689b1c7d6fa852623bb12b33^! > patch stephen-blackheaths-mac-mini:ghc blackh$ cat patch | patch -p1 -R patching file rts/posix/Itimer.c stephen-blackheaths-mac-mini:ghc blackh$ git diff > ios-revert-itimer- change.patch (edit out some junk at the top) }}} Thanks for your patience on this issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7723#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 15 Sep '13

15 Sep '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184, 8235 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by parcs): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5435: GHCi linker should run constructors for linked libraries
by GHC 15 Sep '13

15 Sep '13

#5435: GHCi linker should run constructors for linked libraries -------------------------------------+------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: 7746, 8199 | Related Tickets: #3658 -------------------------------------+------------------------------------ Comment (by simonmar): Files attached, thanks for looking into this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5435#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8184: Compiler panic in the presence of cyclic imports
by GHC 15 Sep '13

15 Sep '13

#8184: Compiler panic in the presence of cyclic imports -----------------------------------+--------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 910 Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- A.hs {{{ #!haskell module A where import {-# SOURCE #-} B data X = X Y }}} B.hs-boot {{{ #!haskell module B where data Y }}} B.hs {{{ #!haskell module B where import A data Y = Y Int Int thing :: X -> a thing (X (Y a b)) = thing (X (Y a b)) }}} C.hs {{{ #!haskell module C where import A import B panic :: Int -> a panic x = thing (X (Y x x)) }}} Now try to compile module C: {{{ $ ghc-stage2 -O C [1 of 4] Compiling B[boot] ( B.hs-boot, B.o-boot ) [2 of 4] Compiling A ( A.hs, A.o ) [3 of 4] Compiling B ( B.hs, B.o ) [4 of 4] Compiling C ( C.hs, C.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130826 for x86_64-unknown-linux): applyTypeToArgs main:B.$wthing{v rsQ} [gid] @ a{tv ivX} [tv] ww_iwm{v} [lid] ww_iwn{v} [lid] a{tv ivX} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I encountered this bug when attempting to compile GHC with GHC -O2 --make. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11