Re: HEAD doesn't build. Totally stalled.
On Fri, 17 Jul 2020 10:45:37 +0800
Moritz Angermann wrote:
> Well, we actually *do* test for __SSP__ in HEAD:
> https://github.com/ghc/ghc/blob/master/rts/RtsSymbols.c#L1170
> Which currently lists:
> #if !defined(mingw32_HOST_OS) && !defined(DYNAMIC) &&
> (defined(_FORTIFY_SOURCE) || defined(__SSP__))
I believe it's a https://gitlab.haskell.org/ghc/ghc/-/issues/18442
It breaks for me as well.
It triggers if one has gcc compiler with any of 2 properties:
1. gcc is built with --enable-default-ssp (sets __SSP__ for all compilations)
2. gcc defaults to _FORTIFY_SOURCE
Note that presence or absence of __stack_chk_guard is indicated
by neither of these and instead is present when gcc is built with
--enable-libssp (use gcc's __stack_* functions instead gcc's direct TLS
instructions with one glibc fallback.)
Gentoo does both [1.] and [2.] by default. I believe Debian does at least
[2.] by default. I'm surprised gitlab presubmit merge did not detect the
build breakage.
What do macros [1] and [2.] mean for glibc-linux:
- _FORTIFY_SOURCE only affects glibc headers to change memcpy()
calls to memcpy_chk() to add overflow checks. It does not affect
symbol exports available by libc. __stack_* symbols are always present.
Parts of libc or other libraries we link ghc with coult already call __stack_*
function as they could already be built with _FORTIFY_SOURCE. Regardless
of how ghc is being built: with _FORTIFY_SOURCE or without.
- __SSP__ indicates code generation of stack canary placement by gcc
(-fstack-protector-* options, or default override with gcc's
--enable-default-ssp)
If target is not a gcc's libssp target (a.k.a. --disable-libssp), a default
for all
linux-glibc targets) then gcc never uses -lssp and uses gcc's builtin
instructions
instead of __stack_chk_guard helpers. In this mode __stack_chk_guard is not
present in any libraries installed by gcc or glibc. The only symbol provided
by glibc
is __stack_chk_fail (which arguably should not be exposed at all as it's an
unusual contract between glibc/gcc: https://gcc.gnu.org/PR93509)
--enable-libssp for gcc does bring in __stack_chk_guard. Library is present and
could
use __stack_chk_guard in libraries ghc depends on regardless of
-fstack-protector-* options used to build ghc. I believe --enable-libssp is
used only
on mingw.
What I'm trying to say is that presence of __stack_chk_guard is orthogonal
to either __SSP__ define or _FORTIFY_SOURCE ghc uses today..
It's rather a function of how gcc toolchain was built: --enable-libssp or not.
> But this seems to still be ill conceived. And while Simon is the only
> one I'm aware of, for whom this breaks we need to find a better
> solution. As such, we will revert the commits.
>
> Why do we do all this symbol nonsense in the RTS to begin with? It
> has to do with our static linker we have in GHC. Loading arbitrary
> archives, means we need to be able to resolve all kinds of symbols
> that objects might refer to. For regular dependencies this will work
> if the dependencies are listed in the package configuration file, the
> linker will know which dependencies to link. This get a bit annoying
> for libraries that the compiler will automagically provide. libgcc,
> libssp, librt, ...
>
> The solution so far was simply to have the RTS depend on these
> symbols, and keep a list of them around. That way when the linker
> built the RTS we'd get it to link all these symbols into the RTS, and
> we could refer to them in the linker. Essentially looking them up in
> the linked binary (ghc, or iserv).
>
> This is a rather tricky problem, and almost all solutions we came up
> with are annoying in one or more dimensions. After some discussion on
> IRC last night, we'll go forward trying the following solution:
>
> We'll keep a file in the lib folder (similar to the settings,
> llvm-targets, ...) that is essentially a lookup table of Symbol ->
> [Library]. If we encounter an unknown symbol, and we have it in our
> lookup table, we will try to load the named libraries, hoping for them
> to contain the symbol we are looking for. If everything fails we'll
> bail.
>
> For the example symbols that prompted this issue: (which are emitted
> when stack smashing protector hardening is enabled, which seems to be
> the default on most linux distributions today, which is likely why I
> couldn't reproduce this easily.)
>
> [("__stack_chk_guard", ["ssp"])]
>
> would tell the compiler to try to locate (through the usual library
> location means) the library called "ssp", if it encounters the symbol
> "__stack_chk_guard".
>
> Isn't this what the dynamic linker is supposed to solve? Why do we
> have to do all this on our own? Can't we just use the dynamic linker?
> Yes, and no. Yes we can use the dynamic linker, and we even do. But
> not all platforms have a working, or usable linker. iOS for example
> has a working dynamic linker, but user programs can't use it. muslc
> reports "Dynamic loading n
Re: bug in aclocal.m4
On Sat, 22 Sep 2018 15:09:15 -0700 Evan Laforge wrote: > Tiny bug, so I'll just throw it out here instead of trying to get arc > set up again: > > aclocal.m4 line 2438, at head (commit > 7e77f41430ae1cad84d5b0c90328331d38f3eda0) has # typo'd as $. It > causes a harmless but alarming error in configure. Sounds reasonable. Proposed as https://phabricator.haskell.org/D5171 -- Sergei pgpfarmiuyzBP.pgp Description: Цифровая подпись OpenPGP ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Setting Up a OpenBSD System for Building GHC Wiki Page
On Wed, 05 Apr 2017 20:58:41 +0200 Karel Gardas wrote: Thanks for starting the page Adam! Trying to wire older python look unusual. ghc-HEAD should work fine with python3. When I tried to build ghc on an fresh OpenBSD install I had to install the following on top: - pkg_add py-sphinx [optional, to get docs] - pkg_add libiconv -- Sergei pgpm4moQUc455.pgp Description: Цифровая подпись OpenPGP ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building head on Openbsd
On Sun, 26 Mar 2017 15:08:50 +0200 Karel Gardas wrote: > On 03/26/17 03:04 PM, Sergei Trofimovich wrote: > > I guess openbsd does not have definition of EM_PPC64 (yet?). > > IIRC it does not. I even remembering to fix this in the past but then > probably forgotten to submit patch... > > Anyway, attempting to duplicate on outdated OpenBSD current from Dec > 2016, but still post 6.0 code so this should be ok... I've tested the following patch https://git.haskell.org/ghc.git/commitdiff/6c73504ac5f4e951062d5e868fa2b69b028b6e79 on amd64-unknown-openbsd6.0. Hope it does not breaks things for you. -- Sergei pgpgfYtePLHHu.pgp Description: Цифровая подпись OpenPGP ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Building head on Openbsd
On Sun, 26 Mar 2017 19:24:07 +0800
Adam Steen wrote:
> Hi
>
> I attempt to build head today on OpenBSD current and failed, but i not sure
> where to start to fix the problems. The full configure and build logs are
> attached. Just a note: ghc-8.0 builds fine, ghc-8.2 fails with the same
> error.
>
> the first error is
...
> rts/linker/Elf.c:539:0: error: warning: unused variable 'secno'
There are just warnings. I think the real error is:
rts/linker/Elf.c:402:0: error:
error: (Each undeclared identifier is reported only once
|
402 | case EM_PPC64: IF_DEBUG(linker,debugBelch( "powerpc64" ));
| ^
I guess openbsd does not have definition of EM_PPC64 (yet?).
Try that to see how far it progresses:
diff --git a/rts/linker/Elf.c b/rts/linker/Elf.c
index 604c3dc..e8f6aab 100644
--- a/rts/linker/Elf.c
+++ b/rts/linker/Elf.c
@@ -400,8 +400,10 @@ ocVerifyImage_ELF ( ObjectCode* oc )
#endif
case EM_PPC: IF_DEBUG(linker,debugBelch( "powerpc32" )); break;
+#ifdef EM_PPC64
case EM_PPC64: IF_DEBUG(linker,debugBelch( "powerpc64" ));
errorBelch("%s: RTS linker not implemented on PowerPC 64-bit",
oc->fileName);
return 0;
+#endif
#ifdef EM_X86_64
case EM_X86_64: IF_DEBUG(linker,debugBelch( "x86_64" )); break;
--
Sergei
pgpaBaMiLGWKx.pgp
Description: Цифровая подпись OpenPGP
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RTS's (old?) invariant regarding OS blocking
On Wed, 2 Mar 2016 16:38:56 +0200 Dan Aloni wrote: > Hi, > > While trying to gain insights into the RTS, I've noticed the following in > the Wiki page [1] on the topic of the scheduler: > > Invariant: a task that holds a capability is not blocked in the operating > system. > > This makes some parts of the system simpler - for example, we can use > spin locks that spin indefinitely, because we can ensure that the spin lock > is only held by a currently executing CPU, and will therefore be released in > a finite (and short) amount of time. > > Does it still apply to modern day GHC, or was it addressed by [2]? It still does apply. Foreign calls are by default 'safe' and executed after Capability is released to a separate OS thread. Capability release is needed as foreign calls can reenter haskell RTS. You can break that invariant and observe the negative effect. For example 'unsafe' foreign call to a blocking function stops all haskell threads happened to be queued on that Capability. Illustration of adverse effect. [1] runs 2 threads: - main thread issues 'safe' and 'unsafe' FFI sleeps - auxiliary thread prints a message on screen every second. 'unsafe_sleep' blocks unrelated haskell thread for 5 seconds while 'safe_sleep' doesn't. We disable SIGVTALARM to not interfere with sleep() system call and use threaded RTS as non-threaded RTS uses SIGVTALARM for thread switching as well. $ ghc --make a.hs -o ./a -rtsopts -threaded && ./a +RTS -V0 -N1 [1 of 1] Compiling Main ( a.hs, a.o ) Linking ./a ... "start unsafe sleep" "thread: enter" "done unsafe sleep" "entering safe sleep" "*** thread: tick" "*** thread: tick" "*** thread: tick" "*** thread: tick" "done safe sleep" "*** thread: tick" "*** thread: tick" "*** thread: tick" "*** thread: tick" "*** thread: tick" "*** thread: tick" "thread: exit" -- [1]: example program a.hs: import Control.Concurrent import Control.Monad import Foreign.C foreign import ccall safe "unistd.h sleep" safe_sleep :: CInt -> IO CInt foreign import ccall unsafe "unistd.h sleep" unsafe_sleep :: CInt -> IO CInt -- sleep for n * 100ms s :: Int -> IO () s slices = threadDelay $ slices * 10^6 main = do t1_lock <- newEmptyMVar t1 <- forkIO $ do print "thread: enter" replicateM_ 10 $ do s 1 print "*** thread: tick" print "thread: exit" putMVar t1_lock () yield -- switch to the ticker print "start unsafe sleep" unsafe_sleep 5 print "done unsafe sleep" print "entering safe sleep" safe_sleep 5 print "done safe sleep" takeMVar t1_lock -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Different behavior in ghci 7.8.3 vs 7.10.1?
On Sat, 27 Jun 2015 07:59:33 -0400 Dominick Samperi wrote: > To test ghci 7.10.1 I compiled from source and simply placed the > resulting bin in my PATH. Perhaps this is not enough? Sounds right. What does 'ghc --info' show? > On the second suggestion, I tried ldd and found that the undefined > symbol is flagged 'B' in the nm output (.bss section). > > This symbol is defined in the shared library, and the output of ghc > -v2 shows that this shared library is > linked without problems on startup of ghci. When the Haskell/FFI > function is run the symbol is undefined. Can you craft a complete small example with a build script that shows the error? -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Different behavior in ghci 7.8.3 vs 7.10.1?
On Fri, 26 Jun 2015 23:05:55 -0400 Dominick Samperi wrote: > Hello, > > I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1 > but this fails. > > Under 7.8.3, when I run from the shell: > export LD_LIBRARY_PATH=thepath > ghci -lmylib -fno-ghci-sandbox mydriver.hs > > I see the usual startup diagnostics along with > Loading object (dynamic) mylib ... done > final link ... done > [1 of 1] Compiling Main > Main> > > But under 7.10.1, when I do the same, there is no indication that > linking happens, and when I try to run the program there are > undefined references. > > I probably missed the post that explains this behavior. Can somebody > provide a pointer to a work-around? There is two separate issues: 1. ghc-7.10 became less chatty when loads libraries. 'ghci -v2' gets it back with a bit of noise 2. looks more like actual problem. is your mylib fully linked against it's depends? LD_LIBRARY_PATH=/the/path ldd -u /path/to/mylib.so LD_LIBRARY_PATH=/the/path ldd /path/to/mylib.so you can also try to inspect LD_DEBUG=help ghci ... -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Playing with the profiler
On Sat, 17 Jan 2015 23:20:30 + Luís Gabriel wrote: > Hi there, > > I'm doing some experiments with the GHC time profiler and I need to add a > new field to the Cost Centre structures. I managed to add the field in the > *CCS.h* header as well as in *codeGen/StgCmmProf.hs* but for some reason > the program is crashing during garbage collection. > > As I have no experience with the GHC internals, I'm having trouble to find > the problem. It would be very nice if someone could give me some clue to > find this bug. > > The patch on GHC as well as the test sample and stack traces can be found > here: https://gist.github.com/luisgabriel/39d51cf4d661c7e62e22 I tried your patch as-is on current ghc-HEAD/amd64 and it works fine. (might easily be another problem) What I am suspicious about is you are using '-prof -debug' and plain 'ghc'. Could it be that you didn't add GhcRTSWays += debug_p in your build.mk after a patch was tweaked last time and some old runtime against new ghc was used? I usually use inplace/bin/ghc-stage2 right after compilation without installation. -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cminusminus.org does not have a link to the spec
On Tue, 16 Sep 2014 20:23:10 + Simon Peyton Jones wrote: > Thanks. This is beyond my competence, and I'm totally submerged anyway. I > suggest you make a Trac ticket about it anyway. Simon Marlow will probably > have an opinion. Today I've found an excuse to actually implement it :) https://phabricator.haskell.org/D622 Reused 'CLOSURE' token and added import CLOSURE id; to existing import id; > | -Original Message----- > | From: Sergei Trofimovich [mailto:sly...@gmail.com] > | Sent: 16 September 2014 19:03 > | To: Simon Peyton Jones > | Cc: Norman Ramsey; ghc-devs; Simon Marlow > | Subject: Re: cminusminus.org does not have a link to the spec > | > | On Mon, 15 Sep 2014 12:05:27 + > | Simon Peyton Jones wrote: > | > | My planned change is for GHC's .cmm files syntax/codegen. > | The idea came out after having stumbled upon a rare ia64 > | bug in GHC's C codegen: > | > | > | http://git.haskell.org/ghc.git/commitdiff/e18525fae273f4c1ad8d6cbe1dea4fc > | 074cac721 > | > | The fundamental bug here is the following: > | Suppose we have two bits of rts: one .c file and one .cmm file > | > | // rts.c defines and exports a function and a variable > | void some_rts_fun (void); > | int some_rts_var; > | > | // rts.cmm uses rts.c's function and variable > | import some_rts_fun; /* this forces C codegen to emit function-like > |'StgFunPtr some_rts_fun ();' > | prototype, it's fine */ > | > | import some_rts_var; /* also forces C codegen to emit function-like > |'StgFunPtr some_rts_var ();' > | prototype, it's broken */ > | // ... > | W whatever = &some_rts_var; /* will pick address not to a real > | variable, but to a > | so called > | function stub, a separate structure > | pointing to real > | 'some_rts_var' */ > | > | I plan to tweak syntax to teach Cmm to distinct between > | imported C global variables/constants, imported Cmm info > | tables(closures), maybe other cases. > | > | I thought of adding haskell-like syntax for imports: > | foreign ccall import some_rts_fun; > | foreign cdata import some_rts_var; > | > | or maybe > | import some_rts_fun; > | import "&some_rts_fun" as some_rts_fun; > | > | This sort of bugs can be easily spotted by whole-program C compiler. > | gcc can do it with -flto option. I basically added to the mk/build.mk: > | SRC_CC_OPTS += -flto > | SRC_LD_OPTS += -flto -fuse-linker-plugin > | SRC_HC_OPTS += -optc-flto > | SRC_HC_OPTS += -optl-flto -optl-fuse-linker-plugin > | and started with './configure --enable-unregisterised' > | > | It immediately shown some of current offenders: > | error: variable 'ghczmprim_GHCziTypes_False_closure' redeclared as > | function > | error: variable 'ghczmprim_GHCziTypes_True_closure' redeclared as > | function > | > | I hope this fuzzy explanation makes some sense. > | > | Thanks! > | > | > Sergei > | > > | > C-- was originally envisaged as a target language for a variety of > | compilers. But in fact LLVM, which was developed at a similar time, > | "won" that race and has built a far larger ecosystem. That's fine with > | us -- it's great how successful LLVM has been -- but it means that C-- is > | now used essentially only in GHC. > | > > | > I'm not sure where the original C-- documents now are; Norman can you > | say? (I do know that the cminusminus.org has lapsed.) > | > > | > The GHC variant of C-- is defined mainly by the Cmm data type in GHC's > | source code. It does have a concrete syntax, because some bits of GHC's > | runtime system are written in Cmm. But I fear that this concrete language > | is not well documented. (Simon Marlow may know more here.) > | > > | > Because GHC's Cmm is part of GHC, we are free to change it. Would you > | like to say more about the change you want to make, and why you want to > | make it? Is this relating directly to GHC or to some other project? > | > > | > Simon > | > > | > > | > | -Original Message- > | > | From: Sergei Trofimovich [mailto:sly...@gmail.com] > | > | Sent: 14 September 2014 17:16 > | > | To: Simon Peyton Jones > | > | Subject: cminusminus.org does not have a link to the spec > | > | > | > | Hello Simon! > | > | > | > | I had
Re: Bash completion in GHC 7.10
On Wed, 10 Dec 2014 16:43:57 +0400 Lennart Kolmodin wrote: > Hi everybody! > > TL;DL GHC 7.10 will have better bash completion, try it out! I'd like your > help to verify the categorisation of DynFlags into ghc / ghci / shared or > hidden flags. Thank you! On the way to users :) https://github.com/gentoo-haskell/gentoo-haskell/commit/d6f63341693063e60168bbddffb0806621696689 sf / # ghc --print-li /usr/lib64/ghc-7.10.0.20141222 sf / # ghci --print-li ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-unknown-linux): ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-unknown-linux): v_unsafeGlobalDynFlags: not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Absolutely not your fault, just makes such things more discoverable :] Thanks again! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc-7.10.1-rc1 build GC log messages
On Wed, 24 Dec 2014 20:27:27 +0100 Tuncer Ayaz wrote: > Building ghc-7.10.1-rc1, I see the following new messages: > > HC [stage 1] compiler/stage2/build/Dwarf.p_o > < residency (8 samples), 103M in use, 0.00 INIT (0.00 elapsed), 0.88 MUT > (1.10 elapsed), 0.76 GC (0.77 elapsed) :ghc>> > > Is this a debug log or normal from now on during a ghc build? > I don't mind, but I just wanted to make sure it's not a mistakenly > enabled debug flag somewhere. It is a normal flag and was present long ago on build system: mk/config.mk.in: GhcHcOpts=-Rghc-timing but happened to break a couple of releases ago. Was fixed in https://ghc.haskell.org/trac/ghc/ticket/8787 You can disable it by putting GhcHcOpts= in mk/build.mk. -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: more parser conflicts?
On Sat, 13 Dec 2014 15:19:34 +
Sergei Trofimovich wrote:
> On Wed, 03 Dec 2014 11:59:42 +
> Simon Marlow wrote:
>
> > >> In unrelated work, I saw this scroll across when happy'ing the parser:
> > >>
> > >>> shift/reduce conflicts: 60
> > >>> reduce/reduce conflicts: 16
> > >>
> > >> These numbers seem quite a bit higher than what I last remember (which
> > >> is something like 48 and 1, not 60 and 16). Does anyone know why?
>
> 4 of reduce/reduce conflicts are result of exact rule copy:
> https://phabricator.haskell.org/D569
>
> > reduce/reduce conflicts are bad, especially so since they're
> > undocumented. We don't know whether this introduced parser bugs or not.
> > Mike - could you look at this please? It was your commit that
> > introduced the new conflicts.
>
> Agreed.
>
> 11 more reduce/reduce (of left 12) came from single scary rule
> added in
> > commit bc2289e13d9586be087bd8136943dc35a0130c88
> >ghc generates more user-friendly error messages
>
> exp10 :: { LHsExpr RdrName }
> ...
> | 'let' binds {% parseErrorSDoc (combineLocs $1 $2) $ text
> "parse error in let binding: missing required
> 'in'"
> }
>
> The other rules add shift/reduce conflicts as follows:
>
> -- parsing error messages go below here
> {- s/r:1 r/r:0 -}
> | '\\' apat apats opt_asig '->' {% parseErrorSDoc (combineLocs $1 $5) $
> text
>"parse error in
> lambda: no expression after '->'"
> {- s/r:1 r/r:0 -}
> | '\\' {% parseErrorSDoc (getLoc
> $1) $ text
>"parse error: naked
> lambda expression '\'"
> }
> {- s/r:1 r/r:0 -}
> | 'let' binds 'in' {% parseErrorSDoc
> (combineLocs $1 $2) $ text
>"parse error in let
> binding: missing expression after 'in'"
> }
> {- s/r:0 r/r:11 -}
> | 'let' binds{% parseErrorSDoc
> (combineLocs $1 $2) $ text
> "parse error in let
> binding: missing required 'in'"
> }
> {- s/r:0 r/r:0 -}
> | 'let' {% parseErrorSDoc
> (getLoc $1) $ text
>"parse error: naked
> let binding"
>}
> {- s/r:1 r/r:0 -}
> | 'if' exp optSemi 'then' exp optSemi 'else' {% hintIf (combineLocs
> $1 $5) "else clause empty" }
> {- s/r:2 r/r:0 -}
> | 'if' exp optSemi 'then' exp optSemi{% hintIf (combineLocs
> $1 $5) "missing required else clause" }
> {- s/r:1 r/r:0 -}
> | 'if' exp optSemi 'then'{% hintIf (combineLocs
> $1 $2) "then clause empty" }
> {- s/r:2 r/r:0 -}
> | 'if' exp optSemi {% hintIf (combineLocs
> $1 $2) "missing required then and else clauses"
> {- s/r:2 r/r:0 -}
> | 'if' {% hintIf (getLoc $1)
> "naked if statement" }
> {- s/r:0 r/r:0 -}
> | 'case' exp 'of'{% parseErrorSDoc
> (combineLocs $1 $2) $ text
> "parse error in case
> statement: missing list after '->'"
> }
> {- s/r:1 r/r:0 -}
> | 'case' exp {% parseErrorSDoc
> (combineLocs $1 $2) $ text
>"parse error in case
> statement: missing required 'of'"
> }
> {- s/r:1 r/r:0 -}
> | 'case' {% parseErrorSDoc
> (getLoc $1) $ text
> "parse error: naked
> case statement"
> }
>
> Shift/reduces look harmless (like MultiWayIf ambiguity)
> as they seem to resolve as shift correctly.
Proposed fix as:
https://phabricator.haskell.org/D571
Simon, is using happy's "error" token the proper way of fixing
these error reporting rules?
Thanks!
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: more parser conflicts?
On Wed, 03 Dec 2014 11:59:42 +
Simon Marlow wrote:
> >> In unrelated work, I saw this scroll across when happy'ing the parser:
> >>
> >>> shift/reduce conflicts: 60
> >>> reduce/reduce conflicts: 16
> >>
> >> These numbers seem quite a bit higher than what I last remember (which
> >> is something like 48 and 1, not 60 and 16). Does anyone know why?
4 of reduce/reduce conflicts are result of exact rule copy:
https://phabricator.haskell.org/D569
> reduce/reduce conflicts are bad, especially so since they're
> undocumented. We don't know whether this introduced parser bugs or not.
> Mike - could you look at this please? It was your commit that
> introduced the new conflicts.
Agreed.
11 more reduce/reduce (of left 12) came from single scary rule
added in
> commit bc2289e13d9586be087bd8136943dc35a0130c88
>ghc generates more user-friendly error messages
exp10 :: { LHsExpr RdrName }
...
| 'let' binds {% parseErrorSDoc (combineLocs $1 $2) $ text
"parse error in let binding: missing required 'in'"
}
The other rules add shift/reduce conflicts as follows:
-- parsing error messages go below here
{- s/r:1 r/r:0 -}
| '\\' apat apats opt_asig '->' {% parseErrorSDoc (combineLocs $1 $5) $ text
"parse error in lambda:
no expression after '->'"
{- s/r:1 r/r:0 -}
| '\\' {% parseErrorSDoc (getLoc $1)
$ text
"parse error: naked
lambda expression '\'"
}
{- s/r:1 r/r:0 -}
| 'let' binds 'in' {% parseErrorSDoc (combineLocs
$1 $2) $ text
"parse error in let
binding: missing expression after 'in'"
}
{- s/r:0 r/r:11 -}
| 'let' binds{% parseErrorSDoc
(combineLocs $1 $2) $ text
"parse error in let
binding: missing required 'in'"
}
{- s/r:0 r/r:0 -}
| 'let' {% parseErrorSDoc (getLoc
$1) $ text
"parse error: naked let
binding"
}
{- s/r:1 r/r:0 -}
| 'if' exp optSemi 'then' exp optSemi 'else' {% hintIf (combineLocs $1
$5) "else clause empty" }
{- s/r:2 r/r:0 -}
| 'if' exp optSemi 'then' exp optSemi{% hintIf (combineLocs $1
$5) "missing required else clause" }
{- s/r:1 r/r:0 -}
| 'if' exp optSemi 'then'{% hintIf (combineLocs $1
$2) "then clause empty" }
{- s/r:2 r/r:0 -}
| 'if' exp optSemi {% hintIf (combineLocs $1
$2) "missing required then and else clauses"
{- s/r:2 r/r:0 -}
| 'if' {% hintIf (getLoc $1)
"naked if statement" }
{- s/r:0 r/r:0 -}
| 'case' exp 'of'{% parseErrorSDoc
(combineLocs $1 $2) $ text
"parse error in case
statement: missing list after '->'"
}
{- s/r:1 r/r:0 -}
| 'case' exp {% parseErrorSDoc
(combineLocs $1 $2) $ text
"parse error in case
statement: missing required 'of'"
}
{- s/r:1 r/r:0 -}
| 'case' {% parseErrorSDoc (getLoc
$1) $ text
"parse error: naked
case statement"
}
Shift/reduces look harmless (like MultiWayIf ambiguity)
as they seem to resolve as shift correctly.
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: Improving the LLVM backend by packaging it
On Fri, 24 Oct 2014 18:52:53 -0500 Austin Seipp wrote: > I won't repeat what's on the wiki page too much, but the TL;DR version > is: we should start packaging a version of LLVM, and shipping it with > e.g. binary distributions of GHC. It's just a lot better for everyone. > > I know we're normally fairly hesitant about things like this (shipping > external dependencies), but I think it's the only sane thing to do > here, and the situation is fairly unique in that it's not actually > very complicated to implement or support, I think. That makes a lot of sense! Gentoo allows user upgrade llvm and ghc independently, which makes syncing harder. Thus Gentoo does not care much about llvm support in ghc. -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cminusminus.org does not have a link to the spec
On Mon, 15 Sep 2014 12:05:27 + Simon Peyton Jones wrote: My planned change is for GHC's .cmm files syntax/codegen. The idea came out after having stumbled upon a rare ia64 bug in GHC's C codegen: http://git.haskell.org/ghc.git/commitdiff/e18525fae273f4c1ad8d6cbe1dea4fc074cac721 The fundamental bug here is the following: Suppose we have two bits of rts: one .c file and one .cmm file // rts.c defines and exports a function and a variable void some_rts_fun (void); int some_rts_var; // rts.cmm uses rts.c's function and variable import some_rts_fun; /* this forces C codegen to emit function-like 'StgFunPtr some_rts_fun ();' prototype, it's fine */ import some_rts_var; /* also forces C codegen to emit function-like 'StgFunPtr some_rts_var ();' prototype, it's broken */ // ... W whatever = &some_rts_var; /* will pick address not to a real variable, but to a so called function stub, a separate structure pointing to real 'some_rts_var' */ I plan to tweak syntax to teach Cmm to distinct between imported C global variables/constants, imported Cmm info tables(closures), maybe other cases. I thought of adding haskell-like syntax for imports: foreign ccall import some_rts_fun; foreign cdata import some_rts_var; or maybe import some_rts_fun; import "&some_rts_fun" as some_rts_fun; This sort of bugs can be easily spotted by whole-program C compiler. gcc can do it with -flto option. I basically added to the mk/build.mk: SRC_CC_OPTS += -flto SRC_LD_OPTS += -flto -fuse-linker-plugin SRC_HC_OPTS += -optc-flto SRC_HC_OPTS += -optl-flto -optl-fuse-linker-plugin and started with './configure --enable-unregisterised' It immediately shown some of current offenders: error: variable 'ghczmprim_GHCziTypes_False_closure' redeclared as function error: variable 'ghczmprim_GHCziTypes_True_closure' redeclared as function I hope this fuzzy explanation makes some sense. Thanks! > Sergei > > C-- was originally envisaged as a target language for a variety of compilers. > But in fact LLVM, which was developed at a similar time, "won" that race and > has built a far larger ecosystem. That's fine with us -- it's great how > successful LLVM has been -- but it means that C-- is now used essentially > only in GHC. > > I'm not sure where the original C-- documents now are; Norman can you say? (I > do know that the cminusminus.org has lapsed.) > > The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source > code. It does have a concrete syntax, because some bits of GHC's runtime > system are written in Cmm. But I fear that this concrete language is not well > documented. (Simon Marlow may know more here.) > > Because GHC's Cmm is part of GHC, we are free to change it. Would you like > to say more about the change you want to make, and why you want to make it? > Is this relating directly to GHC or to some other project? > > Simon > > > | -Original Message- > | From: Sergei Trofimovich [mailto:sly...@gmail.com] > | Sent: 14 September 2014 17:16 > | To: Simon Peyton Jones > | Subject: cminusminus.org does not have a link to the spec > | > | Hello Simon! > | > | I had a plan to tweak a bit "import" statement > | syntax of Cmm in GHC. > | > | Namely, to distinct between > | import some_c_function; > | import some_c_global_variable; > | > | To try it I first attempted to find latest c-- spec > | (to find some design sketches if available) at > | > | http://www.cminusminus.org/c-downloads/ > | > | But seems the links (and images?) have gone away > | as well as rsync server described at: > | > | http://www.cminusminus.org/the-c-rsync-server/ > | > | Maybe you could forward it to site admins so they would > | tweak links or point me to working copy. > | > | Apologies for bothering you on such minor > | > | Thank you! > | > | -- > | > | Sergei -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status updates
On Tue, 9 Sep 2014 08:34:03 -0500 Austin Seipp wrote: > - Sergei spent some time filing bugs that we should fix in the > testsuite, because they fail --slow validate. I believe these are two > of them: > > - https://ghc.haskell.org/trac/ghc/ticket/9567 > - https://ghc.haskell.org/trac/ghc/ticket/9566 Yeah, I believe the complete list for --slow is only 5 failures: https://ghc.haskell.org/trac/ghc/ticket/9565 - dead loop in simplifier https://ghc.haskell.org/trac/ghc/ticket/9424 - debugged ghc does not unload Show instances after data redefinition (or not :]) https://ghc.haskell.org/trac/ghc/ticket/9426 - something similar with redefinition in ghci https://ghc.haskell.org/trac/ghc/ticket/9566 - corelint error in simplifier https://ghc.haskell.org/trac/ghc/ticket/9567 - another corelint error in simplifier -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
validate --slow bugs (was Re: Status updates)
On Wed, 3 Sep 2014 15:31:03 -0500
Austin Seipp wrote:
> Hi *,
>
> Here are some status updates for the past week, which have been a bit light.
Woot! Great list!
> - I still think we should turn on --slow mode for our buildbots soon,
> but this will cause noise. I'd really like some inputs on this - maybe
> someone would like to help clean up the 'slow' vaildate failures?
> Bonus points for this, since you don't even have to
That's a great goal, but --slow enables compiler debug assertions,
which seem to trigger real errors (full log of failures attached).
I've filled tickets for some of those assertion failures.
If someone more experienced in the area could guide us
hints on how to fix them (CCed Simon PJ).
If they all are non-issues please tell and I'll drop them.
If they are real bugs I can try to debug them a bit
and gather more info (maybe something specific is of interest?).
Highlights:
*** unexpected failure for T3500b(threaded2)
=> T3500b(dyn) 3766 of 4100 [0, 12, 0]
cd ./typecheck/should_run &&
'/home/slyfox/dev/git/ghc-validate/bindisttest/install dir/bin/ghc'
-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
-rtsopts -fno-ghci-history -o T3500b T3500b.hs -O -dynamic
>T3500b.comp.stderr 2>&1
Compile failed (status 256) errors were:
[1 of 1] Compiling Main ( T3500b.hs, T3500b.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.9.20140905 for x86_64-unknown-linux):
Simplifier ticks exhausted
When trying RuleFired foldr/augment
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 12441
Is it bad?
cd ./ghc-api && $MAKE -s --no-print-directory T8628T8628.run.stdout 2>T8628.run.stderr
Actual stderr output differs from expected:
--- /dev/null 2014-08-25 09:46:54.593424088 +0300
+++ ./ghc-api/T8628.run.stderr 2014-09-05 22:49:20.705589132 +0300
@@ -0,0 +1,4 @@
+WARNING: file compiler/simplCore/SimplEnv.lhs, line 539
+Ghci3.$fShowX
+WARNING: file compiler/simplCore/SimplEnv.lhs, line 539
+Ghci3.$fShowX
*** unexpected failure for T8628(normal)
This looks nasty.
=> tc124(hpc) 3135 of 4100 [0, 3, 0]
cd ./typecheck/should_compile &&
'/home/slyfox/dev/git/ghc-validate/bindisttest/install dir/bin/ghc'
-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
-rtsopts -fno-ghci-history -c tc124.hs -O -fhpc -hpcdir .hpc.tc124
-fno-warn-incomplete-patterns >tc124.comp.stderr 2>&1
Compile failed (status 256) errors were:
*** Core Lint errors : in result of Simplifier ***
: Warning:
In the type ‘a_12 -> a_aia -> a_aia’
@ a_12 is out of scope
*** Offending Program ***
Foo.f :: Foo.T -> (GHC.Types.Int, GHC.Types.Char)
[LclIdX,
Arity=1,
Str=DmdType,
Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True,
WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 90 30}]
This also looks scary.
Thanks!
--
Sergei
make -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt
make[1]: ÐÑ
од в каÑалог
`/home/slyfox/dev/git/ghc-validate/testsuite/tests'
python2 ../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp
-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e
ghc_debugged=True -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e
ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e
ghc_with_dynamic_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e
ghc_dynamic_by_default=False -e ghc_dynamic=True -e ghc_with_smp=1 -e
ghc_with_llvm=1 -e windows=False -e darwin=False -e in_tree_compiler=True -e
clean_only=False --rootdir=. --config=../config/ghc -e
'config.confdir="../config"' -e
'config.compiler="/home/slyfox/dev/git/ghc-validate/bindisttest/install
dir/bin/ghc"' -e
'config.ghc_pkg="/home/slyfox/dev/git/ghc-validate/bindisttest/install
dir/bin/ghc-pkg"' -e
'config.hp2ps="/home/slyfox/dev/git/ghc-validate/bindisttest/install
dir/bin/hp2ps"' -e
'config.hpc="/home/slyfox/dev/git/ghc-validate/bindisttest/install
dir/bin/hpc"' -e 'config.gs="gs"' -e 'config.platform="x86_64-unknown-linux"'
-e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e
'default_testopts.cleanup="1"' -e 'config.timeout=int() or config.timeout' -e
'config.timeout_prog="../timeout/install-inplace/bin/timeout"' -e
'config.exeext=""' -e
'config.top="/home/slyfox/dev/git/ghc-validate/testsuite"' --output-summary
"../../testsuite_summary.txt" --rootdir=../../libraries/array/tests
--rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests
--rootdir=../../libraries/bytestring/tests
--rootdir=../../libraries/containers/tests
--roo
Re: Building HEAD (e83e873d) on mips64el: unknown package: old-locale-1.0.0.6
On Tue, 02 Sep 2014 08:48:22 +0400 Nikita Karetnikov wrote: > > I have happened to find seemingly related bug in PIC handing > > on other PIC-sensitive RISCs: > > > > https://phabricator.haskell.org/D177 (also in ghc's master) > > > > I think it might help you to get ghci on your mipsel. > > Thanks for your work. Is it necessary to do anything special in order > to build GHCi except the usual ‘./sync-all get && perl boot && > ./configure && make’? Yeah, those commands should be enough. -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building HEAD (e83e873d) on mips64el: unknown package: old-locale-1.0.0.6
On Thu, 14 Aug 2014 01:30:00 +0400 Nikita Karetnikov wrote: > /usr/bin/ld: rts/dist/build/Adjustor.dyn_o: relocation R_MIPS_HI16 against > `__gnu_local_gp' can not be used when making a shared object; recompile with > -fPIC > rts/dist/build/Adjustor.dyn_o: could not read symbols: Bad value > collect2: ld returned 1 exit status > make[1]: *** [rts/dist/build/libHSrts-ghc7.9.20140809.so] Error 1 > make[1]: *** Waiting for unfinished jobs > make: *** [all] Error 2 Hi Nikita! I have happened to find seemingly related bug in PIC handing on other PIC-sensitive RISCs: https://phabricator.haskell.org/D177 (also in ghc's master) I think it might help you to get ghci on your mipsel. Thanks in advance! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Raft of optimiser changes
On Thu, 28 Aug 2014 11:16:03 + Simon Peyton Jones wrote: > I've just pushed a bunch of Core-to-Core optimisation changes that have been > sitting in my tree for ages. The aggregate effect on nofib is very modest, > but they are mostly aimed at corner cases, and consolidation. > > Program SizeAllocs Runtime Elapsed TotalMem > > Min -7.2% -3.1% -7.8% -7.8%-14.8% > > Max +5.6% +1.3%+20.0%+19.7%+50.0% > > Geometric Mean -0.3% -0.1% +1.7% +1.7% +0.2% > The runtime increases are spurious - I checked. > A couple of perf/compiler tests (i.e. GHC's own performance) improve > significantly, which is a good sign. > I have a few more to come but wanted to get this lot out of my hair. Hello Simon! The compiler improvements look great! Although running 'fulltest' one test caught core lint error: >typecheck/should_compile T7891 [exit code non-0] > (hpc,optasm,profasm,optllvm) It can be reran as: $ make fulltest THREADS=12 TEST=T7891 The result of optasm run: => T7891(optasm) 3365 of 4096 [0, 0, 0] cd ./typecheck/should_compile && '/home/slyfox/dev/git/ghc-validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7891.hs -O -fasm -fno-warn-incomplete-patterns >T7891.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Simplifier *** : Warning: In the type ‘a_12 -> t_aiE -> t_aiE’ @ a_12 is out of scope (attached it's complete output) Thank you! -- Sergei make -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt make[1]: Entering directory `/home/slyfox/dev/git/ghc-validate/testsuite/tests' python2 ../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=1 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=True -e ghc_with_smp=1 -e ghc_with_llvm=1 -e windows=False -e darwin=False -e in_tree_compiler=True --threads=12 -e clean_only=False --rootdir=. --config=../config/ghc -e 'config.confdir="../config"' -e 'config.compiler="/home/slyfox/dev/git/ghc-validate/inplace/bin/ghc-stage2"' -e 'config.ghc_pkg="/home/slyfox/dev/git/ghc-validate/inplace/bin/ghc-pkg"' -e 'config.hp2ps="/home/slyfox/dev/git/ghc-validate/inplace/bin/hp2ps"' -e 'config.hpc="/home/slyfox/dev/git/ghc-validate/inplace/bin/hpc"' -e 'config.gs="gs"' -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'default_testopts.cleanup="1"' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../timeout/install-inplace/bin/timeout"' -e 'config.exeext=""' -e 'config.top="/home/slyfox/dev/git/ghc-validate/testsuite"' --output-summary "../../testsuite_summary.txt" --rootdir=../../libraries/array/tests --rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests --rootdir=../../libraries/bytestring/tests --rootdir=../../libraries/containers/tests --rootdir=../../libraries/directory/tests --rootdir=../../libraries/filepath/tests --rootdir=../../libraries/ghc-prim/tests --rootdir=../../libraries/haskeline/tests --rootdir=../../libraries/hpc/tests --rootdir=../../libraries/old-time/tests --rootdir=../../libraries/parallel/tests --rootdir=../../libraries/pretty/tests --rootdir=../../libraries/process/tests --rootdir=../../libraries/stm/tests --rootdir=../../libraries/template-haskell/tests --rootdir=../../libraries/unix/tests --rootdir=../../libraries/containers/tests-ghc \ --only=T7891 \ \ --way=optasm \ \ \ \ Error: /undefined in This Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop 1899 1 3 %oparray_pop 1883 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1172/1684(ro)(G)-- --dict:0/20(G)-- --dict:77/200(L)-- Current allocation mode is local Current file position is 5 gs -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE ../config/good.ps gs -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE ../config/bad.ps GhostScript available for hp2ps tests Timeout is 300 Found 269 .T files... Beginning test run at Sat Aug 30 13:36:37 2014 FET > Scanning ./annotations/should_compile/all.T > Scannin
Re: clang warnings with unregisterised
On Fri, 29 Aug 2014 02:56:01 +0200
Gabor Greif wrote:
> Devs,
>
> I have built an UNREGISTERISED GHC, and the C-compiler used behind the
> scenes is clang. Now I get literally millions of warnings of the below
> kind:
>
>
> +/var/folders/k9/fj_1d5h17m7c4gbyp2srqrhmgq/T/ghc11601_0/ghc11601_4.hc:688:1:
> + warning: attribute declaration must precede definition
> [-Wignored-attributes]
> +II_(s4Vv_closure);
> +^
> +
> +/Users/ggreif/ghc-head/includes/Stg.h:213:63:
> + note: expanded from macro 'II_'
> +#define II_(X) static StgWordArray (X) GNU_ATTRIBUTE(aligned (8))
> + ^
> +
> +/Users/ggreif/ghc-head/includes/Stg.h:175:42:
> + note: expanded from macro 'GNU_ATTRIBUTE'
> +#define GNU_ATTRIBUTE(at) __attribute__((at))
> + ^
> +
> +/var/folders/k9/fj_1d5h17m7c4gbyp2srqrhmgq/T/ghc11601_0/ghc11601_4.hc:588:16:
> + note: previous definition is here
> +static StgWord s4Vv_closure[] = {
> + ^
>
> It seems like the "II_" and "EI_" prototypes *follow* the real thing,
> and because clang is more picky with attribute placement, we get all
> those warnings.
They just occur many times in the source, thus not only before but also after
definition.
> compiler/cmm/PprC.hs:pprExternDecl is the function that puts together
> the "II_(...)" and "EI_(...)", but where does the "static StgWord
> s4Vv_closure[] = {" come from?
pprWordArray :: CLabel -> [CmmStatic] -> SDoc
> I just want to flip the order of their occurrence.
I think it would be a good thing to split .hc file lifting
all external and local declarations up (and print only
unique ones). It should shrink .hc file size a bit and
make it nicer to read.
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: making ./validate run tests on all CPUs by default
On Wed, 13 Aug 2014 11:39:56 +0200 Tuncer Ayaz wrote: > On Tue, Aug 12, 2014 at 10:31 PM, Sergei Trofimovich wrote: > > Good evening all! > > > > Currently when being ran './validate' script (without any parameters): > > - builds ghc using 2 parallel jobs > > - runs testsuite using 2 parallel jobs > > > > I propose to change the default value to amount of available CPUs: > > - build ghc using N+1 parallel jobs > > - run testsuite using N+1 parallel jobs > > > > Pros: > > - first-time users will get faster ./validate > > - seasoned users will need less tweaking for buildbots > > > > Cons: > > - for imbalanced boxes (32 cores, 8GB RAM) it might > >be quite painful to drag box out of swap > > > > What do you think about it? > > Isn't the memory use also a problem on boxes with a much lower > number of cores (e.g. 7.8 space leak(s))? > > On one machine with 1GB per core, I had to limit cabal install's > parallelism when using 7.8. It's true in general, but I would not expect such a massive growth on ghc source. Current -Rghc-timing shows ~300MBs per ghc process on amd64. The fallout examples are HsSyn and cabal's PackageDescription modules. ghc's build system is a bit different from Cabal's: - Cabal runs one 'ghc --make' instance for a whole package. It leads to massive RAM usage in case of a multitude of modules (highlighting-kate and qthaskell come to mind). - ghc's buld system uses one 'ghc -c' execution for a single .hs file (roughly) > Assuming the patch goes in, is there a way to limit parallel jobs > on the command line? The mechanism to set limit manually is the same as before: CPUS=8 ./validate It's the default that is proposed to be changed. -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
making ./validate run tests on all CPUs by default
Good evening all! Currently when being ran './validate' script (without any parameters): - builds ghc using 2 parallel jobs - runs testsuite using 2 parallel jobs I propose to change the default value to amount of available CPUs: - build ghc using N+1 parallel jobs - run testsuite using N+1 parallel jobs Pros: - first-time users will get faster ./validate - seasoned users will need less tweaking for buildbots Cons: - for imbalanced boxes (32 cores, 8GB RAM) it might be quite painful to drag box out of swap What do you think about it? Actual patch: https://phabricator.haskell.org/D146 Thanks! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)
On Thu, 07 Aug 2014 15:42:07 +0100
Simon Marlow wrote:
> On 06/08/2014 21:40, Sergei Trofimovich wrote:
> > I think I know what happens. According to perf the benchmark spends 34%+
> > of time in garbage collection ('perf record -- $args'/'perf report'):
> >
> >27,91% test test [.] evacuate
> > 9,29% test test [.] s9Lz_info
> > 7,46% test test [.] scavenge_block
> >
> > And the whole benchmark runs a tiny bit more than 300ms.
> > It is exactly in line with major GC timer (0.3s).
>
> 0.3s is the *idle* GC timer, it has no effect when the program is
> running normally. There's no timed GC or anything like that.
>
> It sometimes happens that a tiny change somewhere tips a program over
> into doing one more major GC, though.
>
> > If we run
> > $ time ./test inverter 345 10n 4u 1>/dev/null
> > multiple times there is heavy instability in there (with my patch reverted):
> > real0m0.319s
> > real0m0.305s
> > real0m0.307s
> > real0m0.373s
> > real0m0.381s
> > which is +/- 80ms drift!
> >
> > Let's try to kick major GC earlier instead of running right at runtime
> > shutdown time:
> > $ time ./test inverter 345 10n 4u +RTS -I0.1 1>/dev/null
> >
> > real0m0.304s
> > real0m0.308s
> > real0m0.302s
> > real0m0.304s
> > real0m0.308s
> > real0m0.306s
> > real0m0.305s
> > real0m0.312s
> > which is way more stable behaviour.
> >
> > Thus my theory is that my changed stepped from
> >"90% of time 1 GC run per run"
> > to
> >"90% of time 2 GC runs per run"
>
> Is this program idle? I have no idea why this might be happening! If
> the program is busy computing stuff, the idle GC should not be firing.
> If it is, that's a bug.
The task is a completely CPU-bound thing.
Then I was very lucky to get that change with -I option.
I'll try to find exact place where profiling times change (or just float),
but it will take more time.
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)
On Wed, 6 Aug 2014 22:15:34 +0300
Sergei Trofimovich wrote:
> On Wed, 06 Aug 2014 09:30:45 +0200
> Joachim Breitner wrote:
>
> > Hi,
> >
> > the attached commit seems to have regressed the scs nofib benchmark by
> > ~3%:
> > http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scs&env=1#/?exe=2&base=2+68&ben=nofib/time/scs&env=1&revs=50&equid=on
>
> That's a test of compiled binary performance, not the compiler, right?
>
> > The graph unfortunately is in the wrong order, as the tool gets confused
> > by timezones and by commits with identical CommitDate, e.g. due to
> > rebasing. This needs to be fixed, I manually verified that the commit
> > below is the first that shows the above-noise-level-increase of runtime.
> >
> > (Other benchmarks seem to be unaffected.)
> >
> > Is this regression expected and intended or unexpected? Is it fixable?
> > Or is is this simply inexplicable?
>
> The graph looks mysterious (18 ms bump). Bencmark does not use haskell
> threads at all.
>
> I'll try to reproduce degradation locally and will investigate.
I think I know what happens. According to perf the benchmark spends 34%+
of time in garbage collection ('perf record -- $args'/'perf report'):
27,91% test test [.] evacuate
9,29% test test [.] s9Lz_info
7,46% test test [.] scavenge_block
And the whole benchmark runs a tiny bit more than 300ms.
It is exactly in line with major GC timer (0.3s).
If we run
$ time ./test inverter 345 10n 4u 1>/dev/null
multiple times there is heavy instability in there (with my patch reverted):
real0m0.319s
real0m0.305s
real0m0.307s
real0m0.373s
real0m0.381s
which is +/- 80ms drift!
Let's try to kick major GC earlier instead of running right at runtime
shutdown time:
$ time ./test inverter 345 10n 4u +RTS -I0.1 1>/dev/null
real0m0.304s
real0m0.308s
real0m0.302s
real0m0.304s
real0m0.308s
real0m0.306s
real0m0.305s
real0m0.312s
which is way more stable behaviour.
Thus my theory is that my changed stepped from
"90% of time 1 GC run per run"
to
"90% of time 2 GC runs per run"
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding
On Wed, 2 Jul 2014 14:59:13 -0500 Austin Seipp wrote: > Hi *, > > First off, WARNING: BIKESHEDDING AHEAD. > > With that out of the way - today on IRC, there was some discussion > about some stylistic/consistency issues in GHC, and being spurred by > Johans recent proposal for top-level documentation, I figured perhaps > we should beat the drum on this issue as well. > > The TL;DR is that GHC has a lot of inconsistent style issues, > including things like: > > - Mixing literate haskell with non-literate haskell files > - Legacy code with tabs and spaces intermixed > - Related to the last one, trailing whitespace > - Mixing styles of do notation in different parts of the compiler > (braces vs no braces) > - Probably things like indentation mismatches even in the same code > - Probably many other things I've missed, obvious or not. I'd vote for detabbing/un-.lhs-ing in one go and ASAP. Fore example, this weekend. There will always be people creating derivative work on top of current source tree. I, for example, didn't dare to detab rts bits to make patches readable. Detabbing commits are very easy to check in git: 'git show -w' (should output nothing). It's a pain for current patches, but I'd say it's bearable. The rest of changes are harder to achieve, but should be quite easy to maintain with hlint forcing one rule (everyone agree on) at a time. -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cc & ld extra flags
On Sat, 28 Jun 2014 08:31:41 -0700 Mark Lentczner wrote: > I'd like to build GHC, and all the base libs, with an extra flag supplied > to cc (well gcc) and ld commands: > > I thought I could just add this to mk/build.mk: > > SRC_CC_OPTS = -mmacos-version-min=10.7 > SRC_LD_OPTS = -mmacos-version-min=10.7 > But this seems very inconsistently applied. For example: Hi Mark! The best way to set all 3 vars: SRC_CC_OPTS = -mmacos-version-min=10.7 SRC_LD_OPTS = -mmacos-version-min=10.7 SRC_HC_OPTS = -optc-mmacos-version-min=10.7 -optl-mmacos-version-min=10.7 and, maybe even -optP. CC/LD_OPTS is more for non-haskell code from build system perspective. http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#forcing-options-through -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage (+patch)
On Wed, 11 Jun 2014 21:35:57 +0300 Sergei Trofimovich wrote: > On Wed, 11 Jun 2014 08:18:30 + > Simon Peyton Jones wrote: > > > Stefan, Guys > > This commit breaks the Windows build (ie my laptop) > > > > commit 9fd507e5758f4141ac2619f0db57136bcab035c6 > > > > Author: Sergei Trofimovich > > > > Date: Fri May 23 23:58:06 2014 +0300 > > > > > > > > Raise exceptions when blocked in bad FDs (fixes Trac #4934) > > The breakage is this: > > > > C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa): > > undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure' > > The reason is, I think that that this line in RtsStartup.c should be inside > > the guard #ifndef mingw32_HOST_OS > > > > getStablePtr((StgPtr)blockedOnBadFD_closure); > > I'd do that myself but I am not confident that the fix is correct; and I > > would like to add a comment to explain why the getStablePtr is > > non-windows-only. > > Can someone do this, please? > > Oh, I've missed the fact GHC.Event.Thread in a non-windows thing. > The whole patch was for posix-only platform, but i tried to export > that exception for all platforms. > > CCed Simon M. > > There is 2 routes: > a) move an exception a common module to all platforms. > For example to Foreign.C.Error (I've started to prepare a patch) To avoid import loops and make things clear I've moved it to GHC.Exception.RTS (other from-rts exceptions can be pushded there as well) Patch is in attach. Please review. Thank you! -- Sergei From 9fd22821be997c5b75b84c3528351e8dc678882f Mon Sep 17 00:00:00 2001 From: Sergei Trofimovich Date: Wed, 11 Jun 2014 22:18:41 +0300 Subject: [PATCH] rts: fix linkage on windows (missing blockedOnBadFD_closure) commit 9fd507e5758f4141ac2619f0db57136bcab035c6 declared to RTS exception object, but defined it in UNIX-specific module GHC.Event.Thread. It led to linkage error: C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa): undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure' Fixed by moving exception object to separate module GHC.Exception.RTS. Reported-by: Simon Peyton Jones Signed-off-by: Sergei Trofimovich --- libraries/base/GHC/Event/Thread.hs | 7 +-- libraries/base/GHC/Exception/RTS.hs | 25 + libraries/base/base.cabal | 1 + rts/Prelude.h | 4 ++-- rts/package.conf.in | 4 ++-- rts/win32/libHSbase.def | 2 +- 6 files changed, 32 insertions(+), 11 deletions(-) create mode 100644 libraries/base/GHC/Exception/RTS.hs diff --git a/libraries/base/GHC/Event/Thread.hs b/libraries/base/GHC/Event/Thread.hs index 6e991bf..eb6b6c7 100644 --- a/libraries/base/GHC/Event/Thread.hs +++ b/libraries/base/GHC/Event/Thread.hs @@ -12,10 +12,9 @@ module GHC.Event.Thread , closeFdWith , threadDelay , registerDelay -, blockedOnBadFD -- used by RTS ) where -import Control.Exception (finally, SomeException, toException) +import Control.Exception (finally) import Control.Monad (forM, forM_, sequence_, zipWithM, when) import Data.IORef (IORef, newIORef, readIORef, writeIORef) import Data.List (zipWith3) @@ -116,10 +115,6 @@ threadWait evt fd = mask_ $ do then ioError $ errnoToIOError "threadWait" eBADF Nothing Nothing else return () --- used at least by RTS in 'select()' IO manager backend -blockedOnBadFD :: SomeException -blockedOnBadFD = toException $ errnoToIOError "awaitEvent" eBADF Nothing Nothing - threadWaitSTM :: Event -> Fd -> IO (STM (), IO ()) threadWaitSTM evt fd = mask_ $ do m <- newTVarIO Nothing diff --git a/libraries/base/GHC/Exception/RTS.hs b/libraries/base/GHC/Exception/RTS.hs new file mode 100644 index 000..9892e6e --- /dev/null +++ b/libraries/base/GHC/Exception/RTS.hs @@ -0,0 +1,25 @@ +- +-- | +-- Module : GHC.Exception +-- Copyright : (c) The University of Glasgow, 1998-2002 +-- License : see libraries/base/LICENSE +-- +-- Maintainer : cvs-...@haskell.org +-- Stability : internal +-- Portability : non-portable (GHC extensions) +-- +-- Exceptions thrown by C RTS code. +-- +- + +module GHC.Exception.RTS +( +blockedOnBadFD +) where + +import Control.Exception +import Foreign.C.Error + +-- used at least by RTS in 'select()' IO manager backend +blockedOnBadFD :: SomeException +blockedOnBadFD = toException $ errnoToIOError "awaitEvent" eBADF Nothing Nothing diff --git a/libraries/base/base.cabal b
Re: Failed to load interface for GHC.Integer.Type
On Mon, 9 Jun 2014 23:56:37 +0300 Sergei Trofimovich wrote: > On Mon, 09 Jun 2014 21:45:27 +0200 > Joachim Breitner wrote: > > > Hi, > > > > since > > http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd6501abd98 > > travis is complaining: > > > > > > HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot > > HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o > > HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o > > > > Top level: > > Failed to load interface for ‘GHC.Integer.Type’ > > There are files missing in the ‘integer-gmp’ package, > > try running 'ghc-pkg check'. > > Use -v to see a list of the files searched for. > > make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Error 1 > > make[1]: *** Waiting for unfinished jobs > > make: *** [all] Error 2 > > > > Does anyone have an idea what may be causing this? > > A bit more context here is haddock started too early: > > Writing utils/haddock/doc/haddock/invoking.html for chapter(invoking) > cp libffi/build/inst/lib/libffi.a rts/dist/build/libCffi.a > HC [stage 1] libraries/base/dist-install/build/GHC/IO.o-boot > HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Classes.o > Writing utils/haddock/doc/haddock/ch03s02.html for section > Writing utils/haddock/doc/haddock/ch03s03.html for section > HC [stage 1] libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Prim.o > Writing utils/haddock/doc/haddock/ch03s04.html for section > Writing utils/haddock/doc/haddock/ch03s05.html for section > Writing utils/haddock/doc/haddock/hyperlinking.html for section(hyperlinking) > Writing utils/haddock/doc/haddock/module-attributes.html for > section(module-attributes) > HC [stage 1] libraries/base/dist-install/build/GHC/Exception.o-boot > HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/CString.o > Writing utils/haddock/doc/haddock/ch03s08.html for section > Writing utils/haddock/doc/haddock/markup.html for chapter(markup) > HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot > HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o > > Top level: > Failed to load interface for ‘GHC.Integer.Type’ > There are files missing in the ‘integer-gmp’ package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] ... > > I guess real fault is: > http://ghc.haskell.org/trac/ghc/changeset/f31b042c25b9c51efdbe84c1cb6f65f49534c14d/ghc Or not. Looks like it's easy to reproduce as: $ make libraries/base/dist-install/build/Data/Coerce.o V=1 What is more interesting: ghc/libraries/base/Unsafe/Coerce.hs: > import GHC.Integer () -- for build ordering Attached patch fixes the error, but I have no idea why. Maybe, NoImplicitPrelude is not enough and some types leak in here? Maybe Ian (CCed) remembers the story. > commit aba043a0a142ef0ee66ed0e6cbfe2a39c65d8792 > Author: Ian Lynagh > Date: Sun May 19 16:35:40 2013 +0100 > > Fix build order when building with integer-simple > > The problem hasn't shown up with integer-gmp, but I can't see > why it couldn't happen in that case too. -- Sergei From 1b2d13b5d14917c39c88bd237531d5cb96944910 Mon Sep 17 00:00:00 2001 From: Sergei Trofimovich Date: Tue, 10 Jun 2014 01:05:10 +0300 Subject: [PATCH] Data/Coerce.hs: add GHC.Integer as a depend to coerce MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Same as commit aba043a0a142ef0ee66ed0e6cbfe2a39c65d8792 for Unsafe.Coerce. Top level: Failed to load interface for âGHC.Integer.Typeâ There are files missing in the âinteger-gmpâ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Signed-off-by: Sergei Trofimovich --- libraries/base/Data/Coerce.hs | 1 + 1 file changed, 1 insertion(+) diff --git a/libraries/base/Data/Coerce.hs b/libraries/base/Data/Coerce.hs index 9199835..01a1b85 100644 --- a/libraries/base/Data/Coerce.hs +++ b/libraries/base/Data/Coerce.hs @@ -23,5 +23,6 @@ module Data.Coerce ( -- * Safe coercions coerce, Coercible, ) where +import GHC.Integer () -- for build ordering import GHC.Prim (coerce) import GHC.Types (Coercible) -- 2.0.0 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Failed to load interface for GHC.Integer.Type
On Mon, 09 Jun 2014 21:45:27 +0200 Joachim Breitner wrote: > Hi, > > since > http://git.haskell.org/ghc.git/commitdiff/1946922c61df427e59f8a00572fd4dd6501abd98 > travis is complaining: > > > HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot > HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o > HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o > > Top level: > Failed to load interface for ‘GHC.Integer.Type’ > There are files missing in the ‘integer-gmp’ package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] Error 1 > make[1]: *** Waiting for unfinished jobs > make: *** [all] Error 2 > > Does anyone have an idea what may be causing this? A bit more context here is haddock started too early: Writing utils/haddock/doc/haddock/invoking.html for chapter(invoking) cp libffi/build/inst/lib/libffi.a rts/dist/build/libCffi.a HC [stage 1] libraries/base/dist-install/build/GHC/IO.o-boot HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Classes.o Writing utils/haddock/doc/haddock/ch03s02.html for section Writing utils/haddock/doc/haddock/ch03s03.html for section HC [stage 1] libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Prim.o Writing utils/haddock/doc/haddock/ch03s04.html for section Writing utils/haddock/doc/haddock/ch03s05.html for section Writing utils/haddock/doc/haddock/hyperlinking.html for section(hyperlinking) Writing utils/haddock/doc/haddock/module-attributes.html for section(module-attributes) HC [stage 1] libraries/base/dist-install/build/GHC/Exception.o-boot HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/CString.o Writing utils/haddock/doc/haddock/ch03s08.html for section Writing utils/haddock/doc/haddock/markup.html for chapter(markup) HC [stage 1] libraries/base/dist-install/build/GHC/Unicode.o-boot HC [stage 1] libraries/base/dist-install/build/Data/Coerce.o Top level: Failed to load interface for ‘GHC.Integer.Type’ There are files missing in the ‘integer-gmp’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/Data/Coerce.o] ... I guess real fault is: http://ghc.haskell.org/trac/ghc/changeset/f31b042c25b9c51efdbe84c1cb6f65f49534c14d/ghc -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.3 release - please speak up soon.
On Thu, 05 Jun 2014 16:37:36 +0200 Gergely Risko wrote: > Probably I'm very late, and the Nix guys can hopefully workaround this > on their own side, but can you take a quick look on: > https://ghc.haskell.org/trac/ghc/ticket/8919 Hia! Can you write what problems are to ship those libraries in it's current form? Do you have some linking problems or something? Ticket does not describe any actual problems. Thanks! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
On Sun, 4 May 2014 09:34:16 +0100 William Kenyon wrote: > I tested my patch on an old 32 bit laptop over night and it didn't work. > I think it's best to revert Simon's patch and let him fix it when he gets > chance. > > On 3 May 2014 12:59, William Kenyon wrote: > > > I think this should fix the problem. > > It certainly doesn't break anything on a 64 bit machine, > > and should fix the problem on a 32 bit machine (although I can't test that) To be more precise the patch hits codegen limitation: "inplace/bin/ghc-stage1" -static -H32m -O -optc-march=i686 -opta-march=i686 -optl-Wl,-O1 -optl-Wl,--as-needed -optl-Wl,--hash-style=gnu -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140504 for i386-unknown-linux): iselExpr64(i386) I64[_cfk::P32 + 60] - %MO_SS_Conv_W32_W64((Hp + 4) - I32[_cfl::I32]) Does it make sense to have 64-bit alloc_limit on 32-bit box? -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
[PATCH] fix rts exported symbols base_GHCziIOziException_allocationLimitExceeded_closure
From: Sergei Trofimovich Commit b0534f78a73f972e279eed4447a5687bd6a8308e added new exported rts symbols, but slightly misspelled them. Observer on first compiled program: > Linking dist/build/haskell-updater/haskell-updater ... > /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(Schedule.o): In function > `scheduleWaitThread': > (.text+0xc4c): undefined reference to > `base_GHCziIOziException_allocationLimitExceeded_closure' > /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(RtsStartup.o): In function > `hs_init_ghc': > (.text+0x2fa): undefined reference to > `base_GHCziIOziException_allocationLimitExceeded_closure' > collect2: error: ld returned 1 exit status CC: Simon Marlow Signed-off-by: Sergei Trofimovich --- rts/package.conf.in | 4 ++-- rts/win32/libHSbase.def | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/rts/package.conf.in b/rts/package.conf.in index 25fb5eb..914dd9c 100644 --- a/rts/package.conf.in +++ b/rts/package.conf.in @@ -98,7 +98,7 @@ ld-options: , "-Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure" , "-Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure" , "-Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure" - , "-Wl,-u,_base_GHCziIOziException_allocationQuotaExceeded_closure" + , "-Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure" , "-Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure" , "-Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure" , "-Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure" @@ -139,7 +139,7 @@ ld-options: , "-Wl,-u,base_ControlziExceptionziBase_nonTermination_closure" , "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure" , "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure" - , "-Wl,-u,base_GHCziIOziException_allocationQuotaExceeded_closure" + , "-Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure" , "-Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure" , "-Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure" , "-Wl,-u,base_GHCziTopHandler_flushStdHandles_closure" diff --git a/rts/win32/libHSbase.def b/rts/win32/libHSbase.def index 119237b..6bb19da 100644 --- a/rts/win32/libHSbase.def +++ b/rts/win32/libHSbase.def @@ -36,6 +36,7 @@ EXPORTS base_GHCziPack_unpackCString_closure base_GHCziIOziException_blockedIndefinitelyOnMVar_closure base_GHCziIOziException_blockedIndefinitelyOnSTM_closure + base_GHCziIOziException_allocationLimitExceeded_closure base_GHCziIOziException_stackOverflow_closure base_ControlziExceptionziBase_nonTermination_closure -- 1.9.2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate
On Fri, 4 Apr 2014 16:19:48 +
Simon Peyton Jones wrote:
Filed the reproducer as a new ticket:
https://ghc.haskell.org/trac/ghc/ticket/8980
[ Looks like highlighting-kate asks to be added to
compiler performance benchmarks (are there such ones?)
It tends to stress ghc all the time:
http://hackage.haskell.org/trac/ghc/ticket/3664
]
Thanks!
> Sergei
>
> SpecConstr is too aggressive: it sometimes blows up the program badly and we
> have no good solution. See Trac #7898, #7068, #7944, #5550, #8836.
>
> I notice that the latter three are actually fixed in 7.8, so worth trying
> that. If it still fails, do add instructions to reproduce to one of the
> above open tickets, or make a new one.
>
>
> Amos Robinson (cc'd) was working on this problem, but I have not heard
> anything recently.
>
> It surely ought to be possible to "throttle" it a bit so that it stops before
> generating too vast a program.
>
> Meanwhile you can use -fno-spec-constr to simply switch it off for offending
> modules. That should get you going.
> Simon
>
> | -Original Message-----
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> | Sergei Trofimovich
> | Sent: 03 April 2014 21:20
> | To: ghc-devs@haskell.org
> | Subject: Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-
> | citeproc / highlighting-kate
> |
> | On Sat, 22 Mar 2014 22:21:42 +0300
> | Sergei Trofimovich wrote:
> |
> | > Hello!
> | >
> | > I have noticed the problem in ghc-7.6.3 first when tried to build all
> | > haskell userland with -O2 opt level.
> | >
> | > It led to amazing bugs!
> | >
> | > Here is one of those (highlighting-kate hackage package):
> | > > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
> | > > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
> | > > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
> | > > stack overflow: use +RTS -K to increase it
> | >
> | > How to reproduce it:
> | > 1. Download a bundled file (6.6MB):
> | >
> | > http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-
> | rc2.tar.gz
> | > 2. Unpack and run there:
> | > ./mk.sh
> | >
> | > The script is designed to plug any built ghc version w/o external
> | depends.
> | >
> | > Command will fail as:
> | > $ ./mk.sh
> | > ...
> | > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
> | highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
> | highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
> | > stack overflow: use +RTS -K to increase it
> | >
> | > On ghc-7.6.3 it will progress a bit more: down to 452 file and will
> | > crash there similar way.
> | >
> | > I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them
> | > manually/added needed -DWhatever / added {-# LANGUAGE CPP #-} around.
> | > Nothing else.
> | >
> | > It's very hard to shrink such large thing manually down to 2-3 files.
> | > Would be cool if ghc (and cabal) would be able to spit something
> | > self-sufficient (like 'gcc -i' does) for devs to reproduce.
> | >
> | > Adding '-v' shows such log:
> | > ...
> | > *** Simplifier:
> | > Result size of Simplifier iteration=1
> | > = {terms: 21,973, types: 21,838, coercions: 1,842}
> | > Result size of Simplifier iteration=2
> | > = {terms: 21,952, types: 21,819, coercions: 1,842}
> | > Result size of Simplifier
> | > = {terms: 21,950, types: 21,817, coercions: 1,842}
> | > *** SpecConstr:
> | > Result size of SpecConstr***
> |
> | Nobody interested? Is it too scary?
> |
> | Such inliner blowups are hard to shrink down from real examples down to
> | toy ones. I could try to but I need a bit of guidance.
> |
> | Maybe you need only an intermediate core step right before an OOM,
> | whatever?
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate
On Sat, 22 Mar 2014 22:21:42 +0300
Sergei Trofimovich wrote:
> Hello!
>
> I have noticed the problem in ghc-7.6.3 first
> when tried to build all haskell userland with -O2 opt level.
>
> It led to amazing bugs!
>
> Here is one of those (highlighting-kate hackage package):
> > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
> > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
> > highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
> > stack overflow: use +RTS -K to increase it
>
> How to reproduce it:
> 1. Download a bundled file (6.6MB):
> http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-rc2.tar.gz
> 2. Unpack and run there:
> ./mk.sh
>
> The script is designed to plug any built ghc version w/o external depends.
>
> Command will fail as:
> $ ./mk.sh
> ...
> [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
> highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
> highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
> stack overflow: use +RTS -K to increase it
>
> On ghc-7.6.3 it will progress a bit more: down to 452 file and will crash
> there
> similar way.
>
> I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them
> manually/added needed -DWhatever / added {-# LANGUAGE CPP #-}
> around. Nothing else.
>
> It's very hard to shrink such large thing manually down to 2-3 files.
> Would be cool if ghc (and cabal) would be able to spit something
> self-sufficient (like 'gcc -i' does) for devs to reproduce.
>
> Adding '-v' shows such log:
> ...
> *** Simplifier:
> Result size of Simplifier iteration=1
> = {terms: 21,973, types: 21,838, coercions: 1,842}
> Result size of Simplifier iteration=2
> = {terms: 21,952, types: 21,819, coercions: 1,842}
> Result size of Simplifier
> = {terms: 21,950, types: 21,817, coercions: 1,842}
> *** SpecConstr:
> Result size of SpecConstr***
Nobody interested? Is it too scary?
Such inliner blowups are hard to shrink down from real
examples down to toy ones. I could try to but I need
a bit of guidance.
Maybe you need only an intermediate core step right
before an OOM, whatever?
Thanks!
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate
Hello!
I have noticed the problem in ghc-7.6.3 first
when tried to build all haskell userland with -O2 opt level.
It led to amazing bugs!
Here is one of those (highlighting-kate hackage package):
> [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
> highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
> highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
> stack overflow: use +RTS -K to increase it
How to reproduce it:
1. Download a bundled file (6.6MB):
http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-rc2.tar.gz
2. Unpack and run there:
./mk.sh
The script is designed to plug any built ghc version w/o external depends.
Command will fail as:
$ ./mk.sh
...
[281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp (
highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs,
highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o )
stack overflow: use +RTS -K to increase it
On ghc-7.6.3 it will progress a bit more: down to 452 file and will crash there
similar way.
I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them
manually/added needed -DWhatever / added {-# LANGUAGE CPP #-}
around. Nothing else.
It's very hard to shrink such large thing manually down to 2-3 files.
Would be cool if ghc (and cabal) would be able to spit something
self-sufficient (like 'gcc -i' does) for devs to reproduce.
Adding '-v' shows such log:
...
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 21,973, types: 21,838, coercions: 1,842}
Result size of Simplifier iteration=2
= {terms: 21,952, types: 21,819, coercions: 1,842}
Result size of Simplifier
= {terms: 21,950, types: 21,817, coercions: 1,842}
*** SpecConstr:
Result size of SpecConstr***
Thanks!
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: FFI: c/c++ struct on stack as an argument or return value
On Tue, 18 Mar 2014 20:31:19 +0300 Yuras Shumovich wrote: > Hi, > > I thought I have lost the battle :) > Thank you for the support, Simon! > > I'm interested in full featured solution: arguments, return value, > foreign import, foreign export, etc. But it is too much for me to do it > all at once. So I started with dynamic wrapper. > > The plan is to support structs as arguments and return value for dynamic > wrapper using libffi; > then implement native adjustors at least for x86_64 linux; On a positive side there is only 2 arches supporting native adjustors that actually work these days: ArchHasAdjustorSupport = $(if $(findstring $(TargetArch_CPP),i386 x86_64),YES,NO) > then make final design decision (tuple or data? language pragma? union > support? etc); > and only then start working on foreign import. > > But I'm open for suggestions. Just let me know if you think it is better > to start with return value support for foreign import. > > Thanks, > Yuras -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: "quick" vs "perf" builds
On Mon, 10 Mar 2014 18:59:38 +0100 Johan Tibell wrote: > Added: > https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c While at it: > SRC_HC_OPTS= ... -H64m Just wondering: that '-H64m' is from some old times (pre 2007?). GHC seems to eat way more RAM nowadays. Is this bit relevant at all? -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Standalone Deriving, GND and roles in 7.8.1-rc2
On Wed, 5 Mar 2014 15:40:27 -0500
Richard Eisenberg wrote:
> I think those should be the same and that you've discovered a bug. What's the
> definition of the Parsing class?
Here it goes [1]:
class Alternative m => Parsing m where
notFollowedBy :: (Monad m, Show a) => m a -> m ()
notFollowedBy p = try ((try p >>= unexpected . show) <|> pure ())
{-# INLINE notFollowedBy #-}
[1]:
https://github.com/ekmett/parsers/blob/master/src/Text/Parser/Combinators.hs#L230
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Standalone Deriving, GND and roles in 7.8.1-rc2
Hello!
Trying to build random packages with fresh ghc-7.8.1-rc2
I've come up with a strange bit:
https://github.com/trofi/Idris-dev/commit/9f93122ba1aa075c2fa1555fea68a6c403697e04
Is it an intended behaviour that
deriving instance Parsing IdrisInnerParser
capable of doing more, than
newtype IdrisInnerParser a = IdrisInnerParser { runInnerParser :: Parser a
} deriving (Parsing)
?
Thanks!
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] rts: unrust 'libbfd' debug symbols parser
On Sat, 15 Feb 2014 16:30:13 +0300 sly...@gmail.com wrote: > From: Sergei Trofimovich > > Signed-off-by: Sergei Trofimovich > --- > configure.ac | 3 ++- > rts/Printer.c| 10 -- > rts/RtsStartup.c | 6 ++ > 3 files changed, 16 insertions(+), 3 deletions(-) On trac as well: https://ghc.haskell.org/trac/ghc/ticket/8790 -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP'
On Sat, 15 Feb 2014 12:54:09 -0500 Carter Schonwald wrote: > Could you open a trac ticket for these patches and post em there? :-) > -Carter Sure! done as: https://ghc.haskell.org/trac/ghc/ticket/8789 > On Saturday, February 15, 2014, wrote: > > > From: Sergei Trofimovich > > > > > Signed-off-by: Sergei Trofimovich > What a funny semicolon quote -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] compiler/ghc.mk: restore GhcHcOpts variable handling
On Sat, 15 Feb 2014 16:26:07 +0300 sly...@gmail.com wrote: > From: Sergei Trofimovich > > Signed-off-by: Sergei Trofimovich > --- > compiler/ghc.mk | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) On trac as well: https://ghc.haskell.org/trac/ghc/ticket/8787 -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Use ffi_prep_closure_loc rather than ffi_prep_closure (310735e)
> commit 310735e7adce0145c653386c21686b4a1b96aea9
> Author: Ian Lynagh
> Date: Sun Apr 21 16:03:40 2013 +0100
>
> Use ffi_prep_closure_loc rather than ffi_prep_closure
>
> The latter is deprecated. Part of #7718.
>
> >---
>
> rts/Adjustor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rts/Adjustor.c b/rts/Adjustor.c
> index fbf95df..e4d6e8c 100644
> --- a/rts/Adjustor.c
> +++ b/rts/Adjustor.c
> @@ -131,7 +131,7 @@ createAdjustor (int cconv,
> barf("createAdjustor: failed to allocate memory");
> }
>
> -r = ffi_prep_closure(cl, cif, (void*)wptr, hptr/*userdata*/);
> +r = ffi_prep_closure_loc(cl, cif, (void*)wptr, hptr/*userdata*/, code);
> if (r != FFI_OK) barf("ffi_prep_closure failed: %d", r);
The barf() text (/ffi_prep_closure/ffi_prep_closure_loc/) might be adjusted as
well.
> return (void*)code;
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
[poll] ghc --make extension
Hi guys!
Today I've tried to write a minimal [1] test case for ghc on ia64
(it SIGSEGVs there).
The test case consists of a .cmm and some .hs modues.
I tried to build them in one run as:
$ ghc --make Test.hs TestPrim.hs test-prims.cmm -o t
ghc: cannot compile this file to desired target: test-prims.cmm
Usage: For basic information, try the `--help' option.
Thus had to use
${GHC} -c test-prims.cmm
${GHC} --make test-prims.o Test.hs TestPrim.hs
What do you think of allowing to use .c, .cmm and similar
files along with .hs files to make one-shot builds a bit easier?
If noone is opposed I'll fill a request on bugtracker.
Thanks!
[1]: https://github.com/trofi/cmm-example
--
Sergei
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
[PATCH] integer-gmp: mpn_gcd_1 allocate one Word on stack instead of 'sizeof (__mpz_struct)'
From: Sergei Trofimovich gmp.h defines 'mpn_gcd_1' as following: mp_limb_t mpn_gcd_1 (mp_srcptr /* aka 'mp_limb_t *' */, mp_size_t, mp_limb_t); Signed-off-by: Sergei Trofimovich --- cbits/gmp-wrappers.cmm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cbits/gmp-wrappers.cmm b/cbits/gmp-wrappers.cmm index 0390eb5..8a201f1 100644 --- a/cbits/gmp-wrappers.cmm +++ b/cbits/gmp-wrappers.cmm @@ -394,9 +394,9 @@ integer_cmm_gcdIntzh (W_ int1, W_ int2) W_ r; W_ mp_tmp_w; -STK_CHK_GEN_N (1 * SIZEOF_MP_INT); +STK_CHK_GEN_N (1 * SIZEOF_W); -mp_tmp_w = Sp - 1 * SIZEOF_MP_INT; +mp_tmp_w = Sp - 1 * SIZEOF_W; W_[mp_tmp_w] = int1; (r) = ccall __gmpn_gcd_1(mp_tmp_w "ptr", 1, int2); -- 1.8.1.2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libraries/unix: ghc-cabal: No buildable component found
On Mon, 18 Feb 2013 23:01:38 +0100 Karel Gardas wrote: > > Hello, > > I'm trying to build GHC cross-compiler to RTEMS OS, but I'm stuck on > getting this error message from ghc-cabal while configuring libraries/unix: > > ghc-cabal: No buildable component found > gmake[1]: *** [libraries/unix/dist-install/package-data.mk] Error 1 > > I'm not able to find out under which condition(s) cabal signals "no > buildable component found" on this particular library. Any idea? Could be a 'Buildable: False' everywhere: configure.ac:AC_CHECK_HEADER([dlfcn.h], [BUILD_PACKAGE_BOOL=True], [BUILD_PACKAGE_BOOL=False]) > Thanks a lot! > Karel -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] base: use --host as target, not uname
On Wed, 13 Feb 2013 22:47:40 +0100 Gabor Greif wrote: > On 2/13/13, Sergei Trofimovich wrote: > > From: Sergei Trofimovich > > > > Fixed bootstrap failure on linux for --target=mingw32 > > > > Signed-off-by: Sergei Trofimovich > > --- > > configure.ac | 10 -- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/configure.ac b/configure.ac > > index b679520..7553a7a 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -5,17 +5,23 @@ AC_CONFIG_SRCDIR([include/HsBase.h]) > > > > AC_CONFIG_HEADERS([include/HsBaseConfig.h include/EventConfig.h]) > > > > +AC_CANONICAL_BUILD > > +AC_CANONICAL_HOST > > +AC_CANONICAL_TARGET > > + > > AC_ARG_WITH([cc], > > [C compiler], > > [CC=$withval]) > > AC_PROG_CC() > > > > -case `uname -s` in > > -MINGW*|CYGWIN*) > > +AC_MSG_CHECKING(for WINDOWS platform) > > +case $host in > > Hi Sergei, > > I see some host <-> target confusion here. It is probably caused by > > https://github.com/ghc/ghc/blob/master/rules/build-package-data.mk#L74 > > I have always built my cross-ghc with this patch: > > ifeq "$$(CrossCompiling)" "YES" > $1_$2_CONFIGURE_OPTS += --configure-option=--host=$(HOSTPLATFORM) > $1_$2_CONFIGURE_OPTS += --configure-option=--target=$(TARGETPLATFORM) > endif > > instead, and have not seen problems so far. Maybe we should specify > how the packages should be configured for different stages of the > compiler once and for all, so we do not perpetuate the current > confusion. Well, yeah, your patch makes perfect sense for things like hsc2hs, where buld/host/target can be 3 different things. But for simple haskell libraries (like base) it's only a matter of not calling uname on linux. If you try to use --target=x86_64-w64-mingw32 (ghc's configure) on linux you will see the base breakage at once. It will pass correct --host flag to base but it will fail to configure (and this patch is expected to fix it). > Cheers, > > Gabor > > > +*mingw32*|*cygwin*) > > WINDOWS=YES;; > > *) > > WINDOWS=NO;; > > esac > > +AC_MSG_RESULT($WINDOWS) > > > > # do we have long longs? > > AC_CHECK_TYPES([long long]) > > -- > > 1.8.1.2 > > > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] hsc2hs: use configuration of current compiler, not built
On Wed, 13 Feb 2013 08:35:26 + Simon Marlow wrote: > On 13/02/13 07:33, Sergei Trofimovich wrote: > > From: Sergei Trofimovich > > > > Fixed bootstrap failure on linux for --target=mingw32 of such kind: > > > > "/usr/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -static -H32m -O -w > > -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 base-4.6.0.0 > > -package containers-0.5.0.0 -package directory-1.2.0.0 -package > > filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP > > -XForeignFunctionInterface -no-user-package-db -rtsopts -odir > > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir > > utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc > > utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/HSCParser.o > > utils/hsc2hs/dist/build/DirectCodegen.o > > utils/hsc2hs/dist/build/CrossCodegen.o > > utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Common.o > > utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Flags.o > > utils/hsc2hs/dist/build/Paths_hsc2hs.o > > > utils/hsc2hs/dist/build/Main.o: In function `s4cN_info': > > (.text+0x182): undefined reference to `GetModuleFileNameW' > > > > Signed-off-by: Sergei Trofimovich > > --- > > Main.hs | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Main.hs b/Main.hs > > index 30b3a2d..5309179 100644 > > --- a/Main.hs > > +++ b/Main.hs > > @@ -11,7 +11,7 @@ > > -- See the documentation in the Users' Guide for more details. > > > > #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) > > -#include "../../includes/ghcconfig.h" > > +#include "ghcconfig.h" > > #endif > > > > import Control.Monad( liftM, forM_ ) > > Looks like this needs to be conditional on whether we're building hsc2hs > with stage0 or stage1-2. Can we restructure build system a bit to generate separate "ghcconfig.h" for all the stages we are trying to build? It would mean generating two local "ghcconfig.h" files and make them available at once: - which are equal to booter compiler in native case - differ from host compiler where in case --target=T (--host=--build=H) stage1's: #define BuildPlatform_TYPE H #define HostPlatform_TYPE H #define TargetPlatform_TYPE T stage2's: #define BuildPlatform_TYPE H #define HostPlatform_TYPE T #define TargetPlatform_TYPE T Thanks! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
[PATCH] base: use --host as target, not uname
From: Sergei Trofimovich Fixed bootstrap failure on linux for --target=mingw32 Signed-off-by: Sergei Trofimovich --- configure.ac | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b679520..7553a7a 100644 --- a/configure.ac +++ b/configure.ac @@ -5,17 +5,23 @@ AC_CONFIG_SRCDIR([include/HsBase.h]) AC_CONFIG_HEADERS([include/HsBaseConfig.h include/EventConfig.h]) +AC_CANONICAL_BUILD +AC_CANONICAL_HOST +AC_CANONICAL_TARGET + AC_ARG_WITH([cc], [C compiler], [CC=$withval]) AC_PROG_CC() -case `uname -s` in -MINGW*|CYGWIN*) +AC_MSG_CHECKING(for WINDOWS platform) +case $host in +*mingw32*|*cygwin*) WINDOWS=YES;; *) WINDOWS=NO;; esac +AC_MSG_RESULT($WINDOWS) # do we have long longs? AC_CHECK_TYPES([long long]) -- 1.8.1.2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
[PATCH] base: use --target as target, not uname
From: Sergei Trofimovich Fixed bootstrap failure on linux for --target=mingw32 Signed-off-by: Sergei Trofimovich --- configure.ac | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b679520..7553a7a 100644 --- a/configure.ac +++ b/configure.ac @@ -5,17 +5,23 @@ AC_CONFIG_SRCDIR([include/HsBase.h]) AC_CONFIG_HEADERS([include/HsBaseConfig.h include/EventConfig.h]) +AC_CANONICAL_BUILD +AC_CANONICAL_HOST +AC_CANONICAL_TARGET + AC_ARG_WITH([cc], [C compiler], [CC=$withval]) AC_PROG_CC() -case `uname -s` in -MINGW*|CYGWIN*) +AC_MSG_CHECKING(for WINDOWS platform) +case $host in +*mingw32*|*cygwin*) WINDOWS=YES;; *) WINDOWS=NO;; esac +AC_MSG_RESULT($WINDOWS) # do we have long longs? AC_CHECK_TYPES([long long]) -- 1.8.1.2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
[PATCH] hsc2hs: use configuration of current compiler, not built
From: Sergei Trofimovich Fixed bootstrap failure on linux for --target=mingw32 of such kind: "/usr/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -static -H32m -O -w -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 base-4.6.0.0 -package containers-0.5.0.0 -package directory-1.2.0.0 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/Paths_hsc2hs.o utils/hsc2hs/dist/build/Main.o: In function `s4cN_info': (.text+0x182): undefined reference to `GetModuleFileNameW' Signed-off-by: Sergei Trofimovich --- Main.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Main.hs b/Main.hs index 30b3a2d..5309179 100644 --- a/Main.hs +++ b/Main.hs @@ -11,7 +11,7 @@ -- See the documentation in the Users' Guide for more details. #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) -#include "../../includes/ghcconfig.h" +#include "ghcconfig.h" #endif import Control.Monad( liftM, forM_ ) -- 1.8.1.1 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release?
> Thanks for sharing! My perspective is of course as a user. I don't think > I've ever run into a case where the compiler broken a previous work e.g. > C++ program. On the other hand I have to make a release of most of the > libraries I maintain with every GHC release (to bump cabal version > constraints to accept the new base version, if nothing else). Just don't set upper version of base on the packages when you are not sure they will break. Write tested ghc versions in comments instead. You can't install separate base for a given ghc, so why bother? According to PVP you need to use 'base < 4.7' in version, BUT IT IS INSANE How do you expect users to test new ghc release (preview, name it any way), if you require them to unpack every nonresolvable package and update depends by hands? It's very fun to check -HEAD version for fixed bugs in that respect. Luckily many devs are not that insane and use arbitrary 'base < 5' or 'base < 10', which will break randomly at an arbitrary base-5 release. -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
[a pile of random patches] Re: Stage1Only=YES does not seem to work on current master
On Tue, 29 Jan 2013 10:20:19 + Simon Marlow wrote: > On 27/01/13 21:21, Sergei Trofimovich wrote: > > simple build.mk: > > > > SRC_CC_OPTS+=-O2 -pipe > > > > BUILD_DOCBOOK_PDF = NO > > BUILD_DOCBOOK_PS = NO > > BUILD_DOCBOOK_HTML = NO > > HADDOCK_DOCS = NO > > SRC_HC_OPTS+=-w > > > > Stage1Only=YES > > GhcUnregisterised=YES > > SplitObjs=NO > > > > Leads to failures of missing stage2: > > > > "inplace/lib/unlit" utils/count_lines/count_lines.lprl > > utils/count_lines/dist/count_lines.prl > > "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe > > -optc-Ilibraries/primitive/cbits > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' > > -static -H32m -O -w-package-name primitive-0.4.0.1 > > -hide-all-packages -i -ilibraries/primitive/. > > -ilibraries/primitive/dist-install/build > > -ilibraries/primitive/dist-install/build/autogen > > -Ilibraries/primitive/dist-install/build > > -Ilibraries/primitive/dist-install/build/autogen > > -Ilibraries/primitive/cbits-optP-include > > -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package > > base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 > > -no-user-package-db -rtsopts -c libraries/prim > itive/cbits/primitive-memops.c -o > libraries/primitive/dist-install/build/cbits/primitive-memops.o > > "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe > > -optc-Ilibraries/primitive/cbits > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' > > > > -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' > > -static -prof -H32m -O -w-package-name primitive-0.4.0.1 > > -hide-all-packages -i -ilibraries/primitive/. > > -ilibraries/primitive/dist-install/build > > -ilibraries/primitive/dist-install/build/autogen > > -Ilibraries/primitive/dist-install/build > > -Ilibraries/primitive/dist-install/build/autogen > > -Ilibraries/primitive/cbits-optP-include > > -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package > > base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 > > -no-user-package-db -rtsopts -c librarie > s/primitive/cbits/primitive-memops.c -o > libraries/primitive/dist-install/build/cbits/primitive-memops.p_o > > /bin/sh: inplace/bin/ghc-stage2: No such file or directory > > make[1]: *** > > [libraries/primitive/dist-install/build/cbits/primitive-memops.o] Error 127 > > make[1]: *** Waiting for unfinished jobs > > /bin/sh: inplace/bin/ghc-stage2: No such file or directory > > I just pushed a patch that should fix this. Part of the problem is that > the --no-dph flag to sync-all doesn't disable the primitive & vector > repos like it used to, because they are now submodules. I've fixed it > in the build system instead. Yeah, your change fixed 'make' for stage1only. make install does not work though (and didn't before): $ make install DESTDIR=/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image/ ... Installing library in /var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image/usr/lib64/ghc-7.7.20130129/bin-package-db-0.0.0.0 CROSS_COMPILE="ia64-unknown-linux-gnu-" "inplace/bin/ghc-cabal" copy "strip" libraries/hoopl dist-install '/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image' '/usr' '/usr/lib64/ghc-7.7.20130129' '/usr/share/doc/ghc-/html/libraries' Installing library in /var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image/usr/lib64/ghc-7.7.20130129/hoopl-3.10.0.0 CROSS_COMPILE="ia64-unknown-linux-gnu-" "inplace/bin/ghc-cabal" copy "strip" libraries/transformers dist-install '/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/image' '/usr' '/usr/l
[PATCH] GHC_CONVERT_VENDOR: allow 'w64' vendor, like x86_64-w64-mingw32
From: Sergei Trofimovich Gentoo calls 'w64' a mingw flavour with mingw-w64 runtime. Signed-off-by: Sergei Trofimovich --- aclocal.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aclocal.m4 b/aclocal.m4 index 9f9593a..30d492c 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -1812,7 +1812,7 @@ case "$1" in # converts vendor from gnu to ghc naming, and assigns the result to $target_var AC_DEFUN([GHC_CONVERT_VENDOR],[ case "$1" in - pc|gentoo) # like i686-pc-linux-gnu and i686-gentoo-freebsd8 + pc|gentoo|w64) # like i686-pc-linux-gnu, i686-gentoo-freebsd8, x86_64-w64-mingw32 $2="unknown" ;; softfloat) # like armv5tel-softfloat-linux-gnueabi -- 1.8.1.1 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Stage1Only=YES does not seem to work on current master
simple build.mk: SRC_CC_OPTS+=-O2 -pipe BUILD_DOCBOOK_PDF = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_HTML = NO HADDOCK_DOCS = NO SRC_HC_OPTS+=-w Stage1Only=YES GhcUnregisterised=YES SplitObjs=NO Leads to failures of missing stage2: "inplace/lib/unlit" utils/count_lines/count_lines.lprl utils/count_lines/dist/count_lines.prl "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe -optc-Ilibraries/primitive/cbits -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' -static -H32m -O -w-package-name primitive-0.4.0.1 -hide-all-packages -i -ilibraries/primitive/. -ilibraries/primitive/dist-install/build -ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/dist-install/build -Ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/cbits -optP-include -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 -no-user-package-db -rtsopts -c libraries/primitive/cbits/primitive-memops.c -o libraries/primitive/dist-install/build/cbits/primitive-memops.o "inplace/bin/ghc-stage2" -optc-O2 -optc-pipe -optc-Ilibraries/primitive/cbits -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/libraries/base/include' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/rts/dist/build' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes' -optc-I'/var/tmp/portage/cross-ia64-unknown-linux-gnu/ghc-/work/ghc-/includes/dist-derivedconstants/header' -static -prof -H32m -O -w-package-name primitive-0.4.0.1 -hide-all-packages -i -ilibraries/primitive/. -ilibraries/primitive/dist-install/build -ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/dist-install/build -Ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/cbits -optP-include -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -XHaskell98 -XCPP -O2 -no-user-package-db -rtsopts -c libraries/primitive/cbits/primitive-memops.c -o libraries/primitive/dist-install/build/cbits/primitive-memops.p_o /bin/sh: inplace/bin/ghc-stage2: No such file or directory make[1]: *** [libraries/primitive/dist-install/build/cbits/primitive-memops.o] Error 127 make[1]: *** Waiting for unfinished jobs /bin/sh: inplace/bin/ghc-stage2: No such file or directory -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: pgj (x86 FreeBSD HEAD), build 925, Failure
On Sat, 26 Jan 2013 01:56:36 + Ian Lynagh wrote: > On Fri, Jan 25, 2013 at 05:47:03PM -0800, Builder wrote: > > pgj (x86 FreeBSD HEAD), build 925 > > > > Build failed > > Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/925.html > > > > checking for __gmpz_fdiv_qr in -lgmp... no > > checking for __gmpz_fdiv_qr in -lgmp3... no > > configure: error: Failed to compute size of sizeof (MP_INT) > > gmake[1]: *** [libraries/integer-gmp/dist-install/package-data.mk] Error 1 > > gmake: *** [all] Error 2 > > checking for sizeof (MP_INT) size... > > My Win32 HEAD build failed the same way: > > checking for __gmpz_fdiv_qr in -lgmp3... no > checking for sizeof (MP_INT) size... configure: error: Failed to compute size > of sizeof (MP_INT) > libraries/integer-gmp/ghc.mk:4: recipe for target > `libraries/integer-gmp/dist-install/package-data.mk' failed > make[1]: *** [libraries/integer-gmp/dist-install/package-data.mk] Error 1 > > Does anyone know what's up? I've broke it. Is there a config.log from that system? Looks like local include paths were not prepended correctly in missing libgmp case. -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] Re: HEADS UP (was Re: [commit: ghc] master: Tidy up cross-compiling (109a1e5))
On Fri, 25 Jan 2013 11:00:23 +0100 Gabor Greif wrote: > Hio all! > > Just a piece of feedback, > > this patch is giving me (when 'perl boot') an error: > > Booting libraries/integer-gmp/ > configure.ac:70: error: possibly undefined macro: AC_COMPUTE_INT > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > autoreconf: /usr/bin/autoconf failed with exit status: 1 > > I have > > $ autoconf --version > autoconf (GNU Autoconf) 2.59 > Written by David J. MacKenzie and Akim Demaille. > > Copyright (C) 2003 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. How easy for you would be to update autoconf-2.61? It's rather old (from Nov 2006). I guess it should be present in repositories. Would AC_PREREQ be enough to report minimal requirement to a ghc's dev tree? Patch attached. -- Sergei From 564475948e1e77cb197b36e95725006ee871f481 Mon Sep 17 00:00:00 2001 From: Sergei Trofimovich Date: Fri, 25 Jan 2013 22:15:52 +0300 Subject: [PATCH] integer-gmp: configure.ac document requirement for autoconf-2.62 Reported-by: Gabor Greif Signed-off-by: Sergei Trofimovich --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index c99f988..af6797e 100644 --- a/configure.ac +++ b/configure.ac @@ -1,3 +1,6 @@ +dnl for AC_COMPUTE_INT +AC_PREREQ([2.62]) + AC_INIT([Haskell integer (GMP)], [0.1], [librar...@haskell.org], [integer]) AC_CANONICAL_TARGET -- 1.8.1.1 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] Re: HEADS UP (was Re: [commit: ghc] master: Tidy up cross-compiling (109a1e5))
On Thu, 24 Jan 2013 15:06:58 + Simon Marlow wrote: > On 23/01/13 23:44, Sergei Trofimovich wrote: > > > mkGmpDerivedConstants is built for target and ran on host > > [attached patches for it] > > Thanks, I pushed your patches today. > > Cheers, > Simon > > I see a ghc patch in tree, but not integer-gmp one: https://github.com/ghc/packages-integer-gmp/commits/master Thanks! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
[PATCH] Re: HEADS UP (was Re: [commit: ghc] master: Tidy up cross-compiling (109a1e5))
On Thu, 17 Jan 2013 13:00:44 +
Simon Marlow wrote:
> Cross-compilers please take note:
>
> On 17/01/13 12:57, Simon Marlow wrote:
>
> > Before
> > --
> >
> > To build a cross-compiler:
> >./configure --target=<..>
> >
> > To compile a foreign GHC:
> >./configure --host=<..> --target=<..>
> >
> > Now
> > ---
> >
> > To build a cross-compiler:
> >./configure --target=<..>
> >And set "Stage1Only=YES" in mk/build.mk
> >
> > To compile a foreign GHC:
> >./configure --target=<..>
>
> Cheers,
> Simon
Looks great!
Tried a while ago with the following setup:
* --tagret=ia64-unknown-linux-gnu
* "Stage1Only=YES"
* host compiler is ghc-7.6.1 (unregisterised build)
to get real cross-compiler and found out the following issues:
mkGmpDerivedConstants is built for target and ran on host
[attached patches for it]
make install fails as it 'forgets' to install proper ghc-pkg in
$(${cross}-ghc --print-libdir)/bin/
But the resulting cross-compiler was able to build working hello world!
--
Sergei
From 64c14611b0907a672d97cb390c527e7ab9acb16f Mon Sep 17 00:00:00 2001
From: Sergei Trofimovich
Date: Thu, 24 Jan 2013 01:36:21 +0300
Subject: [PATCH] integer-gmp: improve cross-compiling support
GmpDerivedConstants.h
Before the patch GmpDerivedConstants.h was generated
by running mkGmpDerivedConstants on target.
Now it's generated only with help of autoconf macros.
Tested on --target=ia64-unknown-linux-gnu.
Signed-off-by: Sergei Trofimovich
---
.gitignore | 1 -
cbits/mkGmpDerivedConstants.c| 74
cbits/GmpDerivedConstants.h.in | 10 ++
configure.ac | 28 ---
gmp/ghc.mk | 8 -
5 files changed, 34 insertions(+), 87 deletions(-)
delete mode 100644 cbits/mkGmpDerivedConstants.c
create mode 100644 cbits/GmpDerivedConstants.h.in
diff --git a/.gitignore b/.gitignore
index 012224d..56857e9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,4 +8,3 @@ ghc.mk
gmp/config.mk
integer-gmp.buildinfo
cbits/GmpDerivedConstants.h
-cbits/mkGmpDerivedConstants
diff --git a/cbits/mkGmpDerivedConstants.c b/cbits/mkGmpDerivedConstants.c
deleted file mode 100644
index ed07111..000
--- a/cbits/mkGmpDerivedConstants.c
+++ /dev/null
@@ -1,74 +0,0 @@
-/* --
- *
- * (c) The GHC Team, 1992-2004
- *
- * mkDerivedConstants.c
- *
- * Basically this is a C program that extracts information from the C
- * declarations in the header files (primarily struct field offsets)
- * and generates a header file that can be #included into non-C source
- * containing this information.
- *
- * */
-
-#include
-#include "gmp.h"
-
-
-#define str(a,b) #a "_" #b
-
-#define OFFSET(s_type, field) ((size_t)&(((s_type*)0)->field))
-
-/* struct_size(TYPE)
- *
- */
-#define def_size(str, size) \
-printf("#define SIZEOF_" str " %lu\n", (unsigned long)size);
-
-#define struct_size(s_type) \
-def_size(#s_type, sizeof(s_type));
-
-
-
-/* struct_field(TYPE, FIELD)
- *
- */
-#define def_offset(str, offset) \
-printf("#define OFFSET_" str " %d\n", (int)(offset));
-
-#define field_offset_(str, s_type, field) \
-def_offset(str, OFFSET(s_type,field));
-
-#define field_offset(s_type, field) \
-field_offset_(str(s_type,field),s_type,field);
-
-#define field_type_(str, s_type, field) \
-printf("#define REP_" str " b"); \
-printf("%lu\n", (unsigned long)sizeof (__typeof__(s_type*)0)->field * 8);
-
-#define field_type(s_type, field) \
-field_type_(str(s_type,field),s_type,field);
-
-/* An access macro for use in C-- sources. */
-#define struct_field_macro(str) \
-printf("#define " str "(__ptr__) REP_" str "[__ptr__+OFFSET_" str "]\n");
-
-/* Outputs the byte offset and MachRep for a field */
-#define struct_field(s_type, field) \
-field_offset(s_type, field); \
-field_type(s_type, field); \
-struct_field_macro(str(s_type,field))
-
-
-int
-main(int argc, char *argv[])
-{
-printf("/* This file is created automatically. Do not edit by hand.*/\n\n");
-
-struct_size(MP_INT);
-struct_field(MP_INT,_mp_alloc);
-struct_field(MP_INT,_mp_size);
-struct_field(MP_INT,_mp_d);
-
-return 0;
-}
diff --git a/cbits/GmpDerivedConstants.h.in b/cbits/GmpDerivedConstants.h.in
new file mode 100644
index 000..241372f
--- /dev/null
+++ b/cbits/GmpDerivedConstants.h.in
@@ -0,0 +1,10 @@
+#define SIZEOF
