August 2014 - ghc-tickets

[GHC] #8586: internal error: evacuate(static): strange closure type 5189
by GHC 22 Jan '16

22 Jan '16

#8586: internal error: evacuate(static): strange closure type 5189 ----------------------------+------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: crash | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------- I cannot reproduce this reliably, but it happened once. Here’s what I did: * Install Yesod * Scaffold a blank Yesod project with no DB * Run GHCi * :l Foundation.hs * :info AForm Output: {{{ newtype AForm m a = AForm {unAForm :: (HandlerSite m, [Text]) -> Maybe (Env, FileEnv) -> Ints -> m (FormResult a, [FieldView (HandlerSite m)] -> [FieldView (HandlerSite m)], Ints, Enctype)} -- Defined in `Yesod.Form.Types' instance Monad m => Functor (AForm m) -- Defined in `Yesod.Form.Types' instance (Monad m, Monoid a) => Monoid (AForm m a) -- Defined in `Yesod.Form.Types' instance MonadTransghc.exe: internal error: evacuate(static): strange closure type 5189 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} (P.S. I chose 'x86' for the Architecture because it’s running as 32-bit, but I’m actually using 64-bit Windows.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8605: Alternative, guard-like syntax for view patterns
by GHC 22 Jan '16

22 Jan '16

#8605: Alternative, guard-like syntax for view patterns ------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Implement the alternative syntax for view patterns described on the ViewPatternsAlternative wiki page -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8605> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8907: Un-zonked kind variable passes through type checker
by GHC 22 Jan '16

22 Jan '16

#8907: Un-zonked kind variable passes through type checker -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- I have this module: {{{ {-# LANGUAGE PolyKinds #-} module Bug where data Poly a }}} Now, I say this: {{{ > ghc Bug.hs -fforce-recomp -dppr-debug -fprint-explicit-foralls -ddump-tc }}} The following is produced: {{{ [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) TYPE SIGNATURES TYPE CONSTRUCTORS main:Bug.Poly{tc rn2} :: k{tv ao6} [sk] -> ghc-prim:GHC.Prim.*{(w) tc 34d} data Poly{tc} (k::ghc-prim:GHC.Prim.BOX{(w) tc 347}) (a::k) No C type associated Roles: [nominal, phantom] RecFlag NonRecursive, Not promotable = FamilyInstance: none COERCION AXIOMS Dependent modules: [] Dependent packages: [base, ghc-prim, integer-gmp] ==================== Typechecker ==================== }}} My concern is the `[sk]` that appears after the kind variable `k_ao6`. It would appear that a ''skolem'' type variable passes out of the type- checker and is used as the binder for polymorphic kind of `Poly`. Should this get zonked somewhere? My guess is that there is no way to get this apparent misbehavior to trigger some real failure, given that the variable will be substituted away before much else happens. Yet, when I saw a skolem appear in a similar position after modifying the type-checker, I was sure I had done something wrong somewhere. So, is this intended or accidental behavior? If accidental, should we be scared? If we needn't be scared, I'm happy to close this as wontfix, but a Note would probably be helpful somewhere. Apologies if that Note is already written and I missed it! The same behavior is present in 7.8.1 RC 2 and in HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8666: integer-gmp fails to compile on Debian Squeeze
by GHC 22 Jan '16

22 Jan '16

#8666: integer-gmp fails to compile on Debian Squeeze -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Operating System: Linux Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I get an error when compiling recent HEAD on Debian Squeeze: {{{ "inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name integer-gmp-0.5.1.0 -hide-all- packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist- install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist- install/build/autogen -Ilibraries/integer-gmp/. -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -O -fasm -no-user-package-db -rtsopts -Ilibraries/integer- gmp/mkGmpDerivedConstants/dist -odir libraries/integer-gmp/dist- install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/integer-gmp/dist-install/build -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin libraries/integer-gmp/dist- install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/GMP/Prim.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/Logarithms.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/Logarithms/Internals.dyn_o libraries/integer-gmp /dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist- install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist- install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o -shared -dynamic -dynload deploy -no-auto-link-packages -o libraries /integer-gmp/dist-install/build/libHSinteger- gmp-0.5.1.0-ghc7.7.20140113.so Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger- gmp-0.5.1.0-ghc7.7.20140113.so] Error 1 make: *** [all] Error 2 }}} I can build in-tree `libgmp` by extracting it and running `./configure make`. Following Austin's and Herbert's suggestions I tried adding `-fPIC` to command line options but with no result - see attachements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8782: Using GADT's to maintain invariant in GHC libraries
by GHC 22 Jan '16

22 Jan '16

#8782: Using GADT's to maintain invariant in GHC libraries ------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I rewrote `compiler/utils/OrdList.lhs` using a GADT to preserve some invariants stated only in comments — an excellent chance for `ghc` to eat its own proverbial dog food I feel :) The type signatures remain the same so it should be a drop-in replacement but it does use some GHC features that are too recent (closed type families in particular, the `IsList` instance can be removed) making it ineligible for inclusion I believe. hvr on `#ghc` suggested that I submit a patch anyway and that it could be implemented at a later date (they said `ghc` must be able to be compiled by the last two previous major versions), if this is useful then I will translate `Bag.hls` which has the same invariants but more complicated functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9407: Program produces different output when compiled with -O
by GHC 22 Jan '16

22 Jan '16

#9407: Program produces different output when compiled with -O -------------------------------------+------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiled and run as {{{ ghc Subtlety.hs Subtlety }}} the attached program generates the correct output of {{{ Just (Vec3 0.0 0.0 1.0) }}} but when compiled and run using {{{ ghc -O Subtlety.hs Subtlety }}} the program's output is {{{ Just (Vec3 0.0 0.9805806756909202 0.19611613513818404) }}} Furthermore, subtle changes to the source code (like removing the strictness on the `Vec3` type's fields) can alter the behavior of the compiled program. I am using GHC 7.8.3 x86-64 from Haskell Platform 2014.2.0.0 RC2 on Windows 8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9407> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8830: internal error: Misaligned section: 18206e5b on Windows
by GHC 21 Jan '16

21 Jan '16

#8830: internal error: Misaligned section: 18206e5b on Windows ----------------------------+------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------- Loading package gnutls-0.1.5 ... ghc.exe: internal error: Misaligned section: 18206e5b (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Only occurs when loading the module in as part of a build involving TH. A non-TH-using program using this library links successfully. I have installed a gnutls built for Windows, from http://josefsson.org/gnutls4win/. Different versions have different section offsets, but all the versions I've tried fail like this. I've also gotten the same error linking gnuidn, instead of gnutls, with gnuidn from ftp://ftp.gnu.org/gnu/libidn/libidn-1.28-win32.zip This makes me think this may be a general ghci on windows bug, rather than a misbuilt library. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8850: (Compositional) function mkWeakChan
by GHC 21 Jan '16

21 Jan '16

#8850: (Compositional) function mkWeakChan ------------------------------------+------------------------------------- Reporter: bholst | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7285 | ------------------------------------+------------------------------------- Following the existing functions mkWeakIORef and mkWeakMVar, I'd like to have a function mkWeakChan with the following type signature, similar to that of mkWeakMVar requested by ticket #7285: {{{ mkWeakChan :: Chan a -> v -> Maybe (IO ()) -> IO (Weak v) }}} The implementation of '''Chan''' is private, so it is not easily possible to implement it yourself. The implementation of both functions may look like the following: {{{ mkWeakMVar :: MVar a -> v -> Maybe (IO ()) -> IO (Weak v) mkWeakMVar (MVar m#) v (Just f) = IO $ \s -> case mkWeak# m# v f s of (# s1, w #) -> (# s1, Weak w #) mkWeakMVar (MVar m#) v Nothing = IO $ \s -> case mkWeakNoFinalizer# m# v s of { (# s1, w #) -> (# s1, Weak w #) } mkWeakChan :: Chan a -> v -> Maybe (IO ()) -> IO (Weak v) mkWeakChan c@(Chan readVar writeVar) v f = do _ <- mkWeakMVar readVar writeVar Nothing mkWeakMVar writeVar v f }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8850> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8859: import conditionalization in System.Posix.Files.Common is wrong
by GHC 21 Jan '16

21 Jan '16

#8859: import conditionalization in System.Posix.Files.Common is wrong ------------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.1-rc2 Keywords: | Operating System: Other Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- `System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid "unused import" compiler warnings: {{{ #if defined(HAVE_STRUCT_STAT_ST_CTIM) || \ defined(HAVE_STRUCT_STAT_ST_MTIM) || \ defined(HAVE_STRUCT_STAT_ST_ATIM) || \ defined(HAVE_STRUCT_STAT_ST_ATIMESPEC) || \ defined(HAVE_STRUCT_STAT_ST_MTIMESPEC) || \ defined(HAVE_STRUCT_STAT_ST_CTIMESPEC) import Data.Int import Data.Ratio #endif }}} but those modules are actually used in functions like {{{ accessTimeHiRes (FileStatus stat) = unsafePerformIO $ withForeignPtr stat $ \stat_ptr -> do sec <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime #ifdef HAVE_STRUCT_STAT_ST_ATIM nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIMESPEC nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIMENSEC nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIME_N nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_UATIME usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int) let frac = toInteger usec % 10^(6::Int) #else let frac = 0 #endif return $ fromRational $ toRational sec + frac }}} so there should be additional tests for `defined(HAVE_STRUCT_STAT_ST_ATIMENSEC)`, `defined(HAVE_STRUCT_STAT_ST_ATIME_N)`, ... (15 total). Or, maybe there's a better alternative, since this is very long-winded and fragile... This breaks the build on Android, which has `st_atimensec`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8859> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8904: haddock displays GHC.Types.Coercible as a datatype
by GHC 21 Jan '16

21 Jan '16

#8904: haddock displays GHC.Types.Coercible as a datatype ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- ...and not as a class. Appeared after #8894 was fixed. It is correct in Data.Coerce and GHC.Exts, so this is a minor issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5