October 2016 - ghc-devs

Register Allocator Tests
by Thomas Jakway 12 Oct '16

12 Oct '16

Can anyone point me to the register allocator tests (especially for the graph register allocator)? Can't seem to find them and grepping doesn't turn up much (pretty much just testsuite/tests/codeGen/should_run/cgrun028.h).

3 4

Re: Reading floating point
by David Feuer 11 Oct '16

11 Oct '16

I fully expect this to be somewhat tricky, yes. But some aspects of the current implementation strike me as pretty clearly non-optimal. What I meant about going through Rational is that given "625e-5", say, it calculates 625%100000, producing a fraction in lowest terms, before calling fromRational, which itself invokes fromRat'', a division function optimized for a special case that doesn't seem too relevant in this context. I could be mistaken, but I imagine even reducing to lowest terms is useless here. The separate treatment of the digits preceding and following the decimal point doesn't do anything obviously useful either. If we (effectively) normalize in decimal to an integral mantissa, for example, then we can convert the whole mantissa to an Integer at once; this will balance the merge tree better than converting the two pieces separately and combining. On Oct 10, 2016 6:00 AM, "Yitzchak Gale" <gale(a)sefer.org> wrote: The way I understood it, it's because the type of "floating point" literals is Fractional a => a so the literal parser has no choice but to go via Rational. Once you have that, you use the same parser for those Read instances to ensure that the result is identical to what you would get if you parse it as a literal in every case. You could replace the Read parsers for Float and Double with much more efficient ones. But you would need to provide some other guarantee of consistency with literals. That would be more difficult to achieve than one might think - floating point is deceivingly tricky. There are already several good parsers in the libraries, but I believe all of them can provide different results than literals in some cases. YItz On Sat, Oct 8, 2016 at 10:27 PM, David Feuer <david.feuer(a)gmail.com> wrote: > The current Read instances for Float and Double look pretty iffy from an > efficiency standpoint. Going through Rational is exceedingly weird: we have > absolutely nothing to gain by dividing out the GCD, as far as I can tell. > Then, in doing so, we read the digits of the integral part to form an > Integer. This looks like a detour, and particularly bad when it has many > digits. Wouldn't it be better to normalize the decimal representation first > in some fashion (e.g., to 0.xxxxxxexxx) and go from there? Probably less > importantly, is there some way to avoid converting the mantissa to an > Integer at all? The low digits may not end up making any difference > whatsoever. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

3 8

when building latest GHC on Mac with Xcode 8: Symbol not found: _clock_gettime
by John Leo 11 Oct '16

11 Oct '16

Hi everyone, I'm trying to compile ghc from the latest source and am hitting an error "Symbol not found: _clock_gettime". I'm on Mac El Capitan and recently installed Xcode 8 which I'm sure is what caused the problem. Using Google I found some relevant pages including this one https://mail.haskell.org/pipermail/ghc-devs/2016-July/012511.html but I've been unable to figure out what I can do to fix the problem. Any help would be appreciated. The tail end of my compilation output is below. Thanks in advance. John cat ghc/ghc.wrapper >> inplace/bin/ghc-stage2 chmod +x inplace/bin/ghc-stage2 "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -Wall -hide-all-packages -i -iutils/ghctags/. -iutils/ghctags/dist-install/build -Iutils/ghctags/dist-install/build -iutils/ghctags/dist-install/build/ghctags/autogen -Iutils/ghctags/dist-install/build/ghctags/autogen -optP-include -optPutils/ghctags/dist-install/build/ghctags/autogen/cabal_macros.h -package-id Cabal-1.25.0.0 -package-id base-4.9.0.0 -package-id containers-0.5.7.1 -package-id ghc-8.1 -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir utils/ghctags/dist-install/build -hidir utils/ghctags/dist-install/build -stubdir utils/ghctags/dist-install/build -c utils/ghctags/./Main.hs -o utils/ghctags/dist-install/build/Main.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -Wall -hide-all-packages -i -iutils/check-api-annotations/. -iutils/check-api-annotations/dist-install/build -Iutils/check-api-annotations/dist-install/build -iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -Iutils/check-api-annotations/dist-install/build/check-api-annotations/autogen -optP-include -optPutils/check-api-annotations/dist-install/build/check-api-annotations/autogen/cabal_macros.h -package-id Cabal-1.25.0.0 -package-id base-4.9.0.0 -package-id containers-0.5.7.1 -package-id directory-1.2.6.2 -package-id ghc-8.1 -Wall -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir utils/check-api-annotations/dist-install/build -hidir utils/check-api-annotations/dist-install/build -stubdir utils/check-api-annotations/dist-install/build -c utils/check-api-annotations/./Main.hs -o utils/check-api-annotations/dist-install/build/Main.dyn_o dyld: lazy symbol binding failed: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib dyld: lazy symbol binding failed: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib dyld: Symbol not found: _clock_gettime Referenced from: /Users/leo/haskell/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161010.dylib (which was built for Mac OS X 10.12) Expected in: /usr/lib/libSystem.B.dylib make[1]: *** [utils/ghctags/dist-install/build/Main.dyn_o] Trace/BPT trap: 5 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/check-api-annotations/dist-install/build/Main.dyn_o] Trace/BPT trap: 5 make: *** [all] Error 2 i

2 2

RE: [Diffusion] [Build Failed] rGHCa6111b8cc14a: More tests for Trac #12522
by Simon Peyton Jones 10 Oct '16

10 Oct '16

This says “stat not good enough” for “max_bytes_used” on T1969. I pushed a “T1969 is ok” patch recently, because it IS ok on my (64-bit Linux) machine. If it’s not ok for our CI infrastructure, by all means un-push it or something. Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 10 October 2016 15:07 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHCa6111b8cc14a: More tests for Trac #12522 Harbormaster failed to build B11303: rGHCa6111b8cc14a: More tests for Trac #12522! BRANCHES master USERS simonpj (Author) O7 (Auditor) COMMIT https://phabricator.haskell.org/rGHCa6111b8cc14a EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

1 0

Reading floating point
by David Feuer 10 Oct '16

10 Oct '16

The current Read instances for Float and Double look pretty iffy from an efficiency standpoint. Going through Rational is exceedingly weird: we have absolutely nothing to gain by dividing out the GCD, as far as I can tell. Then, in doing so, we read the digits of the integral part to form an Integer. This looks like a detour, and particularly bad when it has many digits. Wouldn't it be better to normalize the decimal representation first in some fashion (e.g., to 0.xxxxxxexxx) and go from there? Probably less importantly, is there some way to avoid converting the mantissa to an Integer at all? The low digits may not end up making any difference whatsoever.

2 1

Allow top-level shadowing for imported names?
by Herbert Valerio Riedel 10 Oct '16

10 Oct '16

Hi *, I seem to recall this was already suggested in the past, but I can't seem to find it in the archives. For simplicity I'll restate the idea: foo :: Int -> Int -> (Int,Int) foo x y = (bar x, bar y) where bar x = x+x results merely in a name-shadowing warning (for -Wall): foo.hs:4:9: warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding bound at foo.hs:2:5 However, import Data.Monoid (<>) :: String -> String -> String (<>) = (++) main :: IO () main = putStrLn ("Hi" <> "There") doesn't allow to shadow (<>), but rather complains about ambiguity: bar.hs:7:23: error: Ambiguous occurrence ‘<>’ It could refer to either ‘Data.Monoid.<>’, imported from ‘Data.Monoid’ at bar.hs:1:1-18 or ‘Main.<>’, defined at bar.hs:4:1 This is of course in line with the Haskell Report, which says in https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-101000… | The entities exported by a module may be brought into scope in another | module with an import declaration at the beginning of the module. The | import declaration names the module to be imported and optionally | specifies the entities to be imported. A single module may be imported | by more than one import declaration. Imported names serve as top level | declarations: they scope over the entire body of the module but may be | shadowed by *local non-top-level bindings.* However, why don't we allow this to be relaxed via a new language extensions, to allow top-level bindings to shadow imported names (and of course emit a warning)? Unless I'm missing something, this would help to keep existing and working code compiling if new versions of libraries start exporting new symbols (which happen to clash with local top-level defs), rather than resulting in a fatal name-clash; and have no major downsides. If this sounds like a good idea, I'll happily promote this into a proper proposal over at https://github.com/ghc-proposals/ghc-proposals; I mostly wanted to get early feedback here (and possibly find out if and where this was proposed before), before investing more time turning this into a fully fledged GHC proposal. Cheers, HVR

15 19

bkpcabal01 test failure on Mac OS X
by Ben Gamari 08 Oct '16

08 Oct '16

Hi Edward, Our new OS X build bot has noticed that the bkpcabal01 testcase introduced with your Backpack merge seems to fail on OS X with, =====> bkpcabal01(normal) 1 of 1 [0, 0, 0] cd "./backpack/cabal/bkpcabal01/bkpcabal01.run" && $MAKE -s --no-print-directory bkpcabal01 CLEANUP=1 Actual stderr output differs from expected: --- /dev/null 2016-10-08 22:51:23.000000000 +0300 +++ ./backpack/cabal/bkpcabal01/bkpcabal01.run/bkpcabal01.run.stderr.normalised 2016-10-08 22:51:23.000000000 +0300 @@ -0,0 +1,4 @@ +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-36887/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-36936/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-37078/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-37123/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols *** unexpected failure for bkpcabal01(normal) It seems that this message is produced by `ar` while building the .a archive, bkpcabal01 bgamari$ make SETUP="./Setup -v3" bkpcabal01 ... ("/usr/bin/ar",["-r","-s","-v","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o"]) ar: creating archive dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o /Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols I've opened #12673 to track this issue but until we have a chance to fix it I've enabled `ignore_stderr` to the testcase on Darwin. Cheers, - Ben

1 0

Type hole in pattern match
by amindfv＠gmail.com 08 Oct '16

08 Oct '16

Is this intended behavior?: foo :: _ (foo, _) = (True, True) Produces no warning or message at all even with -Wall Tom

3 2

[GHC Proposal] Optional tuple parenthesization
by Ben Gamari 07 Oct '16

07 Oct '16

Hello everyone, Iceland_Jack has just opened Pull Requests #18 [1] and #19 [2] against the ghc-proposals repository, describing a extensions to GHC's LambdaCase extension and pattern matching syntax on tuples. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/18 [2] https://github.com/ghc-proposals/ghc-proposals/pull/19

1 0

Travis broken (type checking patches by SPJ)
by Joachim Breitner 07 Oct '16

07 Oct '16

Hi, our secondary CI infrastructure is in bad shape since a week. The first push that broke it was the one ending with commit fc4ef66 by SPJ: * fc4ef66 - Comments only (vor 7 Tagen)<Simon Peyton Jones> * b612da6 - Fix impredicativity (again) (vor 7 Tagen)<Simon Peyton Jones> * 3012c43 - Add Outputable Report in TcErrors (vor 7 Tagen)<Simon Peyton Jones> * 66a8c19 - Fix a bug in occurs checking (vor 7 Tagen)<Simon Peyton Jones> * 2fbfbca - Fix desugaring of pattern bindings (again) (vor 7 Tagen)<Simon Peyton Jones> * 0b533a2 - A bit of tracing about flattening (vor 7 Tagen)<Simon Peyton Jones> https://github.com/ghc/ghc/compare/f21eedbc223c...fc4ef667ce2b --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ /tmp/ghctest-gSX4vv/test spaces/./boxy/Base1.run/Base1.comp.stderr.normalised 2016-09-30 12:44:57.182659875 +0000 @@ -0,0 +1,18 @@ + +Base1.hs:20:13: + Couldn't match type â€˜a0 -> a0â€™ with â€˜forall a. a -> aâ€™ + Expected type: MEither Sid b + Actual type: MEither (a0 -> a0) b + In the expression: MLeft fid + In an equation for â€˜test1â€™: test1 fid = MLeft fid + +Base1.hs:25:39: + Couldn't match type â€˜a1 -> a1â€™ with â€˜forall a. a -> aâ€™ + Expected type: Maybe (Sid, Sid) + Actual type: Maybe (a1 -> a1, a2 -> a2) + In the expression: Just (x, y) + In a case alternative: MRight y -> Just (x, y) + In the expression: + case m of { + MRight y -> Just (x, y) + _ -> Nothing } *** unexpected failure for Base1(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_aAI Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for RaeBlogPost(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_awK Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for TypeLevelVec(normal) A subsequent commit by SPJ fixed the first one. It now compield without -DDEBUG again, but the other two failures (observable only with -DDEBUG) are still there. Since then, Travis has been reporting failures for the master branch. I only noticed now as I pushed something to master, and I got an email. Did you not get notifications about the breakage? If you did, was it unclear how to get to the log file? In any case: Simon, could you have a look and see if the ASSERT is pointing out a real bug introduced with your commits, or whether the ASSERT is wrong, so that we can build master with -DDEBUG again? Thanks, Joachim -- “Comments only” with this failure:Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0