September 2018 - ghc-tickets

[GHC] #11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers
by GHC 29 Sep '18

29 Sep '18

#11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 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: -------------------------------------+------------------------------------- Running haddock on: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo ( A(..), pattern P ) where data A a = A a pattern P :: a -> A a pattern P a <- A a }}} in GHC 7.10.3 gives haddock documentation for P in the form of: {{{ pattern P :: a -> A a }}} while the haddock in GHC 8.0.1-rc3 gives haddock documentation for P in the form of: {{{ pattern P :: forall a. a -> A a }}} I think GHC/Haddock should not be adding the forall quantifier, and hence think the behaviour in GHC 8.0.1-rc3 is wrong, and the behaviour of GHC 7.10.3 is preferred. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15688: HAVE_LIBNUMA is defined as non-zero even when libnuma does not exist
by GHC 29 Sep '18

29 Sep '18

#15688: HAVE_LIBNUMA is defined as non-zero even when libnuma does not exist ----------------------------------------+--------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I think this is a regression introduced in the last few weeks. The libnuma dependency is checked correctly by the configure script, but somehow when I don't have libnuma installed I still have `HAVE_LIBNUMA` defined as non-zero so I end up with this error: {{{ /usr/bin/x86_64-linux-gnu-ld.gold: error: cannot find -lnuma rts/posix/OSMem.c:368:0: error: error: undefined reference to 'mbind' | 368 | if (RtsFlags.GcFlags.numa) { | ^ rts/posix/OSMem.c:670:0: error: error: undefined reference to 'numa_num_configured_nodes' | 670 | } | ^ rts/posix/OSMem.c:680:0: error: error: undefined reference to 'numa_get_mems_allowed' | 680 | | ^ rts/posix/OSMem.c:670:0: error: error: undefined reference to 'numa_num_configured_nodes' | 670 | } | ^ rts/posix/OSMem.c:685:0: error: error: undefined reference to 'numa_bitmask_free' | 685 | mask = numa_get_mems_allowed(); | ^ rts/posix/OSMem.c:670:0: error: error: undefined reference to 'numa_num_configured_nodes' | 670 | } | ^ collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) utils/ghc-cabal/ghc.mk:56: recipe for target 'utils/ghc- cabal/dist/build/tmp/ghc-cabal' failed }}} Installing libnuma-dev fixes this. Relevant lines in config.log: {{{ CabalHaveLibNuma='False' #define HAVE_LIBNUMA 0 }}} I have no idea why `HAVE_LIBNUMA` is not 0 when compiling the file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15689: s390x builds flood with -Wunused-label warnings
by GHC 29 Sep '18

29 Sep '18

#15689: s390x builds flood with -Wunused-label warnings -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (CodeGen) | Keywords: | Operating System: Linux Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This has been happening for major releases for some time already, but I am finally getting around to reporting this. On s390x when building ghc, huge numbers of -Wunused-label warnings flood gcc output. For example this build: https://koji.fedoraproject.org/koji/taskinfo?taskID=29940997 (note the logs are only kept for 2 weeks) The build.log is 11MB and this is just for compiling less than half of ghc-cabal (270 modules), which generated around 50k unused-label warnings!! So you can imagine the size of a full build. (Well ghc-8.2.2.69.fc29 full build.log was "only" 33MB for s390x vs 8.8MB for x86_64.) For now I patched warnings.mk on s390x to workaround this, but it would be better to fix the root cause I suppose. Here is a small part of the buildlog: {{{ "/usr/bin/ghc" -H32m -O -Wall \ -optc-Wall -optc-fno-stack-protector \ \ -hide-all-packages \ -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package unix \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp /ghc-cabal \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=2,2,0,1 \ -DCABAL_PARSEC \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ libraries/Cabal/Cabal/Distribution/Parsec/Lexer.hs \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/mtl \ -ilibraries/text \ libraries/text/cbits/cbits.c \ -Ilibraries/text/include \ -ilibraries/parsec/src \ \ "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... done. "rm" -f utils/ghc-pkg/dist/build/Version.hs echo "module Version where" >> utils/ghc- pkg/dist/build/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc- pkg/dist/build/Version.hs echo "version = \"8.4.3\"" >> utils/ghc-pkg/dist/build/Version.hs echo "targetOS = \"linux\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetARCH = \"s390x\"" >> utils/ghc-pkg/dist/build/Version.hs [ 1 of 270] Compiling Control.Monad.Cont.Class ( libraries/mtl/Control/Monad/Cont/Class.hs, bootstrapping/Control/Monad/Cont/Class.o ) /tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdp1MonadCont_entry’: /tmp/ghc705e_0/ghc_130.hc:16:1: error: warning: label ‘_c3bA’ defined but not used [-Wunused-label] _c3bA: ^~~~~ | 16 | _c3bA: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘c3bx_entry’: /tmp/ghc705e_0/ghc_130.hc:34:1: error: warning: label ‘_c3bx’ defined but not used [-Wunused-label] _c3bx: ^~~~~ | 34 | _c3bx: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_callCC_entry’: /tmp/ghc705e_0/ghc_130.hc:54:1: error: warning: label ‘_c3bO’ defined but not used [-Wunused-label] _c3bO: ^~~~~ | 54 | _c3bO: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘c3bL_entry’: /tmp/ghc705e_0/ghc_130.hc:72:1: error: warning: label ‘_c3bL’ defined but not used [-Wunused-label] _c3bL: ^~~~~ | 72 | _c3bL: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘s38I_entry’: /tmp/ghc705e_0/ghc_130.hc:98:1: error: warning: label ‘_c3ca’ defined but not used [-Wunused-label] _c3ca: ^~~~~ | 98 | _c3ca: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘s38J_entry’: /tmp/ghc705e_0/ghc_130.hc:125:1: error: warning: label ‘_c3cf’ defined but not used [-Wunused-label] _c3cf: ^~~~~ | 125 | _c3cf: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT1_entry’: /tmp/ghc705e_0/ghc_130.hc:152:1: error: warning: label ‘_c3ck’ defined but not used [-Wunused-label] _c3ck: ^~~~~ | 152 | _c3ck: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘s38M_entry’: /tmp/ghc705e_0/ghc_130.hc:181:1: error: warning: label ‘_c3cx’ defined but not used [-Wunused-label] _c3cx: ^~~~~ | 181 | _c3cx: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorTzuzdcp1MonadCont_entry’: /tmp/ghc705e_0/ghc_130.hc:206:1: error: warning: label ‘_c3cA’ defined but not used [-Wunused-label] _c3cA: ^~~~~ | 206 | _c3cA: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘s38Q_entry’: /tmp/ghc705e_0/ghc_130.hc:235:1: error: warning: label ‘_c3cO’ defined but not used [-Wunused-label] _c3cO: ^~~~~ | 235 | _c3cO: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘s38P_entry’: /tmp/ghc705e_0/ghc_130.hc:257:1: error: warning: label ‘_c3cV’ defined but not used [-Wunused-label] _c3cV: ^~~~~ | 257 | _c3cV: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContErrorT_entry’: /tmp/ghc705e_0/ghc_130.hc:285:1: error: warning: label ‘_c3cZ’ defined but not used [-Wunused-label] _c3cZ: ^~~~~ | 285 | _c3cZ: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘s38W_entry’: /tmp/ghc705e_0/ghc_130.hc:323:1: error: warning: label ‘_c3dj’ defined but not used [-Wunused-label] _c3dj: ^~~~~ | 323 | _c3dj: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘s38X_entry’: /tmp/ghc705e_0/ghc_130.hc:350:1: error: warning: label ‘_c3do’ defined but not used [-Wunused-label] _c3do: ^~~~~ | 350 | _c3do: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptT1_entry’: /tmp/ghc705e_0/ghc_130.hc:377:1: error: warning: label ‘_c3dt’ defined but not used [-Wunused-label] _c3dt: ^~~~~ | 377 | _c3dt: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘s38Z_entry’: /tmp/ghc705e_0/ghc_130.hc:411:1: error: warning: label ‘_c3dG’ defined but not used [-Wunused-label] _c3dG: ^~~~~ | 411 | _c3dG: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘ControlziMonadziContziClass_zdfMonadContExceptTzuzdcp1MonadCont_entry’: /tmp/ghc705e_0/ghc_130.hc:435:1: error: warning: label ‘_c3dJ’ defined but not used [-Wunused-label] _c3dJ: ^~~~~ | 435 | _c3dJ: | ^ /tmp/ghc705e_0/ghc_130.hc: In function ‘s392_entry’: /tmp/ghc705e_0/ghc_130.hc:462:1: error: warning: label ‘_c3dX’ defined but not used [-Wunused-label] _c3dX: ^~~~~ | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent)
by GHC 29 Sep '18

29 Sep '18

#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: Architecture: Unknown/Multiple | Operating System: Difficulty: Project (more than a week) | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: 635, 7353 | None/Unknown | Test Case: | Blocking: ----------------------------------------------+---------------------------- This is mainly a reference discussion ticket. libuv (https://github.com/joyent/libuv) is a lightweight library which allows asynchronous IO across OpenBSD, Linux, Darwin, Windows etc by utilizing the fastest implementation on each system (epoll, kqueue, IOCP, event ports). These specialized IO polling methods are '''much''' faster on their respective platforms than just using select() like the RTS currently does. Additionally, it also provides cross platform threads, mutex, condition vars, terminal input/output and term settings w/ cross platform ANSI escape code handling, thread pools, cross platform HRC's etc. It's currently significantly faster than libevent and slightly faster than libev (and no doubt faster than rolling our own stuff). Because it's maintained and utilized heavily by Node.js it's in extremely active and maintained development. Rewriting a portion of the RTS to utilize libuv would have the following benefits; * We could ditch basically all of our platform specific code. Everything under rts/win32 and rts/posix, except the SEH stuff, could be deleted. * libuv is tuned for speed on each platform. This would be an optimization to all our async IO stuff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #15686: Different results depending on if the code was compiled with or without optimizations
by GHC 28 Sep '18

28 Sep '18

#15686: Different results depending on if the code was compiled with or without optimizations -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The test case consists of three files: Main.hs {{{#!hs {-# LANGUAGE OverloadedLists, BangPatterns #-} {-# OPTIONS_GHC -ddump-simpl -dsuppress-all -ddump-to-file #-} module Main where import Mesh import Vec import Control.Exception main :: IO () main = do !_ <- evaluate $ toBondForce (Particle {_position = Vec {_vecX = 0.0, _vecY = -20.0}, _mass = 10.0, _velocity = Vec {_vecX = 0.0, _vecY = 3.0}}) (Particle {_position = Vec {_vecX = 20.0, _vecY = -20.0}, _mass = 10.0, _velocity = Vec {_vecX = 0.0, _vecY = 0.0}}) (FixedDistanceBond {_distance = 20.0, _strength = 0.5}) return () }}} Vec.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, FunctionalDependencies #-} module Vec where data Vec = Vec { _vecX :: {-# UNPACK #-}!Double, _vecY :: {-# UNPACK #-}!Double } deriving (Eq, Ord, Read, Show) liftVec :: (Double -> Double -> Double) -> Vec -> Vec -> Vec liftVec f (Vec x y) (Vec z w) = Vec (f x z) (f y w) {-# INLINE liftVec #-} instance Num Vec where fromInteger i = Vec (fromInteger i) (fromInteger i) (+) a b = liftVec (+) a b {-# INLINE (+) #-} (*) a b = liftVec (*) a b {-# INLINE (*) #-} (-) a b = liftVec (-) a b {-# INLINE (-) #-} signum (Vec x y) = Vec (signum x) (signum y) abs (Vec x y) = Vec (abs x) (abs y) instance Fractional Vec where fromRational r = Vec (fromRational r) (fromRational r) (/) = liftVec (/) {-# INLINE (/) #-} fromDouble :: Double -> Vec fromDouble x = Vec x x {-# INLINE fromDouble #-} class Vector2D v where norm :: v -> Double normalize :: v -> v distance :: v -> v -> Double dot :: v -> v -> Double project :: v -> v -> v instance Vector2D Vec where norm (Vec x y) = sqrt (x ** 2 + y ** 2) {-# INLINE norm #-} normalize v@(Vec x y) = Vec (x / n) (y / n) where n = norm v {-# INLINE normalize #-} distance v1 v2 = norm (v2 - v1) {-# INLINE distance #-} dot (Vec x y) (Vec z w) = x * z + y * w {-# INLINE dot #-} project tgt v = normTgt * realToFrac (dot normTgt v) where normTgt = normalize tgt {-# INLINE project #-} }}} Mesh.hs {{{#!hs {-# LANGUAGE Strict, RecordWildCards, TemplateHaskell, BangPatterns #-} {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts, FunctionalDependencies #-} {-# OPTIONS_GHC -ddump-simpl -dsuppress-all -ddump-to-file #-} module Mesh where import Vec import Debug.Trace data Particle = Particle { _position :: {-# UNPACK #-}!Vec , _mass :: {-# UNPACK #-}!Double , _velocity :: {-# UNPACK #-}!Vec } deriving (Eq, Ord, Read, Show) data Bond = FixedDistanceBond { _distance :: {-# UNPACK #-}!Double , _strength :: {-# UNPACK #-}!Double } deriving (Eq, Ord, Read, Show) toBondForce :: Particle -> Particle -> Bond -> Vec toBondForce Particle{..} !p2 FixedDistanceBond{..} = traceShow (show (Mesh._position p2, dir)) $ dir * fromDouble (actualDist - _distance) * fromDouble _strength - project dir velDiff * 0.1 where posDiff = Mesh._position p2 - _position dir = normalize posDiff actualDist = norm posDiff velDiff = _velocity - Mesh._velocity p2 }}} Compiling Main.hs with optimizations (-O2) and running the program produces the output "(Vec {_vecX = 20.0, _vecY = 0.0},Vec {_vecX = 1.0, _vecY = 0.0})" while compiling without optimizations produces "(Vec {_vecX = 20.0, _vecY = -20.0},Vec {_vecX = 1.0, _vecY = 0.0})" which is correct. Further observations: Changing `traceShow (show (Mesh._position p2, dir))` to `traceShow (show (Mesh._position p2))` makes the code perform correctly even with optimizations. The core output looks correct to me even with optimizations. I can't test with other GHC versions on Windows, but I know I can't reproduce this with GHC 8.4 on Linux and I think it also doesn't reproduce with 8.2 on Linux. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15683: coerce fails for Coercible type families
by GHC 28 Sep '18

28 Sep '18

#15683: coerce fails for Coercible type families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 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: -------------------------------------+------------------------------------- I want to bring attention to this [https://www.reddit.com/r/haskell/comments/9io4xw/coercing_type_families_whe… reddit post] that boils down to {{{#!hs type family X a type instance X Int = String type instance X Bool = String data T a = T (X a) }}} but not being able to coerce {{{#!hs coerce :: T Int -> T Bool }}} This gives the error “Couldn't match type ‘`Int`’ with ‘`Bool`’ arising from a use of ‘`coerce`’”. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is
by GHC 28 Sep '18

28 Sep '18

#14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC warns on this program: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -Wall #-} module Bug where import Data.Kind import Data.Void data SBool (z :: Bool) where SFalse :: SBool 'False STrue :: SBool 'True type family F (b :: Bool) (a :: Type) :: Type where F 'True a = a F 'False _ = Void dispatch :: forall (b :: Bool) (a :: Type). SBool b -> F b a -> a dispatch STrue x = x dispatch SFalse x = case x of {} }}} {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:22:21: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ :: F b a | 22 | dispatch SFalse x = case x of {} | ^^^^ }}} This warning is incorrect, as `x` is of type `F 'False a`, or `Void`, in that case alternative. Curiously, if you ascribe either the pattern for `x`: {{{#!hs dispatch SFalse (x :: F 'False a) = case x of {} }}} Or the case scrutinee: {{{#!hs dispatch SFalse x = case x :: F 'False a of {} }}} Then the warning goes away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14813> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #5467: Template Haskell: support for Haddock comments
by GHC 28 Sep '18

28 Sep '18

#5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5467#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15682: evolve / improve Native Gen Format in Format.hs (especially in context of post simd cleanup)
by GHC 27 Sep '18

27 Sep '18

#15682: evolve / improve Native Gen Format in Format.hs (especially in context of post simd cleanup) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Currently `GlobalReg` represents the STG machine registers. However, some STG registers get aliased to the same machine registers (e.g. `FloatReg 1` and `DoubleReg 1`; see `Note [Overlapping global registers]`). To make matters worse, we assume that we can always determine the `CmmType` of a `GlobalReg`. However, in the case of SIMD registers this isn't necessarily the case (e.g. a XMM register may contain 1 or 2 double-precision floats, or 1, 2, 4, 8, or 16 integers). for ghc/compiler/nativeGen/Format.hs {{{ data Format = II8 | II16 | II32 | II64 | FF32 | FF64 | FF80 deriving (Show, Eq) }}} currently this is meant to "encode" both physical bit size AND which register class the value is. we also have the issue that this register class distinction stops being true once simd integer operations. this gets worse with simd once we want to track (perhaps?) the size / number of elements used in the xmm/ymm/zmm / arm simd vectors. perhaps also: signedness? this actually also relates to how GlobalRegisters and Format are related! is GlobalRegisters meant for STG machine vs native Machine? this intersects with ABI questions. Plus we currently have eg Float and Double which are different logically/semantically, BUT the same registers in most native machine architectures -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15682> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12178: Allow inline pragmas on pattern synonyms
by GHC 27 Sep '18

27 Sep '18

#12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Richard observes that it might be useful to allow inline pragmas to refer to pattern synonyms to ensure that the matcher is inlined. The main question to resolve is whether `{-# INLINE P #-}` means to inline just the matcher, just the builder or both. It seems that without more fine grained control then the pragma should cause both the matcher and builder to be inline but I am not certain about this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11