September 2018 - ghc-tickets

[GHC] #12126: Bad error messages for SPECIALIZE pragmas
by GHC 09 Dec '18

09 Dec '18

#12126: Bad error messages for SPECIALIZE pragmas -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Specialize, | Operating System: Unknown/Multiple ErrorMessages | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When playing with SPECIALIZE pragmas, I've encountered one large problem with the error messages, and two minor ones. 1. Given a function with a `Num` constraint, applying `SPECIALIZE` at a non-function type triggers defaulting incorrectly; the code {{{#!hs f1 :: Num a => a -> a f1 x = x + x {-# SPECIALIZE f1 :: Bool #-} }}} produces the error {{{ …/Test1.hs:5:1: error: • Couldn't match expected type ‘Integer -> Integer’ with actual type ‘Bool’ • In the SPECIALISE pragma {-# SPECIALIZE f1 :: Bool #-} }}} (This is in the attached file `Test1.hs`.) 2. Given a function, applying `SPECIALIZE` at a well-formed type without the looked-for instance produces an error with some extra text (the first line ends with "a SPECIALISE pragma for ‘f2’", even though this is repeated on the next line); the code {{{#!hs f2 :: Num a => a -> a f2 x = x + x {-# SPECIALIZE f2 :: Bool -> Bool #-} }}} produces the error {{{ …/Test2.hs:5:1: error: • No instance for (Num Bool) a SPECIALISE pragma for ‘f2’ • In the SPECIALISE pragma {-# SPECIALIZE f2 :: Bool -> Bool #-} }}} (This is in the attached file `Test2.hs`.) 3. This is minor, but: both of these error messages talk about a `SPECIALISE` pragma when I wrote a `SPECIALIZE` pragma. Even more so, case is not preserved in the quoted pragma; if I provide a {{{#!hs {-# specialize … #-} }}} pragma, the error message ends with {{{ • In the SPECIALISE pragma {-# SPECIALIZE … #-}`. }}} even though that isn't what I wrote. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13165: Speed up the RTS hash table
by GHC 09 Dec '18

09 Dec '18

#13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS hash table is rather slow. Every lookup involves at least one indirect call (to get a hash code). It also uses separate chaining, which is itself slow. Until recently, this didn't really matter, since the RTS hash table wasn't used for anything particularly performance critical other than `StablePtr` operations. However, it has since become the bottleneck when compacting with sharing, to the point that compacting without sharing is around 10x faster and is thus the default. Fortunately, there are easy ways to make the hash table faster. These include: - Use linear probing instead of separate chaining. - Specialize for the case of pointer keys - Don't use indirect calls for hashing - Use a fast, universal hash function for pointers. - Use SSE instructions where available to do fast searches. - Minimize the number of indirections in the use of the table. In both the case of the StablePtr table and that of compact regions, the keys of the table are not GC pointers, but the values are, so there needs to be a way to ensure that the GC handles the table correctly -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags
by GHC 08 Dec '18

08 Dec '18

#14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# LANGUAGE CApiFFI #-} {-# OPTIONS_GHC -optc-O3 #-} module M where foreign import capi unsafe "stdlib.h exit" c_exit :: Int -> IO () }}} However, the `-optc-O3` flag has no effect, unless `ghc` is called without any `-O` flags, or with `-O0`. Here's the resulting C compiler invocations for different `-O` flags: {{{ $ ghc -fforce-recomp -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14023_0/ghc_2.c -o /tmp/ghc14023_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O0 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14045_0/ghc_2.c -o /tmp/ghc14045_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O1 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14073_0/ghc_2.c -o /tmp/ghc14073_0/ghc_3.s -Wimplicit -S -O -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O2 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14093_0/ghc_2.c -o /tmp/ghc14093_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O3 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14119_0/ghc_2.c -o /tmp/ghc14119_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} To summarise, here's the resulting effective `-O`-level passed to `gcc`: ||= GHC invocation =||= GCC invocation =||= Effective C `-O`-level =|| || `ghc` || `gcc -O3` || `-O3` || || `ghc -O0` || `gcc -O3` || `-O3` || || `ghc -O1` || `gcc -O3 -O1` || `-O1` || || `ghc -O2` || `gcc -O3 -O2` || `-O2` || || `ghc -O3` || `gcc -O3 -O2` || `-O2` || Consequently, the only way to have C code compiled with `-O3` is to force GHC into `-O0` mode; this is obviously not ideal, as it easily kills any benefit you'd gain from passing `-O3` to the C compiler... ;-) I see a few alternatives on how to resolve this: 1. Have GHC recognise `-optc-O[0-9]` and suppress automatically injecting any `-O<n>` of its own 2. Have GHC inject its automatic `-O`-flags before user-provided `-optc` flags 3. Have GHC inject `-optc` flags as late as possible on the C compiler command-line 4. Implement a new variant of the `-optc` flag which injects its flags as late as possible on the C compiler command-line -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o
by GHC 08 Dec '18

08 Dec '18

#15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a file `foo.hs` is compiled and has `foo.hi` and `foo.o` lying around, then the ''second time'' `foo.hs` is loaded in GHCi (with `set +c` set), even with `:load *foo.hs` to force interpretation, the file loads fine but the type information is not collected, as if `:set +c` wasn't in effect. This means that commands like `:type-at` and `:all-types` work as if they had the old file. I expect that given `:set +c`, a successful `:load *foo.hs` would always collect the new type information for `foo.hs`. == Steps to reproduce The contents of `setc.hs` is the following, although it's pretty surely irrelevant. {{{#!hs module SetC where }}} The following is a GHCi session showing the problem (my comments are marked with `--`). {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set +c -- dir /b is basically ls on Windows Prelude> :! dir /b setc* setc.hs -- When I load a file multiple times it works fine Prelude> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected -- But if I compile it *SetC> :! ghc -c setc.hs *SetC> :! dir /b setc* setc.hi setc.hs setc.o -- The first time the type info is collected *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected -- But then it is no longer collected *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. -- NOT collected! *SetC> }}} Then if I change `setc.hs` to add some expressions: {{{#!hs module SetC where x :: Int x = 1 }}} {{{ *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. -- NOT collected! -- The new definition is loaded fine *SetC> x 1 -- But the type information is not there (no output!) *SetC> :all-types *SetC> -- Then if I delete the compiled .hi and .o files *SetC> :! del setc.hi setc.o -- ... and load again, :all-types suddenly works *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected *SetC> :all-types setc.hs:(4,1)-(4,2): GHC.Types.Int setc.hs:(4,5)-(4,6): GHC.Types.Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15130: Hadrian doesn't rebuild changed `CoreUtils.hs`
by GHC 08 Dec '18

08 Dec '18

#15130: Hadrian doesn't rebuild changed `CoreUtils.hs` --------------------------------------+--------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- When compiling stage2 with Hadrian, freezing stage1 causes changes to `CoreUtils.hs` to be ignored, and `CoreUtils.hs` not being recompiled. The following steps should reproduce the problem: 1. Make a debug build with Hadrian: `./hadrian/build.sh --flavour=Devel2` 2. Rebuild with freeze1: `./hadrian/build.sh --flavour=Devel2 --freeze1` 3. Edit `compiler/coreSyn/CoreUtils.hs`, adding some change that is easily detected in the output 4. Rebuild with freeze1: `./hadrian/build.sh --flavour=Devel2 --freeze1` 5. Observe how `CoreUtils` does not appear in the list of modules Hadrian is compiling, and how changes to that file do not end up in the stage2 compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14251: LLVM Code Gen messes up registers
by GHC 08 Dec '18

08 Dec '18

#14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.3 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Due to the way the LLVM Code Gen generates Function Singnatures, it is possible to end up mixed up registers. A slightly adapted T8064 {{{#!hs {-# LANGUAGE MagicHash, BangPatterns #-} module Main where import GHC.Exts {-# NOINLINE f #-} f :: (Int# -> Float# -> Double# -> Float# -> Double# -> String) -> String f g = g 3# 4.0# 5.0## 6.0# 6.9## ++ " World!" {-# NOINLINE p #-} p :: Int# -> Float# -> Double# -> Float# -> Double# -> String p i j k l m = "Hello" {-# NOINLINE q #-} q :: Int# -> Int# -> Float# -> Double# -> Float# -> Double# -> String q _ i j k l m = "Hello " ++ show (F# l) ++ " " ++ show (D# m) {-# NOINLINE r #-} r :: Int# -> Float# -> Double# -> Float# -> Double# -> String r i = let !(I# z) = length [I# 1# .. I# i] in \j k l m -> p z j k l m -- ghc won't eta-expand around the length, because it has unknown cost main = do putStrLn (f p) -- fast call putStrLn (f r) -- slow call: function but wrong arity let g = last [q 1#] putStrLn (f g) -- slow call: thunk }}} will produce the following results: {{{ ../inplace/bin/ghc-stage1 -fllvm -fforce-recomp T6084.hs -O2 -o T6084-llvm && ./T6084-llvm [1 of 1] Compiling Main ( T6084.hs, T6084.o ) Linking T6084-llvm ... Hello World! Hello World! Hello 4.0 5.0 World! ../inplace/bin/ghc-stage1 -fasm -fforce-recomp T6084.hs -O2 -o T6084-asm && ./T6084-asm [1 of 1] Compiling Main ( T6084.hs, T6084.o ) Linking T6084-asm ... Hello World! Hello World! Hello 6.0 6.9 World! }}} The underlying reason is that (at least for X86_64) the Float and Double registers alternate. The llvm code gen creates function signatures based on the live registers (instead of all). For `q` only the last Float and Double register are `live`. However when calling `q` we pass `f1: Float -> d1: Double -> f2: Float -> d2: Double`. `f2` and `d2` are silently ignored, and in the function body, we now have `f2 <- f1` and `d2 <- d1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #13786: GHC panic on Mac OS X with "cabal repl" / "stack repl" on GHC 8.0.2 and 7.8.3
by GHC 07 Dec '18

07 Dec '18

#13786: GHC panic on Mac OS X with "cabal repl" / "stack repl" on GHC 8.0.2 and 7.8.3 -------------------------------------+------------------------------------- Reporter: ppelleti | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using [https://github.com/ppelleti/hs-mercury-api this package], I tried doing "stack repl" with GHC 8.0.2: {{{ whiteandnerdy:hs-mercury-api ppelleti$ stack repl The following GHC options are incompatible with GHCi and have not been passed to it: -threaded * * * * * * * * The main module to load is ambiguous. Candidates are: 1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr- firmware.hs 2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs 3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs 4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs 5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs 6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs You can specify which one to pick by: * Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr- firmware * Specifying what the main is e.g. stack ghci --main-is mercury-api:exe :tmr-firmware * Choosing from the candidate above [1..6] * * * * * * * * Specify main module to use (press enter to load none): 4 Loading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs Configuring GHCi with the following packages: mercury-api GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib Expected in: flat namespace in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This bug appears to have been around a while, because it also happens with GHC 7.8.3: {{{ whiteandnerdy:hs-mercury-api ppelleti$ cabal repl Preprocessing library mercury-api-0.1.0.0... GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package text-1.2.2.1 ... linking ... done. Loading package hashable-1.2.6.0 ... linking ... done. Loading package unordered-containers-0.2.8.0 ... linking ... done. Loading package clock-0.7.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package ansi-terminal-0.6.2.3 ... linking ... done. Loading object (static) dist/build/cbits/api/tmr_strerror.o ... done Loading object (static) dist/build/cbits/api/tmr_param.o ... done Loading object (static) dist/build/cbits/api/hex_bytes.o ... done Loading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib Expected in: flat namespace in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm using Mac OS X 10.9.5: {{{ whiteandnerdy:hs-mercury-api ppelleti$ uname -a Darwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15263: Fuse zipWith3
by GHC 06 Dec '18

06 Dec '18

#15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was surprised to discover that `zipWith3` has no `RULES` associated with it to aid fusion. Can we add these? I have no idea what I'm doing, but would this substitution work: {{{ {-# RULES "zipWith3" zipWith3 f a b c = zipWith id (zipWith f a b) c #-} }}} Those who know what they're doing will likely devise a better strategy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15639: Surprising failure combining QuantifiedConstraints with Coercible
by GHC 06 Dec '18

06 Dec '18

#15639: Surprising failure combining QuantifiedConstraints with Coercible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't understand what's going wrong here. {{{#!hs -- Fishy.hs {-# language RankNTypes, QuantifiedConstraints, RoleAnnotations #-} module Fishy (Yeah, yeahCoercible) where import Data.Coerce data Yeah_ a = Yeah_ Int newtype Yeah a = Yeah (Yeah_ a) type role Yeah representational yeahCoercible :: ((forall a b. Coercible (Yeah a) (Yeah b)) => r) -> r yeahCoercible r = r -- Fishy2.hs module Fishy2 where import Fishy import Data.Type.Coercion import Data.Coerce yeah :: Coercion [Yeah a] [Yeah b] yeah = yeahCoercible Coercion }}} I get {{{ Fishy2.hs:8:22: error: • Couldn't match representation of type ‘a’ with that of ‘b’ arising from a use of ‘Coercion’ ‘a’ is a rigid type variable bound by the type signature for: yeah :: forall a b. Coercion [Yeah a] [Yeah b] at Fishy2.hs:7:1-34 ‘b’ is a rigid type variable bound by the type signature for: yeah :: forall a b. Coercion [Yeah a] [Yeah b] at Fishy2.hs:7:1-34 • In the first argument of ‘yeahCoercible’, namely ‘Coercion’ In the expression: yeahCoercible Coercion In an equation for ‘yeah’: yeah = yeahCoercible Coercion • Relevant bindings include yeah :: Coercion [Yeah a] [Yeah b] (bound at Fishy2.hs:8:1) | 8 | yeah = yeahCoercible Coercion | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity
by GHC 06 Dec '18

06 Dec '18

#15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This bug report is about the incorrect result not the poor performance.) Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd64): {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e100000000 :: Double Infinity (5.70 secs, 68,552 bytes) Prelude> 1e1000000000 :: Double 0.0 (69.35 secs, 60,088 bytes) }}} Writing `10^` instead of `1e` completes almost instantly with the correct result (`Infinity`) in both cases. More precisely, {{{ Prelude> 1e646457008 :: Double Infinity (40.80 secs, 64,272 bytes) Prelude> 1e646457009 :: Double 0.0 (40.46 secs, 60,088 bytes) }}} Note: {{{#!hs (floor $ 2^31 / logBase 2 10 + 16) == 646457009 }}} This vague numerology makes me think something C `int`-related is overflowing somewhere (GMP? integer-gmp? GHC?). Standalone test program: {{{#!hs main = do print 1e646457008 print 1e646457009 }}} Interestingly, it doesn't occur, or at least not near the same threshold, in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes bisecting the exact threshold on i686 not something I want to take on (though if someone writes some code that can do it programmatically I'd be happy to run it overnight if it would help). {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e646457008 :: Double Infinity (415.26 secs, 17,908 bytes) Prelude> 1e646457009 :: Double Infinity (417.66 secs, 17,820 bytes) Prelude> 1e746457298 :: Double Infinity (490.00 secs, 17,820 bytes) Prelude> 1e1000000000 :: Double GNU MP: Cannot allocate memory (size=419438600) Aborted $ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16