Re: HEAD doesn't build. Totally stalled.

[Sergei Trofimovich]

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 

Re: bug in aclocal.m4

[Sergei Trofimovich]

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

[Sergei Trofimovich]

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

[Sergei Trofimovich]

On Sun, 26 Mar 2017 15:08:50 +0200
Karel Gardas <karel.gar...@centrum.cz> 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

[Sergei Trofimovich]

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

[Sergei Trofimovich]

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?

[Sergei Trofimovich]

On Fri, 26 Jun 2015 23:05:55 -0400
Dominick Samperi djsamp...@gmail.com 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: Different behavior in ghci 7.8.3 vs 7.10.1?

[Sergei Trofimovich]

On Sat, 27 Jun 2015 07:59:33 -0400
Dominick Samperi djsamp...@gmail.com 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: Playing with the profiler

[Sergei Trofimovich]

On Sat, 17 Jan 2015 23:20:30 +
Luís Gabriel lam...@gmail.com 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

[Sergei Trofimovich]

On Tue, 16 Sep 2014 20:23:10 +
Simon Peyton Jones simo...@microsoft.com 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 simo...@microsoft.com 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 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

Re: Bash completion in GHC 7.10

[Sergei Trofimovich]

On Wed, 10 Dec 2014 16:43:57 +0400
Lennart Kolmodin kolmo...@gmail.com 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-liTABENTER
  /usr/lib64/ghc-7.10.0.20141222

  sf / # ghci --print-liTABENTER
  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

[Sergei Trofimovich]

On Wed, 24 Dec 2014 20:27:27 +0100
Tuncer Ayaz tuncer.a...@gmail.com wrote:

 Building ghc-7.10.1-rc1, I see the following new messages:
 
 HC [stage 1] compiler/stage2/build/Dwarf.p_o
 ghc: 607994600 bytes, 145 GCs, 14478288/51516200 avg/max bytes
 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?

[Sergei Trofimovich]

On Sat, 13 Dec 2014 15:19:34 +
Sergei Trofimovich sly...@gmail.com wrote:

 On Wed, 03 Dec 2014 11:59:42 +
 Simon Marlow marlo...@gmail.com 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?

[Sergei Trofimovich]

On Wed, 03 Dec 2014 11:59:42 +
Simon Marlow marlo...@gmail.com 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

[Sergei Trofimovich]

On Fri, 24 Oct 2014 18:52:53 -0500
Austin Seipp aus...@well-typed.com 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

[Sergei Trofimovich]

On Mon, 15 Sep 2014 12:05:27 +
Simon Peyton Jones simo...@microsoft.com 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

[Sergei Trofimovich]

On Tue, 9 Sep 2014 08:34:03 -0500
Austin Seipp aus...@well-typed.com 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)

[Sergei Trofimovich]

On Wed, 3 Sep 2014 15:31:03 -0500
Austin Seipp aus...@well-typed.com 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 21
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 T8628/dev/null 
T8628.run.stdout 2T8628.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 21
Compile failed (status 256) errors were:
*** Core Lint errors : in result of Simplifier ***
no location info: 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=vanilla, 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  

Re: Building HEAD (e83e873d) on mips64el: unknown package: old-locale-1.0.0.6

[Sergei Trofimovich]

On Tue, 02 Sep 2014 08:48:22 +0400
Nikita Karetnikov nik...@karetnikov.org 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

[Sergei Trofimovich]

On Thu, 14 Aug 2014 01:30:00 +0400
Nikita Karetnikov nik...@karetnikov.org 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

[Sergei Trofimovich]

On Thu, 28 Aug 2014 11:16:03 +
Simon Peyton Jones simo...@microsoft.com 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 21
Compile failed (status 256) errors were:
*** Core Lint errors : in result of Simplifier ***
no location info: 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
 Scanning 

Re: clang warnings with unregisterised

[Sergei Trofimovich]

On Fri, 29 Aug 2014 02:56:01 +0200
Gabor Greif ggr...@gmail.com 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

[Sergei Trofimovich]

On Wed, 13 Aug 2014 11:39:56 +0200
Tuncer Ayaz tuncer.a...@gmail.com 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

[Sergei Trofimovich]

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)

[Sergei Trofimovich]

On Wed, 6 Aug 2014 22:15:34 +0300
Sergei Trofimovich sly...@gentoo.org wrote:

 On Wed, 06 Aug 2014 09:30:45 +0200
 Joachim Breitner m...@joachim-breitner.de wrote:
 
  Hi,
  
  the attached commit seems to have regressed the scs nofib benchmark by
  ~3%:
  http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scsenv=1#/?exe=2base=2+68ben=nofib/time/scsenv=1revs=50equid=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

[Sergei Trofimovich]

On Wed, 2 Jul 2014 14:59:13 -0500
Austin Seipp aus...@well-typed.com 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

[Sergei Trofimovich]

On Sat, 28 Jun 2014 08:31:41 -0700
Mark Lentczner mark.lentcz...@gmail.com 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)

[Sergei Trofimovich]

On Wed, 11 Jun 2014 21:35:57 +0300
Sergei Trofimovich sly...@gentoo.org wrote:

 On Wed, 11 Jun 2014 08:18:30 +
 Simon Peyton Jones simo...@microsoft.com wrote:
 
  Stefan, Guys
  This commit breaks the Windows build (ie my laptop)
  
  commit 9fd507e5758f4141ac2619f0db57136bcab035c6
  
  Author: Sergei Trofimovich sly...@gentoo.org
  
  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 sly...@gentoo.org
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 simo...@microsoft.com
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
 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/libraries/base/base.cabal
index e56724c..8537843 100644
--- a/libraries/base/base.cabal
+++ b/libraries/base/base.cabal
@@ -276,6 +276,7 @@ Library
 Control.Monad.ST.Imp
 Control.Monad.ST.Lazy.Imp
 Foreign.ForeignPtr.Imp

Re: Failed to load interface for GHC.Integer.Type

[Sergei Trofimovich]

On Mon, 09 Jun 2014 21:45:27 +0200
Joachim Breitner m...@joachim-breitner.de 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: Failed to load interface for GHC.Integer.Type

[Sergei Trofimovich]

On Mon, 9 Jun 2014 23:56:37 +0300
Sergei Trofimovich sly...@gmail.com wrote:

 On Mon, 09 Jun 2014 21:45:27 +0200
 Joachim Breitner m...@joachim-breitner.de 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 i...@well-typed.com
 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 sly...@gentoo.org
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 sly...@gentoo.org
---
 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: 7.8.3 release - please speak up soon.

[Sergei Trofimovich]

On Thu, 05 Jun 2014 16:37:36 +0200
Gergely Risko gerg...@risko.hu 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)

[Sergei Trofimovich]

On Sun, 4 May 2014 09:34:16 +0100
William Kenyon g...@abacathoo.org 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 g...@abacathoo.org 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

[Sergei Trofimovich]

From: Sergei Trofimovich sly...@gentoo.org

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 marlo...@gmail.com
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
 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

[Sergei Trofimovich]

On Fri, 4 Apr 2014 16:19:48 +
Simon Peyton Jones simo...@microsoft.com 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 sly...@gmail.com 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 -Ksize 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 -Ksize 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***CRASH
 | 
 | 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

[Sergei Trofimovich]

On Sat, 22 Mar 2014 22:21:42 +0300
Sergei Trofimovich sly...@gmail.com 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 -Ksize 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 -Ksize 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***CRASH

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

Re: FFI: c/c++ struct on stack as an argument or return value

[Sergei Trofimovich]

On Tue, 18 Mar 2014 20:31:19 +0300
Yuras Shumovich shumovi...@gmail.com 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

[Sergei Trofimovich]

On Mon, 10 Mar 2014 18:59:38 +0100
Johan Tibell johan.tib...@gmail.com 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

Standalone Deriving, GND and roles in 7.8.1-rc2

[Sergei Trofimovich]

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: Standalone Deriving, GND and roles in 7.8.1-rc2

[Sergei Trofimovich]

On Wed, 5 Mar 2014 15:40:27 -0500
Richard Eisenberg e...@cis.upenn.edu 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

Re: [PATCH] compiler/ghc.mk: restore GhcHcOpts variable handling

[Sergei Trofimovich]

On Sat, 15 Feb 2014 16:26:07 +0300
sly...@gmail.com wrote:

 From: Sergei Trofimovich sly...@gentoo.org
 
 Signed-off-by: Sergei Trofimovich sly...@gentoo.org
 ---
  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: [PATCH] includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP'

[Sergei Trofimovich]

On Sat, 15 Feb 2014 12:54:09 -0500
Carter Schonwald carter.schonw...@gmail.com 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, sly...@gmail.com wrote:
 
  From: Sergei Trofimovich sly...@gentoo.org javascript:;
 
  Signed-off-by: Sergei Trofimovich sly...@gentoo.org javascript:;

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] rts: unrust 'libbfd' debug symbols parser

[Sergei Trofimovich]

On Sat, 15 Feb 2014 16:30:13 +0300
sly...@gmail.com wrote:

 From: Sergei Trofimovich sly...@gentoo.org
 
 Signed-off-by: Sergei Trofimovich sly...@gentoo.org
 ---
  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: [commit: ghc] master: Use ffi_prep_closure_loc rather than ffi_prep_closure (310735e)

[Sergei Trofimovich]

 commit 310735e7adce0145c653386c21686b4a1b96aea9
 Author: Ian Lynagh i...@well-typed.com
 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

Re: libraries/unix: ghc-cabal: No buildable component found

[Sergei Trofimovich]

On Mon, 18 Feb 2013 23:01:38 +0100
Karel Gardas karel.gar...@centrum.cz 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

[Sergei Trofimovich]

On Wed, 13 Feb 2013 22:47:40 +0100
Gabor Greif ggr...@gmail.com wrote:

 On 2/13/13, Sergei Trofimovich sly...@gmail.com wrote:
  From: Sergei Trofimovich sly...@gentoo.org
 
  Fixed bootstrap failure on linux for --target=mingw32
 
  Signed-off-by: Sergei Trofimovich sly...@gentoo.org
  ---
   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: GHC 7.8 release?

[Sergei Trofimovich]

 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

Re: [PATCH] Re: HEADS UP (was Re: [commit: ghc] master: Tidy up cross-compiling (109a1e5))

[Sergei Trofimovich]

On Thu, 24 Jan 2013 15:06:58 +
Simon Marlow marlo...@gmail.com 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