August 2013 - ghc-tickets

Re: [GHC] #8113: Cannot override ghci builtin commands with :def[!]
by GHC 29 Aug '13

29 Aug '13

#8113: Cannot override ghci builtin commands with :def[!] -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Easy (less than 1 Test Case: | hour) ghci/scripts/T8113 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by rwbarton): I got caught off guard by hvr's change because I had a ghci macro `:tsu` I'd forgotten about which meant that every time I tried to `:t` something I got a weird error. Took me a while to figure out that it was my `.ghci` file at fault. I suppose I could learn to use `:type` or `::t` but I'd prefer not to have to. And I don't want to have to give up macros starting with t, and every other single-letter ghci command that I use. Can we please have macros override built-in commands, but still have `:t` expand to `:type`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8113#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 29 Aug '13

29 Aug '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): There was an old bug #4304 which SimonM closed regarding this. Personally I'd rather see the flag go than keep the warning forever and ever, because the fix is extremely simple. I have a patch that implements this which I'm validating on my tree now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7473: getModificationTime gives only second-level resolution
by GHC 29 Aug '13

29 Aug '13

#7473: getModificationTime gives only second-level resolution ----------------------------------------+---------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/directory | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by redneb): I cannot reproduce that. In my experiments, `GetFileAttributesEx` works as expected. To test this I ran the following command (in a cygwin shell so that I can use sleep): {{{ #!sh echo 1 >> test.txt && ./modtime test.txt && sleep 0.1 && echo 2 >> test.txt && ./modtime test.txt }}} The output was: {{{ test.txt: 2013-08-29 00:30:02.4667839 UTC test.txt: 2013-08-29 00:30:02.5869567 UTC }}} As you can see that's full 100ns resolution. And here's the code for the modtime program I used above: {{{ #!haskell import System.Win32 import Data.Time () import Data.Time.Clock.POSIX import System.Environment main :: IO () main = getArgs >>= mapM_ printModTime printModTime :: String -> IO () printModTime path = do fad <- getFileAttributesExStandard path let FILETIME ft = fadLastWriteTime fad mt = posixSecondsToUTCTime (fromIntegral (ft - win32_epoch_adjust) / 10000000) putStrLn (path ++ ": " ++ show mt) win32_epoch_adjust :: DDWORD win32_epoch_adjust = 116444736000000000 }}} This requires my patches [1] for win32 to compile. [1] https://github.com/haskell/win32/pull/10 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7473#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7367: Optimiser / Linker Problem on amd64
by GHC 28 Aug '13

28 Aug '13

#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by rwbarton): wurmli, what's the matter with it? "800,100,272 bytes allocated in the heap" means that the total size of all the allocations done over the course of the program is 800,100,272 bytes. That's the expected size of 20 million (Int, Int) pairs which share their second field (`n`), plus a small amount of other stuff. It doesn't have anything to do with the size of the heap at any given time. The maximum heap size is shown separately: "50,520 bytes maximum residency" which is quite reasonable. Similarly your original program does not ever occupy 10 GB of heap at a time. If you look at the process in top you will see a memory usage close to "47,184 bytes maximum residency" (well probably more like a couple MB, to hold the program image, but not anything near 10 GB). I have no idea why the original program timed out on the language benchmark machines, but it wasn't due to it allocating 10 GB sequentially. Allocation of short-lived objects is very cheap. But it is not free, and this discussion has been about why current GHC produces a program that allocates a lot when GHC 7.4 did not. Eliminating the large amount of allocation might reduce the runtime by a few percent or so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7957: -ddump-minimal-imports should honour -outputdir
by GHC 28 Aug '13

28 Aug '13

#7957: -ddump-minimal-imports should honour -outputdir -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7957#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7957: -ddump-minimal-imports should honour -outputdir
by GHC 28 Aug '13

28 Aug '13

#7957: -ddump-minimal-imports should honour -outputdir -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Looks like it's done. Thank you herbert! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7957#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5188: Runtime error when allocating lots of memory
by GHC 28 Aug '13

28 Aug '13

#5188: Runtime error when allocating lots of memory ---------------------------------+--------------------------- Reporter: knyblad | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Changes (by rwbarton): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5188#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5188: Runtime error when allocating lots of memory
by GHC 28 Aug '13

28 Aug '13

#5188: Runtime error when allocating lots of memory ---------------------------------+--------------------------- Reporter: knyblad | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by rwbarton): The first attached patch checks for integer overflow in the computation of `size` in `osGetMBlocks`. With the patch the example program now exits with this message: {{{ pow: out of memory (requested 4096 MBlocks) }}} The second and third patches are extra checks for overflow when converting between integer types in `my_mmap` and `osGetMBlocks`. AFAIK it *should* always be the case that `W_` >= `nat` and that `size_t` >= `W_` on platforms supported by GHC; but on any system where that is the case, the C compiler can eliminate the tests anyways, so I recommend including both tests. Oops, I see there is a missing `%` in the middle patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5188#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7473: getModificationTime gives only second-level resolution
by GHC 28 Aug '13

28 Aug '13

#7473: getModificationTime gives only second-level resolution ----------------------------------------+---------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/directory | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@… (added) Comment: The {{{GetFileAttributesEx}}} function on Windows returns resolution of 100ns, but if you repeatedly write to a file and read modification times under Windows you will see it change in granularity of 1s, as the Windows NTFS file system omits any modification time update if one was already done in the last second. As a result, {{{getModificationTime}}} isn't going to have the resolution you are after on Windows, even with the new function. I have verified this experimentally on both a Windows XP laptop and a Windows Vista desktop. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7473#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7500: GHC: internal error: getMBlock: mmap: Operation not permitted
by GHC 28 Aug '13

28 Aug '13

#7500: GHC: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Changes (by rwbarton): * status: new => patch Comment: I dug into this some more. In the kernel I have installed (Debian 2.6.32-5-686), mmap selects an address for the new mapping based on the hint address and the process's current mappings, but without regard to `mmap_min_addr`. Then, if the address selected was less than `mmap_min_addr`, mmap may return EPERM, depending on the SELinux configuration. I believe the same applies to at least all 32-bit x86 Linux versions. In my kernel, it doesn't seem that trying to mmap again with no hint address can ever help Linux find the unmapped areas above `mmap_min_addr`. I'm not sure whether this holds in modern Linux, which has an entirely new algorithm for finding unmapped areas. But in any case, it is easy enough to try a second mmap with no hint address. I've attached a patch which, on Linux, tries to do a second mmap if it receives EPERM, and treats EPERM as an out-of-memory condition. With the patch, the example program allocates 2929 MB and then exits with the message {{{ part.hs: out of memory (requested 1048576 bytes) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7500#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0