- ghc-devs - Haskell.org

Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
by Jan Stolarek 05 Nov '14

05 Nov '14

As part of #9358 I'm considering removing these two flags: -ddump-simpl-phases: dumps simplifier statistics for phases of the simplifier but it works only when used together with -ddump-simpl-stats. User can limit which statistics are displayed by passing in either the simplifier phase number (0,1,2), phase name (final, main, post-worker-wrapper, Gentle) or both (separated with ":"). So for example -ddump-simpl-phases=0:main,1 dumps statistics for all pases labeled as phase 1 and only those pases of phase 0 that are named "main". Has anyone ever used that flag? Do we consider it useful? -ddump-core-pipeline: this seems like a partially implemented stub. The name is very misleading because it is related to plugins. The only thing that it seems to do at the moment is that when -ddump-to-file is set then -ddump-core-pipeline will result in dumping plugin passes to file. Janek

3 2

Tests with compilation errors
by Gintautas Miliauskas 05 Nov '14

05 Nov '14

Going through some validate.sh results, I found compilation errors due to missing libraries, like this one: =====> stm052(normal) 4088 of 4108 [0, 21, 0] cd ../../libraries/stm/tests && 'C:/msys64/home/Gintas/ghc/bindisttest/install dir/bin/ghc.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopt s -fno-warn-tabs -fno-ghci-history -o stm052 stm052.hs -package stm >stm052.comp.stderr 2>&1 Compile failed (status 256) errors were: stm052.hs:10:8: Could not find module ‘System.Random’ Use -v to see a list of the files searched for. I was surprised to see that these are not listed in the test summary at the end of the test run, but only counted towards the "X had missing libraries" row. That setup makes it really easy to miss them, and I can't think of a good reason to sweep such tests under the rug; a broken test is a failing test. How about at least listing such failed tests in the list of failed tests of the end? At least in this case the error does not seem to be due to some missing external dependencies (which probably would not be a great idea anyway...). The test does pass if I remove the "-no-user-package-db" argument. What was the intention here? Does packaging work somehow differently on Linux? (I'm currently testing on Windows.) On a related note, how about separating test failures from failing performance tests ("stat too good" / "stat not good enough")? The latter are important, but they seem to be much more prone to fail without good reason. Perhaps do some color coding of the test runner output? That would also help. -- Gintautas Miliauskas

4 6

GHC AST Annotations (again)
by Alan & Kim Zimmerman 05 Nov '14

05 Nov '14

Hi all Hopefully I will be able to stop harassing everyone on this topic soon. The final versions of the patches for this are ready for review. It has been split into three parts D412 Extends the HsLit values to have an extra field for the original source text, which can differ from the literal value. D426 adds various extra locations in the HsSyn AST to allow the additions of API annotations everywhere needed. D438 modifies the Lexer/Parser to produce API annotations and comments as part of the ParsedSource result. Please review if you are interested. Links https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations https://ghc.haskell.org/trac/ghc/ticket/9628 https://phabricator.haskell.org/D412 https://phabricator.haskell.org/D426 https://phabricator.haskell.org/D438 Regards Alan

1 1

"Hidden" LLVM flags
by Jan Stolarek 05 Nov '14

05 Nov '14

DynFlags list some LLVM flags as "hidden": ( "llvm-tbaa", Opt_LlvmTBAA, nop), -- hidden flag ( "llvm-pass-vectors-in-regs", Opt_LlvmPassVectorsInRegisters, nop), -- hidden flag Do I undertsand correctly that "hidden" means "not documented in the User's Guide"? Is there a good reason for this? I'd like to document them as part of #9358, especially that -fllvm-tbaa is enabled by default for all optimisation levels. Janek

1 1

package 'categories' fails with HEAD
by Gabor Greif 05 Nov '14

05 Nov '14

Hi all, some time ago I filed: https://github.com/ekmett/categories/issues/4 against the 'categories' library. But I cannot see what is wrong with the code. It also builds with older GHCs (though I should re-check with 7.8.3). So I conjecture this is a HEAD problem in GHC HEAD. It seems weird. Any ideas what this could be? Cheers, Gabor

1 0

RE: [commit: ghc] wip/rae: Fix #1476 by making splice patterns work. (eb257c3)
by Simon Peyton Jones 04 Nov '14

04 Nov '14

| Unfortunately, splice patterns in brackets still do not work | because we don't run splices in brackets. Without running a pattern | splice, we can't know what variables it binds, so we're stuck. Not just "don't" but "can't"!! This isn't a compiler deficiency: the code is not there to run! Simon

1 0

Problem with select(2) in single threaded runtime.
by Merijn Verstraaten 04 Nov '14

04 Nov '14

While adding a test case for https://phabricator.haskell.org/D407 I noticed that while my initial patch fixed the crash for the threaded runtime, the single threaded runtime was still affected. I dove into the RTS and have hit a snag. In awaitEvent (rts/posix/Select.c) select(2) is called with the timeout computed from the Haskell call. On my current (OSX) machine my test case overflows "struct timeval", causing select to return EINVAL and crash the runtime. Unfortunately, there appears to be no portable to find the maximum size of time_t/suseconds_t (the types of the struct timeval fields), and therefore no portable way to avoid this overflow. The most practical thing I can think of is to add a configure case that checks sizeof(time_t) and sizeof(suseconds_t) and guesses they're just unsigned values of the relevant type, but I'm open to better suggestions. Alternatively, the solution is to hardcode the max value for every platform, in which case I avoid you all to tell me the maximum value on your specific platform :p Cheers, Merijn

2 5

Phab and I differ
by Simon Peyton Jones 04 Nov '14

04 Nov '14

I built and validated this commit just fine. Phab says Unexpected failures: ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) rts linker_unload [bad exit code] (normal) stranal/should_compile str001 [exit code non-0] (optasm) stranal/should_compile str002 [exit code non-0] (optasm) stranal/should_compile test [exit code non-0] (optasm) but none of them fail for me. I don't know how to see enough of Phab's log to see what it thinks when wrong. (it just shows me 25 lines; clicking on "unlimited" still only shows 30 lines) | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 04 November 2014 15:32 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC6a1c05f01429: A little | refactoring of HsSplice and friends | | Harbormaster failed to build B1678: rGHC6a1c05f01429: A little | refactoring of HsSplice and friends! | | USERS | simonpj (Author) | GHC - Type checker/inferencer (Auditor) | GHC - Core/System FC (Auditor) | GHC - Renamer (Auditor) | GHC - HsSyn/Parser (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC6a1c05f01429 | | To: simonpj, GHC - Type checker/inferencer, GHC - Core/System FC, GHC | - Renamer, GHC - HsSyn/Parser

3 3

RE: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-notes
by Simon Peyton Jones 04 Nov '14

04 Nov '14

I'm seeing all these build failures, but it builds fine for me. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 04 November 2014 12:28 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening- | notes | | Harbormaster failed to build B1665: rGHC652a5efe774a: Add flattening- | notes! | | USERS | simonpj (Author) | GHC - Type checker/inferencer (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC652a5efe774a | | To: simonpj, GHC - Type checker/inferencer

2 2

Re: [Msys2-users] Debugging undeterministic segfaults
by Gintautas Miliauskas 04 Nov '14

04 Nov '14

I had a problem <https://github.com/Alexpux/MSYS2-packages/issues/116> with building msys2-runtime, but debug bash installed successfully. I uncommented the hook to invoke qtcreator.exe on crashing (your .bat file needs escaping, puill request pending...), but I'm not quite sure how to check that it works. I tried building this crasher program with /usr/bin/gcc: #include <stdio.h> int main() { char *s = 0; printf("hi\n"); printf("%s\n", s); printf("bye\n"); return 0; } But running it just prints "hi", no indications of a crash or anything, regardless of the value of the MSYS variable: $ /usr/bin/gcc -o crash crash.c $ ./crash.exe hi $ echo $? 0 On Tue, Nov 4, 2014 at 1:56 AM, Ray Donnelly <mingw.android(a)gmail.com> wrote: > On Tue, Nov 4, 2014 at 12:45 AM, Gintautas Miliauskas > <gintautas.miliauskas(a)gmail.com> wrote: > > I have a suspicion that the segmentation faults are related to fork > errors, > > which appear in logs from time to time. After a few builds fork() errors > > become very frequent, and segfaults seem to occur more often. I just ran > the > > build (validate.sh) in a loop, and after a while got a bunch of > segfaults in > > Makefile rules as basic as rm invocations in the initial "make clean", > e.g.: > > > > "rm" -rf driver/split/dist > > driver/split/ghc.mk:19: recipe for target 'clean_driver/split_dist' > failed > > make[1]: *** [clean_driver/split_dist] Segmentation fault > > Makefile:94: recipe for target 'maintainer-clean' failed > > > > Closing and reopening the msys2 console seems to help - for some time. > > Interesting .. how much process spawning do you think happens? On > MSYS2 we run massive builds (bootstrapping builds of GCC for 2 arches > for example), but MSYS2 shares a memory map, so heap corruption could > happen and cause later problems. My recommendation about building > debug bash and msys2-runtime and set > MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|<process-id> > stands all the more then. You may need to setup path mappings in Qt C > to map from MSYS2 paths to Windows paths. You need to do this as QtC > needs to use the native GDB instead of the MSYS2 one so that QtC and > GDB are in the same pathing namespace. > > There may be a way of building msys2-runtime to check for memory > overruns too, perhaps just building it with the 'debug' option will > enable that, I'm not sure .. > > > > > > > > > > > On Tue, Nov 4, 2014 at 1:30 AM, Ray Donnelly <mingw.android(a)gmail.com> > > wrote: > >> > >> On Mon, Nov 3, 2014 at 11:07 PM, Gintautas Miliauskas > >> <gintautas.miliauskas(a)gmail.com> wrote: > >> > +ghc-devs > >> > > >> > Hi Ray, > >> > > >> > thanks for the feedback. ghc-stage1 is a native application, it is > built > >> > using a host ghc and a mingw gcc bundled with the ghc distribution (in > >> > order > >> > to keep Windows builds more predictable). The thing is, the same > builds > >> > (using make) that were stable on cygwin seem to be crashing on msys2, > >> > even > >> > though the (bundled) gcc used for the build is the same. It could be > >> > that > >> > msys2 is triggering a bug in ghc somehow, but it could be something > >> > going on > >> > in msys2 itself. > >> > > >> > The tricky part is that the crashes are rare, one in thousands of ghc > >> > invocations within a make build, and I'm having trouble pinning one > down > >> > to > >> > investigate. I'll try some basic tracing first, but ideas for > something > >> > more > >> > sophisticated would be very helpful. > >> > >> Ah, ok. I skim read your initial email and applied totally incorrect > >> weighting to the "not very hard to reproduce" bit, apologies! > >> > >> It *should* be possible to setup post-mortem debugging using either Qt > >> Creator (Tools->Options->Debugger, tick "Use Qt Creator for > >> post-mortem debugging") or Dr. Mingw > >> (https://github.com/jrfonseca/drmingw) I briefly tested both options: > >> > >> Qt Creator: It seems there's a bug in its handling of the > >> -wincrashevent command line which I've just added a note about to the > >> MINGW-packages todo list since I'd find this feature more than very > >> useful: > >> https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md > >> > >> Dr Mingw: Launching the crashing executable from Windows Explorer, it > >> launches it and gives me useful information. > >> > >> Unfortunately, regardless of the debugger used, when invoking the > >> crashing executable from the mintty commandline, something inhibits > >> all post mortem debugging. I will ask the mingw-w64 guys if they know > >> what this is. I guess intrusive dialogs would be annoying, but I'd > >> like an env. var override for that I think. > >> > >> There is another possibility, and that's that bash is crashing, which > >> is an MSYS2 program. We do have a way of hooking into post-mortem > >> debugging there since Cygwin provided a way and we improved it. If you > >> check your msys2_shell.bat you'll see: > >> rem set > >> MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|<process-id> > >> > >> If you remove the rem and make sure the path is correct (it may have > >> rotted some since I last used it) then hopefully you'll get something > >> useful. To be really useful, you should rebuild two packages, > >> MSYS2-packages/{msys2-runtime,bash}/PKGBUILD with > >> options=('debug' '!strip') > >> and then install them. > >> > >> Finally, can anyone else confirm the problem? > >> > >> There may be some edge cases when e.g. PATH is around 1024 characters, > >> I've seen some hardcoded limits in the msys2-runtime (nee Cygwin) > >> code base for things like that. I'd advise cutting your Windows PATH > >> down to just the essentials. > >> > >> Cheers, > >> > >> Ray. > >> > >> > > >> > A PKGBUILD for ghc should be feasible, although the bootstrapping is a > >> > bit > >> > tricky (some Haskell tools need to be preinstalled). I'm not sure how > >> > useful > >> > it would be since for Windows there is already a nicely packaged > native > >> > Haskell Platform installer. > >> > > >> > > >> > On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly <mingw.android(a)gmail.com > > > >> > wrote: > >> >> > >> >> On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas > >> >> <gintautas.miliauskas(a)gmail.com> wrote: > >> >> > Hello, > >> >> > > >> >> > I have been working on building GHC, the Glasgow Haskell Compiler, > on > >> >> > Windows using msys2 [1]. We have been having some strange trouble > >> >> > with > >> >> > ghc > >> >> > segfaulting during the bootstrapping process (i.e., during make). > The > >> >> > crashes are not very hard to reproduce, but they are not > predictable > >> >> > either. > >> >> > This is almost certainly a bug in ghc itself and not with msys2 > >> >> > (although > >> >> > the crashes do not seem to occur in other environments), but I've > >> >> > been > >> >> > having some trouble pinning it down. > >> >> > > >> >> > >> >> Hi Gintuatas, > >> >> > >> >> Great. I spotted that MSYS2 was the recommended env. for GHC on > >> >> Windows, hopefully it will remain so! > >> >> > >> >> > What's a good way to debug such crashes? Is it possible to somehow > >> >> > stop > >> >> > the > >> >> > ghc process when it segfaults and attach gdb, or to dump core > somehow > >> >> > for > >> >> > later inspection? > >> >> > > >> >> > [1] > >> >> > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > >> >> > > >> >> > Here's one example crash: > >> >> > > >> >> > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static > >> >> > -H32m > >> >> > -O > >> >> > -Werror -Wall -H64m -O0 -this-package-key > >> >> > ghc_4ugNArSu5ba0Z1uHXrbTlU > >> >> > -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm > >> >> > -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar > >> >> > -icompiler/ghci > >> >> > -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen > -icompiler/main > >> >> > -icompiler/nativeGen -icompiler/parser -icompiler/prelude > >> >> > -icompiler/profiling -icompiler/rename -icompiler/simplCore > >> >> > -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn > >> >> > -icompiler/stranal -icompiler/typecheck -icompiler/types > >> >> > -icompiler/utils > >> >> > -icompiler/vectorise -icompiler/stage2/build > >> >> > -icompiler/stage2/build/autogen > >> >> > -Icompiler/stage2/build -Icompiler/stage2/build/autogen > -Icompiler/. > >> >> > -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build > >> >> > -Icompiler/stage2 -optP-DGHCI -optP-include > >> >> > -optPcompiler/stage2/build/autogen/cabal_macros.h -package-key > >> >> > Win32_43THQMouBnk2wpnouztX1X -package-key > >> >> > array_GX4NwjS8xZkC2ZPtjgwhnz > >> >> > -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key > >> >> > binpa_17GphrLqCXt1H1lm4Kse1p -package-key > >> >> > bytes_Kc0PyaputnzDnBdZW0y2Gv > >> >> > -package-key conta_ChF4XLXB9JmByIycPzerow -package-key > >> >> > direc_HU5aFxMIQNwGQFzisjuinu -package-key > >> >> > filep_34DFDFT9FVD9pRLLgh8IdQ > >> >> > -package-key hoopl_IZAd44CED5NCOlpg8p2Kaj -package-key > >> >> > hpc_1QTsfQSN40FHN9p3mydARY -package-key > proce_7ZlAbRkwiRO8qgXx3NNP0G > >> >> > -package-key templ_F6UJgDtBcDIFWuHmMGEFzy -package-key > >> >> > time_HGs4JcQCd4wF6U8vJQ5fNH -package-key > trans_5jw4w9yTgmZ89ByuixDAKP > >> >> > -Wall > >> >> > -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 > >> >> > -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 > -Rghc-timing > >> >> > -O2 > >> >> > -fwarn-tabs -O -dcore-lint -no-user-package-db -rtsopts -odir > >> >> > compiler/stage2/build -hidir compiler/stage2/build -stubdir > >> >> > compiler/stage2/build -c compiler/basicTypes/UniqSupply.lhs -o > >> >> > compiler/stage2/build/UniqSupply.o > >> >> > > >> >> > compiler/ghc.mk:657: recipe for target > >> >> > 'compiler/stage2/build/UniqSupply.o' > >> >> > failed > >> >> > make[1]: *** [compiler/stage2/build/UniqSupply.o] Segmentation > fault > >> >> > > >> >> > >> >> Well, it's pretty much the same story as with Linux. Build the > >> >> executable and as many libraries as you can with (something like) > >> >> "-ggdb -O0" then use gdb command line or some IDE of choice. > >> >> Personally I use Qt Creator (we have packages for this) as it can > >> >> debug external programs and, even though I don't dislike command > >> >> lines, I find debugging from them a bit too masochistic. > >> >> > >> >> Is ghc-stage1.exe an MSYS2 program or a native one? Which compiler is > >> >> it built with exactly? > >> >> > >> >> What would be involved in creating a PKGBUILD for ghc? We'd love to > >> >> have one, and it'd certainly make me a lot more inclined to dive in > to > >> >> see what's going on if one existed already. > >> >> > >> >> Ray. > >> >> > >> >> > > >> >> > -- > >> >> > Gintautas Miliauskas > >> >> > > >> >> > > >> >> > > >> >> > > ------------------------------------------------------------------------------ > >> >> > > >> >> > _______________________________________________ > >> >> > Msys2-users mailing list > >> >> > Msys2-users(a)lists.sourceforge.net > >> >> > https://lists.sourceforge.net/lists/listinfo/msys2-users > >> >> > > >> > > >> > > >> > > >> > > >> > -- > >> > Gintautas Miliauskas > > > > > > > > > > -- > > Gintautas Miliauskas > -- Gintautas Miliauskas

2 1