- ghc-devs - Haskell.org

Duplicated typedef trips my gcc over
by Gabor Greif 26 Oct '15

26 Oct '15

Hi all, look: $ git grep "typedef struct LibDwSession_ " rts/Libdw.c:typedef struct LibDwSession_ LibDwSession; rts/Libdw.h:typedef struct LibDwSession_ LibDwSession; $ which gcc /usr/bin/gcc $ gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Any reason why we need the typedef in rts/Libdw.c ?? My gcc complains about it... Cheers, Gabor

3 3

Building HEAD with HEAD fails
by Gabor Greif 24 Oct '15

24 Oct '15

Hi devs, just a heads-up (pun intended...) (After updating to TOT, boot and configure with a freshly installed TOT ghc as bootstrap compiler. Then 'make clean'.) Running 'make' gives: ... Creating includes/ghcplatform.h... Done. "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp "/home/ggreif/bin/ghc" -M -static -H64m -O0 -fasm -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id process-1.2.3.0 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -dep-makefile utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix "" -include-pkg-deps utils/hsc2hs/./Main.hs utils/hsc2hs/./C.hs utils/hsc2hs/./Common.hs utils/hsc2hs/./CrossCodegen.hs utils/hsc2hs/./DirectCodegen.hs utils/hsc2hs/./Flags.hs utils/hsc2hs/./HSCParser.hs utils/hsc2hs/./UtilsCodegen.hs <command line>: package db: duplicate packages with incompatible ABIs: binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779 hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4 ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2 transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33 template-haskell-2.11.0.0 has ABIs: , 0ef51476100e9bdf96d1bf59696b98a1 terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467 The only solution I could come up for now is cd libraries ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d bootstrapping.conf then resuming 'make' leads to success. What could this be? Has somebody seen such an error? Cheers and thanks, Gabor

2 6

Context for typed holes
by David Feuer 23 Oct '15

23 Oct '15

Unless something has changed really recently that I've missed, the typed holes messages are missing some really important information: instance information for types in scope. When I am trying to fill in a hole, I look to the "relevant bindings" to show me what pieces I have available to use. Those pieces don't include contexts! Is there something fundamentally hard about adding this information? I'd only want instance information for type variables--providing it for concrete types would make too much noise. I'd also want information on equality constraints, of course.

5 7

Coercion logic
by David Feuer 22 Oct '15

22 Oct '15

At present, any time we write a function with a `Coercible` constraint, we must take great care to choose `Coercible a b` or `Coercible b a` depending on which will ultimately lead to fewer silly conversions. This is particularly sad because the whole Coercible mechanism guarantees that these have exactly the same run-time representation, and because People Wiser Than Me believe Coercible should *always* remain symmetric. My (admittedly reptilian) brain wonders what it would take to tell the type checker that forall a b . Coercible a b ~ Coercible b a and have it over with. David Feuer

2 2

Re: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..."
by George Colpitts 22 Oct '15

22 Oct '15

Right, as it says in title "error in ghci calling main after loading compiled code" On Thursday, October 22, 2015, GHC <ghc-devs(a)haskell.org> wrote: > #10053: Regression on MacOS platform, error in ghci calling main after > loading > compiled code: "Too late for parseStaticFlags..." > -------------------------------------+------------------------------------- > Reporter: George | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 8.0.1 > Component: GHCi | Version: 7.10.1-rc2 > Resolution: | Keywords: > Operating System: MacOS X | Architecture: x86_64 > Type of failure: Incorrect result | (amd64) > at runtime | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * milestone: 7.10.3 => 8.0.1 > > > Old description: > > > ghci > > GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help > > Prelude> :load rsa > > Ok, modules loaded: Main. > > Prelude Main> :show modules > > Main ( rsa.hs, rsa.o ) > > Prelude Main> main > > Too late for parseStaticFlags: call it before runGhc or runGhcT > > Exception: ExitFailure 1 > > Prelude Main> > > > > note, there is no failure if I load interpreted code > > New description: > > {{{ > $ ghci > GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help > Prelude> :load rsa > Ok, modules loaded: Main. > Prelude Main> :show modules > Main ( rsa.hs, rsa.o ) > Prelude Main> main > Too late for parseStaticFlags: call it before runGhc or runGhcT > Exception: ExitFailure 1 > Prelude Main> > }}} > > note, there is no failure if I load interpreted code > > -- > > Comment: > > This isn't going to be fixed for 7.10.3. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10053#comment:14> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

MIN_VERSION macros
by David Feuer 22 Oct '15

22 Oct '15

Cabal defines MIN_VERSION_* macros that allow CPP in a Haskell source file to get information about the versions of the packages that module is being compiled against. Unfortunately, these macros are not available when not compiling with cabal, so packages must either 1. Insist on cabal compilation. This is not very friendly to developers. 2. Make "pessimistic" assumptions, assuming that all the packages are old. This makes it annoying to test new features while also leading to compilation or run-time failures when packages have removed it changed features. 3. Attempt to guess the version based on the GHC version. This works reasonably well for base, ghc-prim, containers, etc., but not so well/at all for others. Would there be some way to get GHC itself to provide these macros to all modules that request CPP? David Feuer

6 7

Memory fence around stg_atomicModifyMutVarzh
by Michael Walker 21 Oct '15

21 Oct '15

Hello, I've been trying to figure out where exactly the synchronisation guarantee of `atomicModifyIORef` comes from, I've gone down a bit of a rabbit-hole of function calls and macro expansions, and wanted to check I'd got the right idea. **Assumption:** `stg_atomicModifyMutVarzh` imposes a barrier to reordering, as described in the Data.IORef documentation. Call tree: stg_atomicModifyMutVarzh dirty_MUT_VAR recordClosureMutated recordMutableCap allocBlock_lock ACQUIRE_SM_LOCK -> ACQUIRE_LOCK -> pthread_mutex_lock **Conclusion:** `pthread_mutex_lock` imposes a memory barrier, and it is through this rather indirect chain of function calls that `stg_atomicModifyMutVarzh` gets its barrier property. Is this correct? Or is there a more direct barrier invocation that I have missed? Thanks. -- Michael Walker (http://www.barrucadu.co.uk)

4 4

pattern synonym with required ctx having polykinded constraint fails
by Sreenidhi Nair 21 Oct '15

21 Oct '15

Hello, We have a pattern synonym as follows type family Showable (a :: k) :: Constraint where Showable (a :: *) = (Show a) Showable a = () pattern Just' :: () => (Showable a) => a -> (Maybe a) pattern Just' a <- (extractJust -> (True, a)) where Just' a = Just a When we try to use the pattern in a different package, the error was [1 of 1] Compiling Bar ( Bar.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) /tmp/test/p2/.stack-work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux-ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi Declaration for Just' Pattern synonym Just': Iface type variable out of scope: k Cannot continue after interface file error The error only occurred when Showable was polykinded and we used synonym in a different package . Using the synonym in the same package works fine. This problem did not happen with the following definition of (non polykinded ) Showable type family Showable a :: Constraint where Showable a = (Show a) We have attached the sample packages which simulate the exact scenario described above. -- Yours truly, Sreenidhi Nair

2 2

Re: [Differential] [Closed] D975: ELF/x86_64: map object file sections separately into the low 2GB
by Thomas Miedema 21 Oct '15

21 Oct '15

This commit is causing segmentation faults on Travis (DYNAMIC_GHC_PROGRAMS = NO): https://s3.amazonaws.com/archive.travis-ci.org/jobs/85552765/log.txt Unexpected failures: ghci.debugger/scripts break001 [bad exit code] (ghci) ghci.debugger/scripts break005 [bad exit code] (ghci) ghci.debugger/scripts break006 [bad exit code] (ghci) ghci.debugger/scripts break011 [bad exit code] (ghci) ghci.debugger/scripts break017 [bad exit code] (ghci) ghci.debugger/scripts dynbrk007 [bad exit code] (ghci) ghci.debugger/scripts hist001 [bad exit code] (ghci) ghci.debugger/scripts print001 [bad exit code] (ghci) ghci.debugger/scripts print002 [bad exit code] (ghci) ghci.debugger/scripts print003 [bad exit code] (ghci) ghci.debugger/scripts print004 [bad exit code] (ghci) ghci.debugger/scripts print005 [bad exit code] (ghci) ghci.debugger/scripts print006 [bad exit code] (ghci) ghci.debugger/scripts print008 [bad exit code] (ghci) ghci.debugger/scripts print010 [bad exit code] (ghci) ghci.debugger/scripts print011 [bad exit code] (ghci) ghci.debugger/scripts print012 [bad exit code] (ghci) ghci.debugger/scripts print013 [bad exit code] (ghci) ghci.debugger/scripts print016 [bad exit code] (ghci) ghci.debugger/scripts print017 [bad exit code] (ghci) ghci.debugger/scripts print019 [bad exit code] (ghci) ghci.debugger/scripts print020 [bad exit code] (ghci) ghci.debugger/scripts print023 [bad exit code] (ghci) ghci.debugger/scripts print024 [bad exit code] (ghci) ghci.debugger/scripts print026 [bad exit code] (ghci) ghci.debugger/scripts print028 [bad exit code] (ghci) ghci.debugger/scripts print031 [bad exit code] (ghci) ghci.debugger/scripts print032 [bad exit code] (ghci) ghci.debugger/scripts print034 [bad exit code] (ghci) ghci/scripts T2976 [bad exit code] (ghci) On Thu, Oct 15, 2015 at 5:20 PM, simonmar (Simon Marlow) < noreply(a)phabricator.haskell.org> wrote: > This revision was automatically updated to reflect the committed changes. > Closed by commit rGHC04e8366608fe: ELF/x86_64: map object file sections > separately into the low 2GB (authored by simonmar). > > *CHANGED PRIOR TO COMMIT* > https://phabricator.haskell.org/D975?vs=4501&id=4502#toc > > *REPOSITORY* > rGHC Glasgow Haskell Compiler > > *CHANGES SINCE LAST UPDATE* > https://phabricator.haskell.org/D975?vs=4501&id=4502 > > *REVISION DETAIL* > https://phabricator.haskell.org/D975 > > *AFFECTED FILES* > rts/CheckUnload.c > rts/Linker.c > rts/LinkerInternals.h > testsuite/tests/ghci/linking/all.T > testsuite/tests/rts/linker_error.c > > *EMAIL PREFERENCES* > https://phabricator.haskell.org/settings/panel/emailpreferences/ > > *To: *simonmar, Phyx, trommler, bgamari, austin > *Cc: *hsyl20, thomie, bgamari >

2 1

Show instances for GHC internals
by Ömer Sinan Ağacan 20 Oct '15

20 Oct '15

Currently the only way to debug and inspect GHC internals is by adding some carefully placed print statements. (I'd love to be proven wrong on this, cost of debugging this way is huge, given how long it's taking to rebuild GHC) We have Outputable instances for most data types, and `Outputable.pprTrace` etc. helps with debugging/inspecting pure functions this way. However, Outputable instances are hiding some details and they're sometimes not useful for debugging and inspecting internals. This is why I implemented CoreDump package(http://hackage.haskell.org/package/CoreDump), Outputable instance of CoreSyn is simply not useful for some things. Similarly, just today I had to add a show function for `HscTypes.TargetId` because `Outputable` instance was hiding `Maybe Phase` field. Since the only way to debug or inspect GHC internals(except maybe the RTS) is by printing things, I think we should provide Show instances for.. basically everything. Otherwise I just can't see a way of debugging things and inspecting internals, tracing code etc. for learning purposes. I was wondering what would be the cost of adding Show instances. Would that mean significantly increased compile times? Or significantly bigger GHC binaries? If that's the case, could we enable Show instances with some arguments so that we can enable/disable it by modifying mk/build.mk?

4 6