October 2018 - ghc-tickets

[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] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables
by GHC 07 Dec '18

07 Dec '18

#15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: TypeFamilies | 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 following code typechecks on GHC HEAD (8.7+): {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind class C1 a where type T1 a b class C2 a where type T2 a b instance C1 (Maybe a) where type forall a b. T1 (Maybe a) b = b instance C2 (Maybe a) where type forall b. T2 (Maybe a) b = b }}} But ought it to? There is something funny happening in the `C1` instance: it's explicitly quantifying `a`, despite the fact that it had previously been quantified by the class head! Moreover, it appears that you can safely drop the `a` in the explicit `forall`, as the `C2 (Maybe a)` instance witnesses. What does the documentation have to say on this topic? This is all I could find: > When an explicit `forall` is present, all //type// variables mentioned must be bound by the `forall`. I couldn't find anything on the interaction between this feature and associated type families. We should: 1. Decide which of the two programs above should be accepted, and 2. Update the documentation to reflect this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[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

[GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64
by GHC 06 Dec '18

06 Dec '18

#15780: ghc-8.4.4 failed to build on armv7 and aarch64 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-8.4.4 is failing to build for me on Fedora ARM archs (both 32bit and 64bit). https://koji.fedoraproject.org/koji/taskinfo?taskID=30284522 They both fail in the same way: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgMiscClosures.cmm -o rts/dist/build/StgMiscClosures.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.4 for aarch64-unknown-linux): padLiveArgs -- i > regNum ?? CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen/Base.hs:194:27 in ghc:LlvmCodeGen.Base Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [rts/ghc.mk:295: rts/dist/build/HeapStackCheck.o] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9