git issues or repository issues?

[Karel Gardas]

Hello,

for around a year or two I do have issues which updating ghc git
repository. There are actually two issues.

The clone is created as recommended by ghc.dev:

$ git clone --recurse-submodules https://gitlab.haskell.org/ghc/ghc.git

Update is performed as recommended too:

$ git pull --recurse-submodules.

After some time (accumulated patches) since I update monthly or
bi-monthly to test I see those two issues:

1. this is what fails first and is able to be "fixed" by running another
pull:

Fetching submodule utils/hsc2hs
fatal: remote error: upload-pack: not our ref
0584d4fd443ac7a8e397895a79d162a55e36ef00
fatal: the remote end hung up unexpectedly
fatal: remote error: upload-pack: not our ref
57d23853806add183308178663c7e22fbef2417f
fatal: the remote end hung up unexpectedly
fatal: remote error: upload-pack: not our ref
5361c3d9503d017d5f42daff793837a017e4f7a7
fatal: the remote end hung up unexpectedly
fatal: remote error: upload-pack: not our ref
e5a6da21382ae76098a4f02148504b9f79e5e2ff
fatal: the remote end hung up unexpectedly
fatal: remote error: upload-pack: not our ref
3373ca908ad059cbadb526e6ed1dcba5679b0d72
fatal: the remote end hung up unexpectedly
fatal: remote error: upload-pack: not our ref
659eb37eb84e9cbdef226726f46a0fa5608eab5c
fatal: the remote end hung up unexpectedly
fatal: remote error: upload-pack: not our ref
40e1c4eb53c1e65be23e91f63139aa16111bbdf3
fatal: the remote end hung up unexpectedly
fatal: remote error: upload-pack: not our ref
b8ae1bf26ee0e74c3e2e7fc2c7dd0dd2b0a2
fatal: the remote end hung up unexpectedly


2. this one is not-fixable, but hard to judge if this is issue at all or
what. Certainly "error" is making me nervous about it.

Fetching submodule utils/haddock
error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags':
'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot
create 'refs/remotes/origin/wip/hsyl20/dynflags'
From https://gitlab.haskell.org/ghc/haddock
 ! [new branch]wip/hsyl20/dynflags -> origin/wip/hsyl20/dynflags
 (unable to update local ref)
Fetching submodule utils/hsc2hs


This all is run on Ubuntu 20.04.x LTS pretty uptodate. The provided git
is 2.25.1 there.

Does anybody here have any idea why this happens?

Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghcup failed

[Karel Gardas]

On 6/2/21 10:16 PM, Viktor Dukhovni wrote:
> On Wed, Jun 02, 2021 at 07:06:59PM +, Simon Peyton Jones via ghc-devs 
> wrote:
> 
>> "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/bin/ghc-pkg" --force 
>> --global-package-db 
>> "/home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d" update 
>> rts/dist/package.conf.install
>>
>> ghc-pkg: Couldn't open database 
>> /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d for 
>> modification: {handle: 
>> /home/simonpj/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/package.conf.d/package.cache.lock}:
>>  hLock: invalid argument (Invalid argument)
> 
> With WSL2, what sort of filesystem is /home/?  Is a native
> Linux filesystem (ext4, btrfs, ...) over a block device, or is it NTFS
> (either shared with Windows or dedicated for WSL2)?

IIRC

WSL1 is using windows kernel and Linux support is cooked on top of that
somehow -- like linuxator in freebsd or so. Linux syscalls emulated.

WSL2 is using hyper-v and linux kernel, hence is more or less like
normal linux.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Ampere A1 instances for builder/marge?

[Karel Gardas]

Hi,

just to pass
https://www.servethehome.com/oracle-cloud-giving-away-ampere-arm-a1-instances-always-free/
-- oracle seems to be giving some "always free" Ampere/ARM based
instances. Looks like they even have some RAM and cores so perhaps they
may be usable for marge/builder for arm/linux platform?

BTW: Not tested myself, not trust Oracle, but sometimes man can get some
good even from ... well... Oracle...

Thanks,
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: On CI

[Karel Gardas]

On 3/17/21 4:16 PM, Andreas Klebinger wrote:
> Now that isn't really an issue anyway I think. The question is rather is
> 2% a large enough regression to worry about? 5%? 10%?

5-10% is still around system noise even on lightly loaded workstation.
Not sure if CI is not run on some shared cloud resources where it may be
even higher.

I've done simple experiment of pining ghc compiling ghc-cabal and I've
been able to "speed" it up by 5-10% on W-2265.

Also following this CI/performance regs discussion I'm not entirely sure
if  this is not just a witch-hunt hurting/beating mostly most active GHC
developers. Another idea may be to give up on CI doing perf reg testing
at all and invest saved resources into proper investigation of
GHC/Haskell programs performance. Not sure, if this would not be more
beneficial longer term.

Just one random number thrown to the ring. Linux's perf claims that
nearly every second L3 cache access on the example above ends with cache
miss. Is it a good number or bad number? See stats below (perf stat -d
on ghc with +RTS -T -s -RTS').

Good luck to anybody working on that!

Karel


Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ...
  61,020,836,136 bytes allocated in the heap
   5,229,185,608 bytes copied during GC
 301,742,768 bytes maximum residency (19 sample(s))
   3,533,000 bytes maximum slop
 840 MiB total memory in use (0 MB lost due to fragmentation)

 Tot time (elapsed)  Avg pause  Max
pause
  Gen  0  2012 colls, 0 par5.725s   5.731s 0.0028s
0.1267s
  Gen  119 colls, 0 par1.695s   1.696s 0.0893s
0.2636s

  TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)

  SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INITtime0.000s  (  0.000s elapsed)
  MUT time   27.849s  ( 32.163s elapsed)
  GC  time7.419s  (  7.427s elapsed)
  EXITtime0.000s  (  0.010s elapsed)
  Total   time   35.269s  ( 39.601s elapsed)

  Alloc rate2,191,122,004 bytes per MUT second

  Productivity  79.0% of total user, 81.2% of total elapsed


 Performance counter stats for
'/export/home/karel/sfw/ghc-8.10.3/bin/ghc -H32m -O -Wall -optc-Wall -O0
-hide-all-packages -package ghc-prim -package base -package binary
-package array -package transformers -package time -package containers
-package bytestring -package deepseq -package process -package pretty
-package directory -package filepath -package template-haskell -package
unix --make utils/ghc-cabal/Main.hs -o
utils/ghc-cabal/dist/build/tmp/ghc-cabal -no-user-package-db -Wall
-fno-warn-unused-imports -fno-warn-warnings-deprecations
-DCABAL_VERSION=3,4,0,0 -DBOOTSTRAPPING -odir bootstrapping -hidir
bootstrapping libraries/Cabal/Cabal/Distribution/Fields/Lexer.hs
-ilibraries/Cabal/Cabal -ilibraries/binary/src -ilibraries/filepath
-ilibraries/hpc -ilibraries/mtl -ilibraries/text/src
libraries/text/cbits/cbits.c -Ilibraries/text/include
-ilibraries/parsec/src +RTS -T -s -RTS':

 39,632.99 msec task-clock#0.999 CPUs
utilized
17,191  context-switches  #0.434 K/sec

 0  cpu-migrations#0.000 K/sec

   899,930  page-faults   #0.023 M/sec

   177,636,979,975  cycles#4.482 GHz
  (87.54%)
   181,945,795,221  instructions  #1.02  insn per
cycle   (87.59%)
34,033,574,511  branches  #  858.718 M/sec
  (87.42%)
 1,664,969,299  branch-misses #4.89% of all
branches  (87.48%)
41,522,737,426  L1-dcache-loads   # 1047.681 M/sec
  (87.53%)
 2,675,319,939  L1-dcache-load-misses #6.44% of all
L1-dcache hits(87.48%)
   372,370,395  LLC-loads #9.395 M/sec
  (87.49%)
   173,614,140  LLC-load-misses   #   46.62% of all
LL-cache hits (87.46%)

  39.663103602 seconds time elapsed

  38.288158000 seconds user
   1.358263000 seconds sys
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 9.0.1 released

[Karel Gardas]

Hi Jens,

tested and this works! Thanks a lot,

Karel

On 2/9/21 2:24 AM, Jens Petersen wrote:
> Hi Karel,
> 
> On Tue, 9 Feb 2021 at 00:56, Karel Gardas  <mailto:karel.gar...@centrum.cz>> wrote:
> 
> [karel@localhost ~]$ sudo dnf --enablerepo=updates-testing-modular
> install ghc:9.0/default
> 
>  
> Apologies, I thought I had tested, but I copied without the 'module'
> command, it should be:
> 
> $ sudo dnf --enablerepo=updates-testing-modular module install
> ghc:9.0/default
> 
> Alternatively you can run, eg:
> 
> $ sudo dnf --enablerepo=updates-testing-modular module enable ghc:9.0
> $ sudo dnf --enablerepo=updates-testing-modular install ghc
> 
> etc
> 
> It should go stable in about a week.
> 
> Thanks, Jens
>  

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 9.0.1 released

[Karel Gardas]

Hi Jens,

fedora newbie here. Not sure what I'm doing wrong, but it's not working
on f33/amd64 here:

[karel@localhost ~]$ sudo dnf update
[sudo] password for karel:
Last metadata expiration check: 0:00:33 ago on Mon 08 Feb 2021 05:53:17
PM CET.
Dependencies resolved.
Nothing to do.
Complete!
[karel@localhost ~]$ sudo dnf --enablerepo=updates-testing-modular
install ghc:9.0/default
Last metadata expiration check: 0:00:49 ago on Mon 08 Feb 2021 05:53:17
PM CET.
No match for argument: ghc:9.0/default
Error: Unable to find a match: ghc:9.0/default

Thanks,
Karel

On 2/8/21 5:32 PM, Jens Petersen wrote:
> On Fri, 5 Feb 2021 at 02:04, Ben Gamari  > wrote:
> 
> The GHC team is very pleased to announce the availability of GHC 9.0.1.
> 
> 
> This is now testable in Fedora with:
> 
> sudo dnf --enablerepo=updates-testing-modular install ghc:9.0/default
> 
> Thanks, Jens
> 
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.8.1-alpha2 is now available

[Karel Gardas]

Hi Ben,

On 06/15/19 09:35 PM, Ben Gamari wrote:

Hello everyone,

The GHC team is pleased to announce the second and likely last alpha
release of GHC 8.8.1. The source distribution, binary distributions, and
documentation are available at

 https://downloads.haskell.org/~ghc/8.8.1-alpha2

A draft of the release notes is also available [1].


No sure why, but fix for #13633 has not made into the 8.8 branch. Due to 
this testwsdeque fails from time to time on POWER. Tested on 
ppc64le/ubuntu 18.04. Bootstrapped with ghc 8.6.3.


Is there any chance you may cherrypick Peter's fix in merge request 445? 
Would be great since otherwise besides some profiling related tests 
failing the build looks fine on ppc64le.


Thanks!
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Old build system broken

[Karel Gardas]

Sorry to hijack the thread, I get something very similar on ppc64le linux:

Configuring ghc-prim-0.6.1...
ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error:
No entry for "Tables next to code" in "/tmpram/ghc/inplace/lib/settings"

libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/package-data.mk' failed

make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
Makefile:123: recipe for target 'all' failed
make: *** [all] Error 2

this is from today's HEAD.

Thanks,
Karel

On 05/ 8/19 09:28 PM, Phyx wrote:

That looks like stage1 has been improperly configured.

Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info
*
*
*Return anything sensible for target arch? *
*
*
*I still use the make system exclusively and haven't noticed a failure. *
*
*
*But my nightlies haven't kicked off yet today. *
*
*
*Thanks, *
*Tamar
*
Sent from my Mobile

On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs
mailto:ghc-devs@haskell.org>> wrote:

I know we are supposed to be using Hadrian now, but is the old build
system supposed to be broken? 

A clean build fails with

"inplace/bin/ghc-cabal" check libraries/ghc-prim

"inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install
--with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1"
--with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg"
--disable-library-for-ghci --enable-library-vanilla
--enable-library-for-ghci --disable-library-profiling
--enable-shared --configure-option=CFLAGS="-Wall
-Werror=unused-but-set-variable -Wno-error=inline"
--configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   "
--gcc-options="-Wall -Werror=unused-but-set-variable
-Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold"
--with-ar="ar" --with-alex="/usr/bin/alex"
--with-happy="/usr/bin/happy"

Configuring ghc-prim-0.6.1...

ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited
with an

error:

Failed to read "target arch" value ""

__ __

libraries/ghc-prim/ghc.mk:4 : recipe for target
'libraries/ghc-prim/dist-install/package-data.mk
' failed

make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk
] Error 1

Makefile:123: recipe for target 'all' failed

make: *** [all] Error 2

simonpj@MSRC-3645512:~/code/HEAD$

___
ghc-devs mailing list
ghc-devs@haskell.org 
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Compilation time

[Karel Gardas]

On 07/ 8/17 01:33 AM, Ben Gamari wrote:

8.2 will prefer both gold and lld over bfd ld. However two conditions
must hold for these to be used,

  * The ld.lld/ld.gold executable must be in $PATH (or explicitly named
by passing the LD variable to configure)

  * $CC must understand the `-fuse-ld={gold,lld}` option. For (IMHO quite
silly) political reasons, gcc doesn't support `-fuse-ld=lld`. Debian
happens to patch gcc to add support but I don't know how common this
is in other distributions.

Unfortunately, some earlier `gcc` versions didn't fail if given a
`-fuse-ld` option that they didn't understand. Sadly we have no reliable
way to detect this, so in this case we may end up passing a `-fuse-ld`
option that gcc simply ignores.


I've run into this issue too, but it looks like the issue is not in gcc, 
but in ghc's aclocal.m4 (one '$' missing). Attached patch solves this on 
OpenBSD 6.1-current where HEAD fails building on linker error. It passes 
build-id option to the gcc's linker (bfd ld) which does not support it 
as configure detects lld is presented on this system too.


Sorry for not being able to push that through usual arc.

Thanks,
Karel

diff --git a/aclocal.m4 b/aclocal.m4
index 677c0e77bc..921f137b95 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -2278,6 +2278,7 @@ AC_DEFUN([FIND_LD],[
   [enable_ld_override=yes])
 
 if test "x$enable_ld_override" = "xyes"; then
+BACKUP_LD="$LD"
 AC_CHECK_TARGET_TOOLS([LD], [ld.gold ld.lld ld])
 UseLd=''
 
@@ -2288,8 +2289,13 @@ AC_DEFUN([FIND_LD],[
   "LLD"*)  FP_CC_LINKER_FLAG_TRY(lld, $2) ;;
   *) AC_MSG_NOTICE([unknown linker version $out]) ;;
 esac
-if test "z$2" = "z"; then
+if test "z$$2" = "z"; then
 AC_MSG_NOTICE([unable to convince '$CC' to use linker '$LD'])
+# disable ld override and recheck with just ld
+enable_ld_override=no
+LD="$BACKUP_LD"
+unset ac_cv_prog_ac_ct_LD
+AC_CHECK_TARGET_TOOL([LD], [ld])
 fi
else
 AC_CHECK_TARGET_TOOL([LD], [ld])
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.2.1-rc2 source tarball availability

[Karel Gardas]

On 05/ 8/17 10:58 PM, Ben Gamari wrote:

Note that in addition to the usual complement of Linux/Windows/Darwin
bindists, I have also produced a FreeBSD distribution this time around.
I've noticed that as my tools for producing these distributions improves
the marginal cost of producing another distribution is shrinking. I
would be happy to add OpenBSD as well, but first we'll need to nail
#10032, as far as I understand.


Hi Ben,

the situation on OpenBSD is a little bit lucky than on Solaris since I'm 
not sure if this helps, but "system" libffi is in fact installed into 
/usr/local from ports and there is no other libffi on OpenBSD and this 
by probably lucky coincidence makes GHC working with the only quirk 
which is GNU tar complaining about missing header files while making 
binary-dist:


"rm" -f bindistprep/ghc-8.2.0.20170507-x86_64-unknown-openbsd.tar
cd bindistprep && "/usr/local/bin/gtar" hcf - -T ../bindist-list | 
/usr/local/bin/xz -c > 
../bindistprep/ghc-8.2.0.20170507-x86_64-unknown-openbsd.tar.xz
/usr/local/bin/gtar: ghc-8.2.0.20170507/rts/dist/build/ffi.h: Cannot 
stat: No such file or directory
/usr/local/bin/gtar: ghc-8.2.0.20170507/rts/dist/build/ffitarget.h: 
Cannot stat: No such file or directory

/usr/local/bin/gtar: Exiting with failure status due to previous errors
mv bindistprep/*.tar.xz .


anyway, tarbal is generated, it unpacks well, it even install well (with 
just ./configure --prefix=; gmake install) and resulting compiler 
is working and linked libffi is where it should be:



$ ghc --make HelloWorld.lhs 




[1 of 1] Compiling Main ( HelloWorld.lhs, HelloWorld.o )
Linking HelloWorld ...
/usr/local/build/karel/ghc-8.2.1-rc2/lib/ghc-8.2.0.20170507/rts/libHSrts.a(RtsFlags.o): 
In function `copyArg':


rts/RtsFlags.c:1912:0: error:
 warning: warning: strcpy() is almost always misused, please use 
strlcpy()
/usr/local/lib/libgmp.so.10.0: warning: warning: vsprintf() is often 
misused, please use vsnprintf()
/usr/local/build/karel/ghc-8.2.1-rc2/lib/ghc-8.2.0.20170507/rts/libHSrts.a(RtsUtils.o): 
In function `showStgWord64':


rts/RtsUtils.c:220:0: error:
 warning: warning: sprintf() is often misused, please use snprintf()
$ ldd HelloWorld 




HelloWorld:
StartEnd  Type Open Ref GrpRef Name
1116e270 1116e29e7000 exe  20   0  HelloWorld
1119d555b000 1119d585a000 rlib 01   0 
/usr/local/lib/libiconv.so.6.0
1119b2138000 1119b23af000 rlib 01   0 
/usr/local/lib/libgmp.so.10.0
11195fd4e000 11195ff75000 rlib 01   0 
/usr/lib/libm.so.10.0
11197e36b000 11197e573000 rlib 01   0 
/usr/local/lib/libffi.so.1.2
111950004000 111950213000 rlib 02   0 
/usr/lib/libpthread.so.23.0
1119addd3000 1119ae09e000 rlib 01   0 
/usr/lib/libc.so.89.4
111980e0 111980e0 rtld 01   0 
/usr/libexec/ld.so
$ ./HelloWorld 




Hello world!$


so if you like you can give it a try on your OpenBSD. If you are using 
latest 6.1 please make sure you build and test on wxallowed mount:


$ pwd
/usr/local/build/karel/ghc-8.2.0.20170507
$ mount
/dev/sd1a on / type ffs (local)
/dev/sd1d on /usr/local type ffs (local, nodev, wxallowed)

otherwise you would get strange "No permission error" while executing 
any GHC generated executable including tests run by ./configure. I.e. 
OpenBSD starts to be more picky about programs which execute code from 
writeable memory page and such security sinners need to be run from 
wxallowed paths only. Matthias Killian (cced) has done some work on GHC 
to fix that but IIRC he hit the wall somewhere in rts (IIRC) so nothing 
from this yet.



Thanks,
Karel

___
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

[Karel Gardas]

On 04/ 5/17 10:01 PM, Sergei Trofimovich wrote:

   - pkg_add libiconv


Indeed, I completely overlooked this missing in pkg_add line. Anyway, 
the configure is the correct one --with-iconv*...


Thanks for correction Sergei,

Karel


___
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

[Karel Gardas]

LGTM, although I've not needed to do any python business you do, but 
IMHO does not hurt anyway.


Thanks,
Karel

On 04/ 5/17 09:39 AM, Adam Steen wrote:

Hi All

I have created the Building/Preparation/OpenBSD Wiki Page, i have not
yet link it to Building/Preparation
 page yet,
but am looking for a review

Setting Up a OpenBSD System for Building GHC


Cheers
Adam


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Building head on Openbsd

[Karel Gardas]

On 03/26/17 04:54 PM, Sergei Trofimovich wrote:

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.


Well, my patch looks exactly like yours. Anyway, thanks for such fast 
solution and commit.


Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Building head on Openbsd

[Karel Gardas]

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...


Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Attempt at a real world benchmark

[Karel Gardas]

Sorry for hijacking the thread, but

On 12/ 9/16 10:50 AM, Simon Peyton Jones via ghc-devs wrote:

I have wanted telemetry for years.  ("Telemetry" is the term Microsoft, and I 
think others, use for the phone-home feature.)


telemetry or better "call-home", this is very dangerous idea to even 
mention in the context of the compiler. In some circles even mentioning 
this may result in losing the trust put in the compiler.



It would tell us how many people are using GHC; currently I have literally no 
idea.


For this you don't need any kind of telemetry, but you can use numbers 
from various distributions popularity contests. E.g. debian:


https://qa.debian.org/popcon.php?package=ghc
https://qa.debian.org/popcon.php?package=alex
https://qa.debian.org/popcon.php?package=happy
https://qa.debian.org/popcon.php?package=haskell-platform


It could tell us which language features are most used.


Language features are hard if they are not available in separate libs. 
If in libs, then IIRC debian is packaging those in separate packages, 
again you can use their package contest.



Perhaps it could tell us about performance, but I'm not sure how we could make 
use of that info without access to the actual source.


So then, how may GHC users trust GHC not sending their own precious 
sources "home" just for GHC performance improvements -- which btw, may 
not be in the interest of the users as they may be happy with current state?



The big issue is (a) design and implementation effort, and (b) dealing with the 
privacy issues.  I think (b) used to be a big deal, but nowadays people mostly 
assume that their software is doing telemetry, so it feels more plausible.  But 
someone would need to work out whether it had to be opt-in or opt-out, and how 
to actually make it work in practice.


Privacy here is complete can of worms (keep in mind you are dealing with 
a lot of different law systems), I strongly suggest not to even think 
about it for a second. Your note "but nowadays people mostly assume that 
their software is doing telemetry" may perhaps be true in sick mobile 
apps world, but I guess is not true in the world of developing secure 
and security related applications for either server usage or embedded.


So if I may ask, please no, do not do any telemetry/calling home in GHC 
nor in its runtime system and even do not think about it. This is IMHO 
extremely dangerous.


Thanks!
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Compiling on OpenBSD-current

[Karel Gardas]

I've been hit by this during 8.0.2 rc1 binary preparation so if nobody 
else nor you find a time to fix that sooner I'll hopefully find some 
time during this weekend to have a look into it. I'm pretty sure this is 
fairly recent breakage on OpenBSD...


Cheers,
Karel

On 12/ 1/16 12:21 PM, Adam Steen wrote:

Hi

When Compiling on OpenBSD-Current I get the follow error, what do i need
to do to fix this?

Cheers
Adam

===--- building phase 0
gmake --no-print-directory -f ghc.mk  phase=0 phase_0_builds
gmake[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
gmake --no-print-directory -f ghc.mk  phase=1 phase_1_builds
"/usr/local/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi
-osuf  o -hcsuf hc -static  -O0 -H64m -Wall   -package-db
libraries/bootstrapping.conf  -hide-all-packages -i -iutils/hsc2hs/.
-iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build
-iutils/hsc2hs/dist/build/hsc2hs/autogen
-Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include
-optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id
base-4.9.0.0 -package-id containers-0.5.7.1 -package-id
directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id
process-1.4.2.0 -XHaskell2010  -no-user-package-db -rtsopts   -odir
utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
utils/hsc2hs/dist/build-optl-z -optlwxneeded -static  -O0 -H64m
-Wall   -package-db libraries/bootstrapping.conf  -hide-all-packages -i
-iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build
-iutils/hsc2hs/dist/build/hsc2hs/autogen
-Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include
-optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id
base-4.9.0.0 -package-id containers-0.5.7.1 -package-id
directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id
process-1.4.2.0 -XHaskell2010  -no-user-package-db -rtsopts
utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o
utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o
utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o
utils/hsc2hs/dist/build/HSCParser.o
utils/hsc2hs/dist/build/UtilsCodegen.o
utils/hsc2hs/dist/build/Paths_hsc2hs.o

: error:
 Warning: Couldn't figure out linker information!
  Make sure you're using GNU ld, GNU gold or the built in OS
X linker, etc.
cc: wxneeded: No such file or directory
`cc' failed in phase `Linker'. (Exit code: 1)
compiler/ghc.mk:580 :
compiler/stage1/build/.depend-v.haskell: No such file or directory
gmake[1]: *** [utils/hsc2hs/ghc.mk:15 :
utils/hsc2hs/dist/build/tmp/hsc2hs] Error 1
gmake: *** [Makefile:125: all] Error 2



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Status of Harbormaster

[Karel Gardas]

On 10/ 4/16 09:18 AM, Erik de Castro Lopo wrote:

  * AArch64 Linux


That would be awesome if we could get access to a decent (by which I mean
server grade, with at least 4 cores and 8 Gig of RAM).


Just ask for account on GNU GCC Compile Farm. They do have X-gene V1 
machine in the farm, pretty powerful box especially in comparison with 
my pandaboard. I for example keep running POWER7 buildbot for GHC there.


Cheers,
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Solaris feature_tests.h

[Karel Gardas]

Hi Ben,

sending Oracle copyrighted header file to public mailing list is no-go 
for me, I hope you understand it. :-)


Anyway, the problem with the patch[1] is simple: Oracle's Solaris 11 
supports max:


#define _POSIX_C_SOURCE 200112L
#define _XOPEN_SOURCE   600

the patch[1] assigned values:

#define _POSIX_C_SOURCE 200809L
#define _XOPEN_SOURCE   700


which are not recognized by Oracle's feature_tests.h hence the complain 
and #error.


I've verified this fact on both Solaris 11.2 and Solaris 11.3. On the 
other hand Illumos derivates should be OK with the definition of 
patch[1] as Illumos sometime in its history added handling for XPG7[2]. 
Basically if you look into history of Illumos feature_tests.h and you 
get the first commit[3], then you basically will see what's in Solaris 
11.2/11.3 minus few really unrelated changes done in Solaris.



I hope it's more clear now, what's happened with[1] on Solaris.

Thanks!
Karel


[1] 
https://git.haskell.org/ghc.git/commitdiff/cac3fb06f4b282eee21159c364c4d08e8fdedce9


[2]: 
https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/feature_tests.h


[3]: 
https://raw.githubusercontent.com/illumos/illumos-gate/7c478bd95313f5f23a4c958a745db2134aa03244/usr/src/uts/common/sys/feature_tests.h


On 09/26/16 09:17 AM, Ben Gamari wrote:

Hi Karel,

A few months ago we reverted a cleanup [1] to PosixSource.h due to
breakage on Solaris. I believe I have found [2] a build log from a
failing build, but sadly it's far from clear what is going on. Do you
suppose you could send us your /usr/include/sys/feature_tests.h? I
suspect this will shed some light on what has gone wrong.

For the record, I've opened #12624 to track this issue.

Cheers,

- Ben


[1] 
https://git.haskell.org/ghc.git/commitdiff/cac3fb06f4b282eee21159c364c4d08e8fdedce9
[2] http://haskell.inf.elte.hu/builders/solaris-amd64-head/573/10.html



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC build currently broken on OS X and Windows

[Karel Gardas]

Hi,

side note, it's also broken by cac3fb06f4b282eee21159c364c4d08e8fdedce9 
on Solaris. I'll hopefully get to it during the weekend.


Karel

On 07/21/16 10:59 PM, Erik de Castro Lopo wrote:

Hi all.

The recent Compact Regions commit (cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453)
builds fine on Linux but doesn't build on OS X and is at least 99% certain
not to build on Windows.

I'm in the process of fixing it, but it will be 24-36 hours before I have
a patch ready.

Erik



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: CMM-to-ASM: Register allocation wierdness

[Karel Gardas]

On 06/16/16 12:53 PM, Harendra Kumar wrote:

A thought that came to my mind was whether we should focus on getting
better code out of the llvm backend or the native code generator. LLVM
seems pretty good at the specialized task of code generation and low
level optimization, it is well funded, widely used and has a big
community support. That allows us to leverage that huge effort and take
advantage of the new developments. Does it make sense to outsource the
code generation and low level optimization tasks to llvm and ghc
focussing on higher level optimizations which are harder to do at the
llvm level? What are the downsides of using llvm exclusively in future?


Good reading IMHO about the topic is here: 
https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend


Cheers,
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8.0.1 source tarballs available (yet again)

[Karel Gardas]

On 05/17/16 03:02 PM, Andrés Sicard-Ramírez wrote:

On 17 May 2016 at 07:38, Ben Gamari  wrote:

tl;dr: We are giving this release another attempt. Cross your fingers
and try building again.

Hello GHC packagers,

Thanks for your help in the last few days working through what were
hopefully the last issues in the release. I've uploaded a new set of
source tarballs at,

 http://downloads.haskell.org/~ghc/8.0.1/


I got the following error (on Linux):

$ make
/usr/bin/ld: cannot find -lHSghc-boot-th-8.0.1
collect2: ld returned 1 exit status
make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1


That's exactly the issue which should be fixed in this round. Ben cited 
this as an issue affecting Solaris and FreeBSD and you are lucky to be 
able to duplicate this on Linux.


Anyway, please verify that your -src.tar.xz does have following sha256 sum:

b677e215cdfa22fba534b9bf7b530a056113c1f01002eae5b576e92ced9193ba

I guess you are using older sources from previous round as website is 
notoriously known for excessive caching...


Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

[Karel Gardas]

On 05/14/16 10:18 PM, Páli Gábor János wrote:

2016-05-14 13:06 GMT+02:00 Karel Gardas <karel.gar...@centrum.cz>:

On 05/14/16 11:28 AM, Ben Gamari wrote:

The pragmatist in me wants to answer 1) yes, 2) no, although I do
dislike the idea of distributing binaries that weren't derived from the
associated source tarball.


I guess all other Linuxes naturally use gnu
make as `make' and Windows in msys too so only non-GNU/non-Linux
systems should be affected and from those only FreeBSD has caught this.


Yes, that is possible.  I do not know either Solaris or OpenBSD well
enough, but I suspect they might have GNU make(1) installed in their
paths as `make` or their default make(1) can understand GNU-style


No, on Solaris `make` is some Sun/Oracle make:

$ make --version
make: Warning: Ignoring DistributedMake -v option
make: Warning: Ignoring DistributedMake -o option
make: Fatal error: No dmake output dir argument after -o flag

and GNU make is correctly installed as `gmake`:

$ gmake --version
GNU Make 3.82
Built for i386-pc-solaris2.11
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


and on OpenBSD this is the same, except that `make` is BSD make:

$ make --version
make: unknown option -- -
usage: make [-BeiknpqrSst] [-C directory] [-D variable] [-d flags] [-f mk]
[-I directory] [-j max_processes] [-m directory] [-V variable]
[NAME=value] [target ...]


$ gmake --version
GNU Make 4.1
Built for x86_64-unknown-openbsd5.9
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.



Anyhow, in my humble opinion, it is a bad practice the hardwire the
name of the make tool in the sources.


Completely agree with you on this.


If this is
true, then I would recommend "no" to both points and leave the fix in 8.0
branch for 8.0.2...


Well, in theory, FreeBSD is still a Tier-1 platform, so every release
should just build fine without any further efforts.  I am also aware
of the fact I am considered a minority here, and that this is just a
minor technical problem that could wait for some undetermined time.
However, personally, I would be quite disappointed if this promise was
broken.


Hmm, indeed, FreeBSD is tier-1. I'm sorry, but I completely forgotten this.


I am sorry and apologize that I found this bug after the release was
tagged, but I did not have the chance to test it before it was
considered a final release.  I tracked the 8.0.1 Release Candidates
and provided binary tarballs for them, they all went fine, but
apparently that was not enough.


Apparently this slipped from HEAD to 8.0 branch and it should not, 
especially considering this was already on RC4. But well such mistakes 
happen. OK! I've thought to save the energy on building another set of 
dists, but you have my word on this, to have FBSD folks happy I'm ready 
to rebuild again if Ben submits `c' version of 8.0.1 release source 
code. :-)


Cheers,
Karel


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

[Karel Gardas]

On 05/14/16 11:28 AM, Ben Gamari wrote:

Páli Gábor János  writes:


2016-05-13 7:58 GMT+02:00 Páli Gábor János :

2016-05-13 7:55 GMT+02:00 Páli Gábor János :

That is probably because FreeBSD has GNU make(1) as `gmake`, it should
be invoked with that name.  I suspect that, for some reason (which is
unknown to me), the value of the $(MAKE) variable is not respected at
the recursive invocation of make(1).

[..]

Ohh, I was quick to surrender: all you have to do is to
s/make/$(MAKE)/ in line 22 at utils/haddock/doc/ghc.mk.


All right, everything is now filed as #12058.


Thanks Páli! This should now be fixed on the ghc-8.0 branch. The
question how is what should be done about for the 8.0.1 release. It
seems that there are two decisions to be made here,

  1. Do we cut a new source tarball and bump the tag?
  2. If so, do we throw out the existing binary distributions?

The pragmatist in me wants to answer 1) yes, 2) no, although I do
dislike the idea of distributing binaries that weren't derived from the
associated source tarball.


This is interesting since I build dists for solaris and openbsd and none 
of those were affected by the bug. I guess all other Linuxes naturally 
use gnu make as `make' and Windows in msys too so only non-GNU/non-Linux 
systems should be affected and from those only FreeBSD has caught this. 
If this is true, then I would recommend "no" to both points and leave 
the fix in 8.0 branch for 8.0.2...


or! you can create 8.0.1b sources and rebuild on FreeBSD to have 8.0.1b 
binary dist for this platform. Anyway I think nobody will shoot anyone 
if Gabor just fix it in his own tree and rebuild silently fixed 8.0.1.


Cheers,
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Mentor for a JVM backend for GHC

[Karel Gardas]

On 05/ 2/16 07:55 PM, Rahul Muttineni wrote:

@Karel: Yeah it is, but the reward of being able to run Haskell anywhere
is definitely worth it! I'm aware of the LambdaVM project. I didn't
mention it because I wanted to focus on the present. I sent Brian Alliet
an email asking for guidance on architectural decisions a while back,
but have received no response.

I'd be interested in having a copy of the LambdaVM source, thanks. There
are a couple of places in the design I'm iffy on, so it'd be nice to
have a source of inspiration.


http://uloz.to/x3q5Mmi1/lambdavm-tar-bz2 -- this is 50 MB. I've not 
`gmake clean' it so you see what's compiled in jar/classes and what's 
not. Pity, if you'd like to have it running (besides already precompiled 
examples) you would need either Solaris 11 (my host) or "risk" build 
yourself.



Frege is a great project in its own right, but GHC Haskell has become
the standard and I find many of the extensions to be useful in
eliminating many more classes of bugs at compile-time.


Indeed, I'm looking forward to seeing/testing your results.

Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.0.1-rc4 source tarball availability

[Karel Gardas]

Hi,

distros for

sparc-solaris2.11
i386-solaris2.11
x86_64-solaris2.11
powerpc64-linux
x86_64-openbsd5.9

uploaded and signed in http://uloz.to/xPKKdvtV/bindist-tar

Thanks,
Karel

On 04/22/16 04:27 PM, Ben Gamari wrote:

tl;dr: If you would like to produce a binary distribution for GHC
8.0.1-rc4 then let us know, grab the source distribution and
start building. The binary distributions will be all released one
week from today.


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC build time graphs

[Karel Gardas]

On 02/12/16 09:02 PM, Reid Barton wrote:

btw, just recent experience on ARM64 (X-gene board):

bootstrapping 7.10.1 with 7.6.x took: ~120 minutes
bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes

both run as: ./configure; time make -j8


It would be interesting to have the time for bootstrapping 7.10.1 with
7.10.1 too, for comparison.


boostrapping 7.10.1 with 7.10.1 took: ~212 minutes -- but this is not 
comparable directly with numbers above since for whatever reason haddock 
and doc is not build although I've used previous ./configure; time make -j8.


Anyway, parallel make itself is not good to use here since the build 
process may also contain some noise of paralellel make fixes and such.


I think more reliable benchmark may be simple build (single-threaded) of 
ghc-cabal here. I'll see what I can do about that.


Cheers,
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC build time graphs

[Karel Gardas]

On 02/13/16 07:57 PM, Karel Gardas wrote:

On 02/12/16 09:02 PM, Reid Barton wrote:

btw, just recent experience on ARM64 (X-gene board):

bootstrapping 7.10.1 with 7.6.x took: ~120 minutes
bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes

both run as: ./configure; time make -j8


It would be interesting to have the time for bootstrapping 7.10.1 with
7.10.1 too, for comparison.


boostrapping 7.10.1 with 7.10.1 took: ~212 minutes -- but this is not
comparable directly with numbers above since for whatever reason haddock
and doc is not build although I've used previous ./configure; time make
-j8.

Anyway, parallel make itself is not good to use here since the build
process may also contain some noise of paralellel make fixes and such.

I think more reliable benchmark may be simple build (single-threaded) of
ghc-cabal here. I'll see what I can do about that.


OK, so not everything is that bad. Benchmarking compilation of GHC 
7.10.1 ghc-cabal tool reveals:


GHC 7.6.3: ~12 minutes
GHC 7.10.1: ~24 minutes
GHC 8.0.1 RC2: ~14 minutes

Please note that GHC 7.6.3 compiles 89 files while GHC 7.10.1 and 8.0.1 
RC2 compile 90 files. Test done on the same x-gene board like the tests 
above for the reference...


Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC build time graphs

[Karel Gardas]

On 02/12/16 09:02 PM, Reid Barton wrote:

btw, just recent experience on ARM64 (X-gene board):

bootstrapping 7.10.1 with 7.6.x took: ~120 minutes
bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes

both run as: ./configure; time make -j8


It would be interesting to have the time for bootstrapping 7.10.1 with
7.10.1 too, for comparison.


Good idea, build is running, but is sluggish just from the first sight. 
Running already for 1h20m and still building stage1. This is more in 
line with 8.0.1 I'm afraid. Anyway, I'll update with proper time once it 
is at the end.


Looks like I'll also need to do 7.8.x build to see where we are on this...

Karel


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC build time graphs

[Karel Gardas]

On 01/28/16 11:34 PM, Ben Gamari wrote:

Joachim Breitner  writes:


Hi Oleg,

Am Freitag, den 29.01.2016, 00:22 +0200 schrieb Oleg Grenrus:

Is the same compiler used to build HEAD and 7.10,1?


Good call. In fact, no: 7.10.1 is built with 7.6.3, while HEAD is built
with 7.10.3.

Anthony’s link, i.e.
https://perf.haskell.org/ghc/#compare/ca00def1d7093d6b5b2a937ddfc8a01c152038eb/a496f82d5684f3025a60877600e82f0b29736e85
has links to the build logs of either build; there I could find that 
information.

That might be (part) of the problem. But if it is, it is even worse, as
it would mean not only building the compiler got slower, but the
compiler itself...


I can verify that the build itself is indeed slower. Validating the
current state of ghc-7.10 takes 19 minutes, whereas ghc-8.0 takes 25.5
minutes. This isn't entirely unexpected but the change is quite a bit
larger than I had thought. It would be nice to know which commits are
responsible.


btw, just recent experience on ARM64 (X-gene board):

bootstrapping 7.10.1 with 7.6.x took: ~120 minutes
bootstrapping 8.0.1 RC2 with 7.10.1 took: ~446 minutes

both run as: ./configure; time make -j8

although board is shared I've tried to look at it from time to time and 
have not observed anyone else there so I can assume this is indeed GHC 
slowness on unregisterised -fvia-C ports...


Karel


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Shaking up GHC

[Karel Gardas]

On 01/23/16 06:21 PM, Tuncer Ayaz wrote:

If there's a good way in 8.x (with new Cabal and Shake) to avoid
bundling, while using Shake for ghc --make, then I'm all for it. My
concern is that it has to be as simple as it's currently to install
ghc on a random Linux distro, in order for someone to use a Shakefile.


Not only random Linux distro please! GHC supports a lot of other nice 
OSes and it would be a pity if shake-based build does not support them too.


Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Karel Gardas]

Hi,

SPARC/Solaris 11.2 build: 
https://app.box.com/s/lktjbjtnqv39pil4pkkni4xpn5mi2053

Its signature: https://app.box.com/s/catr69sepivx5xb0g5totl2y6hwrznpj

Signatures of already sent files:
i386/solaris: https://app.box.com/s/it4pih3bi6bq02mfqmnnae13sk7gebb4
amd64/solaris: https://app.box.com/s/okvd7dq3g1jhznkmlf4coug51f83724t
amd64/openbsd: https://app.box.com/s/xa4u80t8htmmqotxwcmdj25soxddgrxb
SHA256SUM: https://app.box.com/s/86ipjn3z3wwzbcpwos8e80qcivn6fnhv

Updated SHA256SUM file: 
https://app.box.com/s/0t3kutu8i3xhhs1vh97x6vcmjdnvlm78


Karel

On 01/14/16 10:27 PM, Karel Gardas wrote:


Hi,

I've build two builds for Solaris 11.2:

i386: https://app.box.com/s/1m75kzunzsz6bqh77py5517t39734446
amd64: https://app.box.com/s/y583zs1tqduz8lbppt66z1qlxms0vytg

Both binary distributions support shared libraries and use system
provided GMP library. If you do not have it installed then you should do
that using "pkg install library/gmp" command.


and one build for OpenBSD 5.9 (current):

amd64: https://app.box.com/s/95lpdhoc5h0zs0mx3chlacdl3hskzkqi

This binary distribution also supports shared libraries and by default
also OpenBSD position independent executables (PIE). It requires gmp,
libffi and libiconv to be installed by "pkg_add " command.


SPARC build for Solaris 11.2 is ongoing.

Karel


On 01/13/16 04:43 PM, Ben Gamari wrote:


The GHC Team is very pleased to announce the first release candidate of
the Glasgow Haskell Compiler 8.0.1 release. Source and binary
distributions as well as the newly revised users guide can be found at

 http://downloads.haskell.org/~ghc/8.0.1-rc1/

This is the first in a series of release candidates which will allow us
to get wider testing of the significant changes that have occurred since
the 7.10 series. These include,

  * the TypeInType extension, which unifies types and kinds allowing for
promotion of more Haskell constructs to the type-level

  * the introduction of type application in source programs

  * support for recursive superclass relationships

  * support for Applicative do notation

  * introduction of the DuplicateRecordFields language extension

  * a rewritten and substantially more thorough pattern match checker

  * the introduction of injective type classes

  * introduction of the Strict and StrictData language extensions,
allowing modules to be compiled with strict-by-default evaluation
of bindings

  * the ability to run the GHCi interpreter in a separate process,
allowing a callstacks in GHCi, easier integration with tooling, and
more

and much more.

Changes of this magnitude will invariably bring bugs. This release
candidate in particular is known to suffer from a few significant issues
which are being actively worked upon,

  * The new -XInjectiveTypeFamilies language extension will likely be
renamed to -XTypeFamilyDependencies

  * #11120: Type representations are missing for some types and promoted
constructors

  * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails

  * #11276: Pattern checker performance can degrade significantly in
presence of pattern matches with guards

  * #11405: Type-level skolem-escape check fails incorrectly

  * #11414: Use of -XStrict results in compiler abort

  * #11379: Instance solver fails to terminate

  * #11419: Haddock documentation is currently not included in the binary
distributions (and hence is missing on downloads.haskell.org)

  * #11370: -Wredundant-constraints being included in -Wall breaks
the three-release compatibility policy

In the coming weeks we will continue to iterate on these issues. We will
also look at Trac tickets marked with "highest" priority on the release
status page [2].

If you have a ticket that you would like to see addressed that does not
meet one of these criteria, please bring this to our attention.
Likewise, if you encounter an issue please open a ticket if one does not
already exist.

Also note that we currently cannot offer 32-bit Windows builds due to
breaking changing in a recent Windows 10 upgrade. We'll work to
resolve this before the 8.0 release but please let us know if this poses
a significant problem for you.

Cheers,

- Ben


[1] https://cygwin.com/ml/cygwin/2015-12/msg3.htm
[2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Karel Gardas]

SHA256SUM: https://app.box.com/s/0t3kutu8i3xhhs1vh97x6vcmjdnvlm78

Sorry for noise,

Karel

On 01/14/16 10:27 PM, Karel Gardas wrote:


Hi,

I've build two builds for Solaris 11.2:

i386: https://app.box.com/s/1m75kzunzsz6bqh77py5517t39734446
amd64: https://app.box.com/s/y583zs1tqduz8lbppt66z1qlxms0vytg

Both binary distributions support shared libraries and use system
provided GMP library. If you do not have it installed then you should do
that using "pkg install library/gmp" command.


and one build for OpenBSD 5.9 (current):

amd64: https://app.box.com/s/95lpdhoc5h0zs0mx3chlacdl3hskzkqi

This binary distribution also supports shared libraries and by default
also OpenBSD position independent executables (PIE). It requires gmp,
libffi and libiconv to be installed by "pkg_add " command.


SPARC build for Solaris 11.2 is ongoing.

Karel


On 01/13/16 04:43 PM, Ben Gamari wrote:


The GHC Team is very pleased to announce the first release candidate of
the Glasgow Haskell Compiler 8.0.1 release. Source and binary
distributions as well as the newly revised users guide can be found at

 http://downloads.haskell.org/~ghc/8.0.1-rc1/

This is the first in a series of release candidates which will allow us
to get wider testing of the significant changes that have occurred since
the 7.10 series. These include,

  * the TypeInType extension, which unifies types and kinds allowing for
promotion of more Haskell constructs to the type-level

  * the introduction of type application in source programs

  * support for recursive superclass relationships

  * support for Applicative do notation

  * introduction of the DuplicateRecordFields language extension

  * a rewritten and substantially more thorough pattern match checker

  * the introduction of injective type classes

  * introduction of the Strict and StrictData language extensions,
allowing modules to be compiled with strict-by-default evaluation
of bindings

  * the ability to run the GHCi interpreter in a separate process,
allowing a callstacks in GHCi, easier integration with tooling, and
more

and much more.

Changes of this magnitude will invariably bring bugs. This release
candidate in particular is known to suffer from a few significant issues
which are being actively worked upon,

  * The new -XInjectiveTypeFamilies language extension will likely be
renamed to -XTypeFamilyDependencies

  * #11120: Type representations are missing for some types and promoted
constructors

  * #11334: Solving for Typeable (Proxy :: Proxy 'Compose) fails

  * #11276: Pattern checker performance can degrade significantly in
presence of pattern matches with guards

  * #11405: Type-level skolem-escape check fails incorrectly

  * #11414: Use of -XStrict results in compiler abort

  * #11379: Instance solver fails to terminate

  * #11419: Haddock documentation is currently not included in the binary
distributions (and hence is missing on downloads.haskell.org)

  * #11370: -Wredundant-constraints being included in -Wall breaks
the three-release compatibility policy

In the coming weeks we will continue to iterate on these issues. We will
also look at Trac tickets marked with "highest" priority on the release
status page [2].

If you have a ticket that you would like to see addressed that does not
meet one of these criteria, please bring this to our attention.
Likewise, if you encounter an issue please open a ticket if one does not
already exist.

Also note that we currently cannot offer 32-bit Windows builds due to
breaking changing in a recent Windows 10 upgrade. We'll work to
resolve this before the 8.0 release but please let us know if this poses
a significant problem for you.

Cheers,

- Ben


[1] https://cygwin.com/ml/cygwin/2015-12/msg3.htm
[2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Karel Gardas]

I'm sorry, this is my mistake. I've thought original poster was talking 
about ubuntu 12.04 LTS but it looks like it was mac os x in fact. Sorry 
for this noise.


Karel

On 01/13/16 09:57 PM, Brandon Allbery wrote:

On Wed, Jan 13, 2016 at 3:55 PM, Karel Gardas <karel.gar...@centrum.cz
<mailto:karel.gar...@centrum.cz>> wrote:

On 01/13/16 09:28 PM, George Colpitts wrote:

installs fine on mac but cabal install vector fails on
primitive, looks
to me like gmp library is not provided


gmp should be probably provided by your OS. Looks like you will also
need its -dev version too. Does


Won't help on OS X unless they have Fink installed, and even then that
means potentially getting a different libgmp than base is using.
If base includes libgmp, as it must on Windows / OS X, it should be made
available to other packages.

--
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com <mailto:allber...@gmail.com> ballb...@sinenomine.net
<mailto:ballb...@sinenomine.net>
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Karel Gardas]

On 01/13/16 09:28 PM, George Colpitts wrote:

installs fine on mac but cabal install vector fails on primitive, looks
to me like gmp library is not provided


gmp should be probably provided by your OS. Looks like you will also 
need its -dev version too. Does


sudo apt-get install gmp-dev
or
sudo apt-get install libgmp-dev

helps? Sorry, don't know precise package name on your platform...

Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

Alain,

indeed, on SmartOS you are free to modify the supplied GCC so the fix to 
remove -P is most natural one. On the other hand I'm not so lucky with 
binary Solaris 11.x distribution provided by Oracle so I need to use not 
so clean and nice workarounds...


Karel

On 01/ 1/16 12:17 AM, Alain O'Dea wrote:

cpphs isn't a direct option.  It won't install on SmartOS with Cabal.
GCC 4.7 is the earliest GCC supported so I'll have to try something else
for SmartOS.

It looks like the GCC Specs are the problem.

On Ubuntu the Spec for cpp is:

*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}

On SmartOS the Spec for cpp is:

*cpp:
%{,assembler-with-cpp:-P} %(cpp_subtarget)

I think this is how the -P gets injected.  I think this is correctable.
I had a similar issue with -std=c99 which is the default for C compiling
on Ubuntu but not on SmartOS leading to issues with compiling source
that isn't old school C (like persistent-sqlite).

Anyways I must retire from this and entertain my guests.  Happy New Year
folks.


On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea <alain.o...@gmail.com
<mailto:alain.o...@gmail.com>> wrote:

Thanks for the clarification. I understand now.
On Thu, Dec 31, 2015 at 16:52 Karel Gardas <karel.gar...@centrum.cz
<mailto:karel.gar...@centrum.cz>> wrote:

On 12/31/15 07:41 PM, Alain O'Dea wrote:
 > Yes. I can do that.
 >
 > On SmartOS it may not be GCC 3.4.3 causing this. I see this
on GCC 4.7.x
 > through 4.9.x. The paths to gcc on SmartOS also differ. I'll
have to
 > verify that as part of checking this.

This is misunderstanding. GCC 3.4.3 provides *correct* CPP behavior,
while all 4.x provides broken CPP. That means as a workaround
when GCC
3.4.3 is installed I set it as GHC's CPP automatically on
Solaris. When
it is not available, then GHC behaves like you've seen when
using CPP...

Hopefully this is more clear now,

Karel



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

Hi Alain,

I guess you are hit by well known issue in GCC's CPP on Solaris. Just 
verify here:


https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html

solution in this case is simple: use configure option to set different 
non buggy CPP as a CPP for GHC.


Please let me know if this is the culprit,

Thanks,
Karel

On 12/31/15 08:09 AM, Alain O'Dea wrote:

On SmartOS GHC flag warnings show up like this:
/tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning:
 -fffi is deprecated: use -XForeignFunctionInterface or pragma {-#
LANGUAGE ForeignFunctionInterface #-} instead

It appears that this line in DriverPipeline leads to the correct
filename in warnings on Ubuntu, but not on SmartOS:
src_opts <- liftIO $ getOptionsFromFile dflags0 output_fn
https://github.com/ghc/ghc/blob/bb7f2e33197e667eb694bd1243f125c722a0a868/compiler/main/DriverPipeline.hs#L865

How does the intermediate hscpp filename get restored to a correct
filename if warnings are generated during a re-read of the pragmas after
having preprocessed the file?

Full investigation notes are here (rambling and unedited):
https://gist.github.com/AlainODea/98141991849093285c52


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

Also related: https://haskell-phabricator.global.ssl.fastly.net/D151

as Solaris is not the only problematic platform with CPP, HVR has 
started excellent 'RFC: "Native -XCPP" Proposal' thread in the past 
together with the wiki page: 
https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp


Hope this helps,
Karel


On 12/31/15 09:28 AM, Karel Gardas wrote:


Hi Alain,

I guess you are hit by well known issue in GCC's CPP on Solaris. Just
verify here:

https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html

solution in this case is simple: use configure option to set different
non buggy CPP as a CPP for GHC.

Please let me know if this is the culprit,

Thanks,
Karel

On 12/31/15 08:09 AM, Alain O'Dea wrote:

On SmartOS GHC flag warnings show up like this:
/tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning:
 -fffi is deprecated: use -XForeignFunctionInterface or pragma {-#
LANGUAGE ForeignFunctionInterface #-} instead

It appears that this line in DriverPipeline leads to the correct
filename in warnings on Ubuntu, but not on SmartOS:
src_opts <- liftIO $ getOptionsFromFile dflags0 output_fn
https://github.com/ghc/ghc/blob/bb7f2e33197e667eb694bd1243f125c722a0a868/compiler/main/DriverPipeline.hs#L865


How does the intermediate hscpp filename get restored to a correct
filename if warnings are generated during a re-read of the pragmas after
having preprocessed the file?

Full investigation notes are here (rambling and unedited):
https://gist.github.com/AlainODea/98141991849093285c52


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

On 12/31/15 01:30 PM, Ben Gamari wrote:

Karel Gardas <karel.gar...@centrum.cz> writes:


Hi Alain,

I guess you are hit by well known issue in GCC's CPP on Solaris. Just
verify here:

https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html

solution in this case is simple: use configure option to set different
non buggy CPP as a CPP for GHC.

Please let me know if this is the culprit,


Perhaps we should add an autoconf check to preempt this issue and point
affected users in the direction of a solution?


Hmm, I tried that with https://phabricator.haskell.org/D151 -- but 
perhaps some nice warning emitted during configure time in case of 
undetected GCC 3.4.3 on Solaris will help here? This will also need to 
be done in bindist configure thought.


Alain, would you do that? I'm asking since you've been hit by this 
recently...


Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

On 12/31/15 07:41 PM, Alain O'Dea wrote:

Yes. I can do that.

On SmartOS it may not be GCC 3.4.3 causing this. I see this on GCC 4.7.x
through 4.9.x. The paths to gcc on SmartOS also differ. I'll have to
verify that as part of checking this.


This is misunderstanding. GCC 3.4.3 provides *correct* CPP behavior, 
while all 4.x provides broken CPP. That means as a workaround when GCC 
3.4.3 is installed I set it as GHC's CPP automatically on Solaris. When 
it is not available, then GHC behaves like you've seen when using CPP...


Hopefully this is more clear now,

Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot have GHC in ARMv6 architecture

[Karel Gardas]

On 09/ 9/15 01:22 PM, jmcf...@openmailbox.org wrote:

So, when doing that, configure works (the logs were for the previous
attempts). But why is that when I try to make, with a working configure,
and a real sysroot, that I get the following error?

$ make -j5
(...)
"inplace/bin/mkdirhier" compiler/stage2/doc/html/ghc//.
<>
"inplace/bin/mkdirhier" utils/hsc2hs/dist-install/build/tmp//.
"inplace/bin/mkdirhier" utils/ghc-pkg/dist-install/build/tmp//.
"inplace/bin/mkdirhier" utils/ghctags/dist-install/build/tmp//.
<>
"inplace/bin/mkdirhier" utils/ghc-pwd/dist-install/build/tmp//.
"inplace/bin/mkdirhier" utils/ghc-cabal/dist-install/build/tmp//.
"inplace/bin/mkdirhier" utils/hpc/dist-install/build/tmp//.
"inplace/bin/mkdirhier" utils/runghc/dist-install/build/tmp//.
docs/users_guide/users_guide.xml
make[1]: docs/users_guide/users_guide.xml: Command not found
docs/users_guide/what_glasgow_exts_does.gen.xml
docs/users_guide/ghc.mk:24: recipe for target 
'docs/users_guide/users_guide.xml' failed
make[1]: *** [docs/users_guide/users_guide.xml] Error 127
make[1]: *** Waiting for unfinished jobs
make[1]: docs/users_guide/what_glasgow_exts_does.gen.xml: Command not found
docs/users_guide/ghc.mk:24: recipe for target 
'docs/users_guide/what_glasgow_exts_does.gen.xml' failed
make[1]: *** [docs/users_guide/what_glasgow_exts_does.gen.xml] Error 127
Writing utils/haddock/doc/haddock/license.html for section(license)
Writing utils/haddock/doc/haddock/ch01s03.html for section
Writing utils/haddock/doc/haddock/ch01s04.html for section
Writing utils/haddock/doc/haddock/introduction.html for chapter(introduction)
Writing utils/haddock/doc/haddock/invoking.html for chapter(invoking)
Writing utils/haddock/doc/haddock/ch03s02.html for section
Writing utils/haddock/doc/haddock/ch03s03.html for section
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)
Writing utils/haddock/doc/haddock/ch03s08.html for section
Writing utils/haddock/doc/haddock/markup.html for chapter(markup)
Writing utils/haddock/doc/haddock/ix01.html for index
Writing utils/haddock/doc/haddock/index.html for book(haddock)
cp mk/fptools.css utils/haddock/doc/haddock/
Makefile:71: recipe for target 'all' failed
make: *** [all] Error 2


ghc-stage1 logically does not work, although it is created.


How exactly ghc-stage1 behaves? What does ghc-stage1 --info tells you?

Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot have GHC in ARMv6 architecture

[Karel Gardas]

So ghc-stage1 is working. Good! Now just to find why your base is 
broken, please rebuild ghc completely and this time does not use any -j 
5 option. It'll use just one core, but will stop on the first error. 
Let's see how far you get.


Karel

On 09/ 9/15 02:59 PM, jmcf...@openmailbox.org wrote:

How exactly ghc-stage1 behaves? What does ghc-stage1 --info tells you?

  $ ../inplace/bin/ghc-stage1 --make HelloWorld.lhs

HelloWorld.lhs:1:1:
 Could not find module ‘Prelude’
 There are files missing in the ‘base-4.8.1.0’ package,
 try running 'ghc-pkg check'.
 Use -v to see a list of the files searched for.

  $ ../inplace/bin/ghc-pkg check -v >ghc-pkg.check.log  2>&1



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot have GHC in ARMv6 architecture

[Karel Gardas]

On 09/ 9/15 04:21 PM, jmcf...@openmailbox.org wrote:

So ghc-stage1 is working. Good! Now just to find why your base is broken,
please rebuild ghc completely and this time does not use any -j 5 option.
It'll use just one core, but will stop on the first error. Let's see how far
you get.

Ah. Alright, it took a while longer.

  $ ./configure --target=arm-linux-gnueabihf --with-gcc=arm-linux-gnueabihf-gcc-sysroot 
--enable-unregisterised && make
(...)
"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H64m -O0
-this-package-key ghcpr_8TmvWUcS1U1IKHT0levwg3 -hide-all-packages -i 
-ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build 
-ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build 
-Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.-optP-include 
-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-key rts 
-this-package-key ghc-prim -XHaskell2010 -O -fllvm  -no-user-package-db -rtsopts  
-odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build 
-stubdir libraries/ghc-prim/dist-install/build   -c libraries/ghc-prim/./GHC/CString.hs 
-o libraries/ghc-prim/dist-install/build/GHC/CString.o
You are using a new version of LLVM that hasn't been tested yet!
We will try though...


^ OK you can see this.


opt: /tmp/ghc23881_0/ghc_1.ll:7:6: error: unexpected type in metadata definition
!0 = metadata !{metadata !"top", i8* null}
  ^
libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/build/GHC/CString.o' failed
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/CString.o] Error 1
Makefile:71: recipe for target 'all' failed
make: *** [all] Error 2

This is weird, I think I'm not even using LLVM.


This is not weird at all! GHC does not provide ARM NCG and so it is 
using LLVM if you compile ARM registerised build.


So what about to start with the least pain and install supported LLVM 
version?


Cheers,
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot have GHC in ARMv6 architecture

[Karel Gardas]

On 09/ 9/15 05:59 PM, Reid Barton wrote:

This is not weird at all! GHC does not provide ARM NCG and so it is
using LLVM if you compile ARM registerised build.


But "./configure [...] --enable-unregisterised" should mean using the C
backend, not LLVM, right? So this still looks strange. Also there is an
explicit "-fllvm" on the failing ghc-stage1 command line.


Indeed, I've overlooked that completely and I was referring to previous 
info of `ghc --info' where it's clearly registerised:


 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","7.10.2")
 ,("Project Git commit id","0da488c4438d88c9252e0b860426b8e74b5fc9e8")
 ,("Booter version","7.10.1")
 ,("Stage","1")
 ,("Build platform","x86_64-unknown-linux")
 ,("Host platform","x86_64-unknown-linux")
 ,("Target platform","arm-unknown-linux")


Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot have GHC in ARMv6 architecture

[Karel Gardas]

Hi,

I think sysroot option may help you. I wrote something about it for 
ARMv8 in the past here: 
https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/


Cheers,
Karel

On 09/ 7/15 08:18 PM, jmcf...@openmailbox.org wrote:

Hi,

I have tried to have GHC in my Raspberry Pi, got stuck in the issue 7754
(https://ghc.haskell.org/trac/ghc/ticket/7754), since I didn't know
where to pass options to terminfo's configure file, although I did copy
the headers from my Raspberry Pi. I've been using HUGS ever since, as
Arch Linux doesn't have GHC for ARMv6, and deb2targz would not work.

I'm aware I have a phase 0 compiler installed, need to build a phase 1
compiler, and use that to cross-compile GHC itself (I wasn't the 1st
time I tried, couldn't find as much information as now).

I've read the following pages:
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi
https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling
https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation
along with quite a few bug reports, and questions on Stack Overflow that
seemed related but really aren't, or that are already exposed in the
tickets mentioned below.

Below,
/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/include-curses and
/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/lib-curses are
directories to which I copied any headers and libraries, respectively,
from my Raspberry Pi.

I'm not sure which libraries I am supposed to point configure at. These
are the headers-libraries combinations I tried:

$ ./configure --target=arm-linux-gnueabihf 
--with-curses-includes=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/include-curses
 
--with-curses-libraries=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/lib-curses
 && make -j5
(...)
checking for unistd.h... yes
checking ncurses.h usability... no
checking ncurses.h presence... no
checking for ncurses.h... no
checking curses.h usability... no
checking curses.h presence... no
checking for curses.h... no
configure: error: in `/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo':
configure: error: curses headers could not be found, so this package cannot be 
built
See `config.log' for more details
libraries/terminfo/ghc.mk:4: recipe for target 
'libraries/terminfo/dist-install/package-data.mk' failed
make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1
Makefile:71: recipe for target 'all' failed
make: *** [all] Error 2
(https://ghc.haskell.org/trac/ghc/ticket/7754)

$ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/usr/include 
--with-curses-libraries=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/lib-curses
 && make -j5
(...)
checking for unistd.h... yes
checking ncurses.h usability... yes
checking ncurses.h presence... yes
checking for ncurses.h... yes
checking for setupterm in -ltinfo... no
checking for setupterm in -lncursesw... no
checking for setupterm in -lncurses... no
checking for setupterm in -lcurses... no
configure: error: in `/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo':
configure: error: curses library not found, so this package cannot be built
See `config.log' for more details
libraries/terminfo/ghc.mk:4: recipe for target 
'libraries/terminfo/dist-install/package-data.mk' failed
make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1
Makefile:71: recipe for target 'all' failed
make: *** [all] Error 2
(https://ghc.haskell.org/trac/ghc/ticket/7281)

$ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/usr/include 
--with-curses-libraries=/usr/lib && make -j5

$ ./configure --target=arm-linux-gnueabihf 
--with-curses-includes=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/include-curses
 --with-curses-libraries=/usr/lib && make -j5
(...)
Configuring terminfo-0.4.0.1...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking for arm-unknown-linux-gnueabihf-gcc...
/home/jmcf125/ghc-raspberry-pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc
checking whether the C compiler works... no
configure: error: in `/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo':
configure: error: C compiler cannot create executables
See `config.log' for more details
libraries/terminfo/ghc.mk:4: recipe for target 
'libraries/terminfo/dist-install/package-data.mk' failed
make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 77
Makefile:71: recipe for target 'all' failed
make: *** [all] Error 2

Concerning the last 2, it'd be odd if they worked, how could, say, the
GCC cross-compiler for ARM use x86_64 libraries? I tried them anyway,
since the 1st 2 errors didn't seem to make sense...

Also, options --includedir and --oldincludedir seem to have no effect
(always get issue 7754), and it doesn't matter if I build registarised
or not, the results are the same (registarised, I'm using LLVM 3.6.2-3).

I'm sorry if I'm wasting your time with what to you might 

Re: Two step allocator for 64-bit systems

[Karel Gardas]

Dear Giovanni,

thanks to Erik for pointing this out, very similar issue of 1TB 
allocation on dll-split is also happening on amd64-solaris11. I can't 
say this is the same issue yet as I've not debug that fully yet -- will 
do as time permits, but at least you know something else similar 
suspicious also happens on yet another platform...


Thanks,
Karel

On 08/24/15 01:54 PM, Erik de Castro Lopo wrote:

Dear Giovanni,

Your commit:

 commit 0d1a8d09f452977aadef7897aa12a8d41c7a4af0
 Author: Giovanni Campagna gcamp...@cs.stanford.edu
 Date:   Fri Jul 17 11:55:49 2015 +0100

 Two step allocator for 64-bit systems

fails for me on Arm64 (also known as AArch64) Linux.

I was wondering if you might be able to look at this ticket I've
raised and hopefully shed some light on this issue:

 https://ghc.haskell.org/trac/ghc/ticket/10682

Cheers,
Erik



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 7.10.2 plans

[Karel Gardas]

Hi Ben,

count with me. I always thought it may be a good idea to allow some time 
to builders to do their job. For me this means few hours for i386/amd64 
solaris build and test and unfortunately about a day (~10 hours) of 
noisy run for sparc solaris build but I'll do it last time since I hope 
7.12 will have fixed SPARC NCG which should cut the time to half or I'll 
buy faster sparc gear. :-)


Generally speaking Monday morning is the best time for me. Then Wednesday.

Cheers,
Karel

On 07/10/15 04:46 PM, Ben Gamari wrote:

Hi GHCers,

So 7.10.2 is, believe it or not, slowly converging. After finding and
fixing a number of regressions since 7.10.1 (including, unfortunately, a
few only found this week), I think we finally have a source tree that
could possibly be called 7.10.2.

I have been in communication with Herbert, who has built .debs from a
snapshot of the ghc-7.10 branch. They are currently available on his
PPA [1] (see the ghc-7.10.2-7.10.1.20150710-0 debs). Michael will be
using these to do a trial-build of Stackage. Hopefully by Monday we
will have a pretty good idea of whether the tree is fit for release.

When all of this happens we will be ready to cut the release. As usual,
I will be doing binary builds for 32- and 64-bit Linux and Windows. As I
understand it, a subset of you have in the past offered binary builds
for other platforms,

  * Mark: Mac OS X, some Haskell Platform platforms
  * Pali: FreeBSD
  * Karel: Solaris

Would you be willing to do this again? Ideally we would have these
packages available the day of the release. Assuming we can get a final,
Stackage-validated source tarball by Monday, when do you think we could
have all of these prepared?

I'm willing to hold off announcing the release until late next week or
all of these releases are available, whichever happens first (unless
there is widespread agreement within this group that this is not enough
time).

Cheers,

- Ben


[1] https://launchpad.net/~hvr/+archive/ubuntu/ghc/



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New GHC performance dashboard

[Karel Gardas]

On 05/17/15 02:19 PM, Joachim Breitner wrote:

provided me with the required set (thanks for that!), so here it is:

 http://perf.haskell.org/ghc

It should be relatively self-explanatory.


Joachim,

this is indeed great stuff. But although it's self-explanatory I'm not 
able to find out what I'm looking for, i.e. simple way to see graph of 
whole nofib performance results. i.e. not graphs per benchmark, but per 
whole nofib suite. Is that possible?


Thanks!
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Some test data

[Karel Gardas]

On 05/17/15 08:12 PM, Tamar Christina wrote:

Hi All,

I’m currently busy rewriting the GHC-split perl script into Haskell and
require some for the platforms I don’t have at the moment.

I require an example file(s) for:
   - Apple Darwin
   - Sparc
  - PowerPC Linux
  - X86 Linux
  - X86_64 Linux

The test file I require can be generated using
ghc -split-objs -keep-tmp-files -v hs_file

and I’m looking for the file ending with .split_s  (e.g.
R:\Temp\ghc1764_0\ghc1764_2.split_s)

Any file of a non-trivial nature would be helpful.


I can do SPARC for you, but you need to be more specific:

1) what GHC shall I use? Is 7.6.x ok for it? Or 7.10.x?

2) choose one or more files from GHC HEAD and tell what and I'll 
generate what you need...


Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: RFC: Native -XCPP Proposal

[Karel Gardas]

Herbert,

what about to extend plan (1) to also include cpphs as a bundled option 
with all cpphs advantages except no more fork/exec as the bundle will be 
in a form of binary application and not library?


Shall I add it? I would not like to make a mess from your page...

Thanks,
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phabricator as bug tracker system (off topic)

[Karel Gardas]

On 04/14/15 08:52 AM, Jan Stolarek wrote:

And now on topic:
- the only project I've been using Trac for is GHC. It seems to lack some more 
advanced features
but from a developer's perspective it conatins everything necessary to do the 
job. It can be
customized to the needs of a project. I think the only major downside of Trac 
is that a single
installation can only run a single project. Probably not a problem for Agda.


Jan,

I'm using Trac for managing 5 independent internal projects without a 
problem and this is a single installation.


Cheers,
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Rename driver phases C(obj)cpp to C(obj)cplusplus (abde5da)

[Karel Gardas]

Hi Thomas,

Cplusplus is quite long identifier, bad for eyes. Usually in C++ 
community if you can't use cpp then you use cxx. It's shorter and clear 
even when reading fast, don't you think?


Karel

PS: of course even before cxx it was CC, but I think this does not have 
any advantage over cxx in this context...


On 03/27/15 09:38 PM, g...@git.haskell.org wrote:

Repository : ssh://g...@git.haskell.org/ghc

On branch  : master
Link   : 
http://ghc.haskell.org/trac/ghc/changeset/abde5da4dee5f3b83264f8471e458b20d04f8b29/ghc


---


commit abde5da4dee5f3b83264f8471e458b20d04f8b29
Author: Thomas Miedemathomasmied...@gmail.com
Date:   Fri Mar 27 21:37:49 2015 +0100

 Rename driver phases C(obj)cpp to C(obj)cplusplus

 Before:
 Cpp = Pre-process C
 Ccpp= Compile C++
 Cobjcpp = Compile Objective-C++
 CmmCpp  = Pre-process Cmm

 Quite confusing! This commit renames `Ccpp` to `Ccplusplus`, and
 `Cobjcpp` to `Cobjcplusplus`. The two letters `p-p` keep standing for
 `pre-processing` throughout the compiler.

 Reviewed By: austin

 Differential Revision: https://phabricator.haskell.org/D756



---


abde5da4dee5f3b83264f8471e458b20d04f8b29
  compiler/main/DriverPhases.hs   | 32 
  compiler/main/DriverPipeline.hs |  9 +
  ghc/Main.hs |  2 +-
  3 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/compiler/main/DriverPhases.hs b/compiler/main/DriverPhases.hs
index 2433f6d..2d7d904 100644
--- a/compiler/main/DriverPhases.hs
+++ b/compiler/main/DriverPhases.hs
@@ -111,10 +111,10 @@ data Phase
  | Cpp   HscSource
  | HsPp  HscSource
  | Hsc   HscSource
-| Ccpp
-| Cc
-| Cobjc
-| Cobjcpp
+| Ccplusplus-- Compile C++
+| Cc-- Compile C
+| Cobjc -- Compile Objective-C
+| Cobjcplusplus -- Compile Objective-C++
  | HCc   -- Haskellised C (as opposed to vanilla C) compilation
  | Splitter  -- Assembly file splitter (part of '-split-objs')
  | SplitAs   -- Assembler for split assembly files (part of 
'-split-objs')
@@ -148,10 +148,8 @@ eqPhase (Unlit _)   (Unlit _)  = True
  eqPhase (Cpp   _)   (Cpp   _)  = True
  eqPhase (HsPp  _)   (HsPp  _)  = True
  eqPhase (Hsc   _)   (Hsc   _)  = True
-eqPhase CcppCcpp   = True
  eqPhase Cc  Cc = True
  eqPhase Cobjc   Cobjc  = True
-eqPhase Cobjcpp Cobjcpp= True
  eqPhase HCc HCc= True
  eqPhase SplitterSplitter   = True
  eqPhase SplitAs SplitAs= True
@@ -163,7 +161,9 @@ eqPhase CmmCpp  CmmCpp = True
  eqPhase Cmm Cmm= True
  eqPhase MergeStub   MergeStub  = True
  eqPhase StopLn  StopLn = True
-eqPhase _   _  = False
+eqPhase Ccplusplus Ccplusplus = True
+eqPhase Cobjcplusplus  Cobjcplusplus  = True
+eqPhase _  _  = False

  -- Partial ordering on phases: we want to know which phases will occur before
  -- which others.  This is used for sanity checking, to ensure that the
@@ -189,10 +189,10 @@ nextPhase dflags p
LlvmMangle -  As False
SplitAs-  MergeStub
As _   -  MergeStub
-  Ccpp   -  As False
+  Ccplusplus -  As False
Cc -  As False
Cobjc  -  As False
-  Cobjcpp-  As False
+  Cobjcplusplus -  As False
CmmCpp -  Cmm
Cmm-  maybeHCc
HCc-  As False
@@ -215,13 +215,13 @@ startPhase hscpp= HsPp  HsSrcFile
  startPhase hspp = Hsc   HsSrcFile
  startPhase hc   = HCc
  startPhase c= Cc
-startPhase cpp  = Ccpp
+startPhase cpp  = Ccplusplus
  startPhase C= Cc
  startPhase m= Cobjc
-startPhase M= Cobjcpp
-startPhase mm   = Cobjcpp
-startPhase cc   = Ccpp
-startPhase cxx  = Ccpp
+startPhase M= Cobjcplusplus
+startPhase mm   = Cobjcplusplus
+startPhase cc   = Ccplusplus
+startPhase cxx  = Ccplusplus
  startPhase split_s  = Splitter
  startPhase s= As False
  startPhase S= As True
@@ -247,9 +247,9 @@ phaseInputExt (Hsc   _)   = hspp  -- 
intermediate only
  -- because runPipeline uses the StopBefore phase to pick the
  -- output filename.  That could be fixed, but watch out.
  phaseInputExt HCc = hc
-phaseInputExt Ccpp= cpp
+phaseInputExt Ccplusplus  = cpp
  phaseInputExt Cobjc   = m
-phaseInputExt Cobjcpp = mm
+phaseInputExt Cobjcplusplus   = mm
  phaseInputExt Cc  = c
  phaseInputExt Splitter= split_s
  phaseInputExt (As True)   = S
diff --git a/compiler/main/DriverPipeline.hs 

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3

[Karel Gardas]

On 03/19/15 03:38 PM, Jens Petersen wrote:


I tried building RC3 on Fedora Rawhide and hit this surprise i686 failure:



Jens,

are you by any chance building RC3 with RC1/2 ? If so, then this is not 
well supported. I already reported this issue to ghc-devs few days/weeks 
ago.


Karel




https://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.10/fedora-rawhide-i386/ghc-7.10.0.20150316-0.5.fc21/build.log
[400kB]

```
/usr/bin/ghc -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db
libraries/bootstrapping.conf -this-package-key
ghc_FEyGu5JjJqTFXJN7t0AjtZ -hide-all-packages -i -icompiler/basicTypes
-icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar
-icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen
-icompiler/main -icompiler/nativeGen -icompiler/parser
-icompiler/prelude -icompiler/profiling -icompiler/rename
-icompiler/simplCore -icompiler/simplStg -icompiler/specialise
-icompiler/stgSyn -icompiler/stranal -icompiler/typecheck
-icompiler/types -icompiler/utils -icompiler/vectorise
-icompiler/stage1/build -icompiler/stage1/build/autogen
-Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/.
-Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include
-optPcompiler/stage1/build/autogen/cabal_macros.h -package-key
array_3w0nMK0JfaFJPpLFn2yWAJ -package-key base_469rOtLAqwTGFEOGWxSUiQ
-package-key binpa_IZvsDnGi11pBzTC71ohLx0 -package-key
bytes_GyKPtAP9tDU8R3kplaOsGL -package-key conta_LC4pLE3kBzGKpeTiXrfSYW
-package-key direc_CDNjUHiqrmpKhmAfHuWHQd -package-key
filep_1vDJvPDP7mkAk0dVCj6gws -package-key hoopl_67gYDpMwqMo76vntD1o2bl
-package-key hpc_JgusJLXnrCmLlRsEHGsV8F -package-key
proce_8QjZAz7MOkA18YytQjzGwY -package-key time_GZv5NIWYuYvJeCRUBFgGQL
-package-key trans_A1N0ErqCzkOAdEhQZ5kT5v -package-key
unix_0eL7iagUGBD0Zhli8uoZQW -Wall -fno-warn-name-shadowing
-this-package-key ghc -XHaskell2010 -DSTAGE=1 -Rghc-timing
-no-user-package-db -rtsopts -odir compiler/stage1/build -hidir
compiler/stage1/build -stubdir compiler/stage1/build -c
compiler/utils/Pair.hs -o compiler/stage1/build/Pair.o

compiler/utils/Pair.hs:38:32:
 Not in scope: ‘$’
 Perhaps you meant one of these:
   ‘*’ (imported from Prelude), ‘+’ (imported from Outputable),
   ‘’ (imported from Outputable)

```

Not sure how reproducible it is: I am firing off another build now on Fedora 22 
and 23:

https://copr.fedoraproject.org/coprs/petersen/ghc-7.10/build/82399/

I managed to build RC3 on Fedora aarch64.

Jens



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

HEAD not buildable by 7.10.1 RC3?

[Karel Gardas]

Hi,

for a few last days I'm not able to build amd64/solaris11 build of HEAD 
using 7.10.1. I've been using RC1 for this, then post RC2 and now RC3 
and the issue is still the same:


ld: fatal: library -lHSghc-7.11.20150318-5E218FiotzLAN97RtaMkIl: not found
ld: fatal: file processing errors. No output written to 
ghc/stage1/build/tmp/ghc-stage1

collect2: ld returned 1 exit status
gmake[1]: *** [ghc/stage1/build/tmp/ghc-stage1] Error 1
gmake: *** [all] Error 2


the problem is that the library which is created is named: 
libHSghc-7.11-5E218FiotzLAN97RtaMkIl.a and so yearmonthday is 
missing there, hence linking fails.


I assume this may be caused by the patch below, but I'm not sure so if 
I'm mistaken here I'm sorry for this Edward.


Anyway, I would like to raise this concern since we're already in RC3 
for 7.10.1 and if something needs to be changed there, it would be 
better to do that rather sooner IMHO. Although this is issue on Solaris 
I assume it to be same on Linux, except that we probably don't have 
user/buildbot building HEAD with not yet release 7.10.1 and so we do not 
have this reported. Solaris11/amd64 is kind of special here, since the 
support for this platform is new in 7.10.1 and so I need to use this 
unreleased compiler.


For compilation log please have a look into amd64/solaris11 buildbot 
output: 
http://haskell.inf.elte.hu/builders/solaris-amd64-head/232/10.html -- 
this is still using post-RC2 as a bootstrap compiler, but the issue with 
RC3 is  the same.



Thanks!
Karel



commit 838d8044896b6544d8c80c2ab5de63d97220f06c
Author: Edward Z. Yang ezy...@cs.stanford.edu
Date:   Wed Mar 11 14:53:17 2015 +0100

Update Cabal submodule to latest 1.22 snapshot

This changes the library file name format

NOTE: This patch originally updated to Cabal HEAD, but was reduced to
  update to Cabal 1.22 HEAD by hvr as this is needed in order to
  update the filepath submodule to version 1.4.0, and subsequently
  to be cherry-picked into the ghc-7.10 branch

Signed-off-by: Edward Z. Yang ezy...@cs.stanford.edu

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D707


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

How to better parallelize GHC build.

[Karel Gardas]

Folks,

first of all, I remember someone already mentioned issue with decreased 
parallelism of the GHC build recently somewhere but I cann't find it 
now. Sorry, for that since otherwise I would use this thread if it was 
on this mailing list.


Anyway, while working on SPARC NCG I'm using T2000 which provides 32 
threads/8 core UltraSPARC T1 CPU. The property of this machine is that 
it's really slow on single-threaded work. To squeeze some perf from it 
man really needs to push 32 threads of work on it. Now, it really hurts 
my nerves to see it's lazy building/running just one or two ghc 
processes. To verify the fact I've created simple script to collect 
number of ghc processes over time and putting this to graph. The result 
is in the attached picture. The graph is result of running:


gmake -j64

anyway, the average number of running ghc processes is 4.4 and the 
median value is 2. IMHO such low number not only hurts build times on 
something like CMT SPARC machine, but also on let say a cluster of ARM 
machines using NFS and also on common engineering workstations which 
provide these days (IMHO!) around 8-16 cores (and double the threads 
number).


My naive idea(s) for fixing this issue is (I'm assuming no Haskell file 
imports unused imports here, but perhaps this may be also investigated):


1) provide explicit dependencies which guides make to build in more 
optimal way


2) hack GHC's make depend to kind of compute explicit dependencies from 
(1) in an optimal way automatically


3) someone already mentioned using shake for building ghc. I don't know 
shake but perhaps this is the right direction?


4) hack GHC to compile needed hi file directly in its memory if hi file 
is not (yet!) available (issue how to get compiling options right here). 
Also I don't know hi file semantics yet so bear with me on this.



Is there anything else which may be done to fix that issue? Is someone 
already working on some of those? (I mean those reasonable from the list)?


Thanks!
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to better parallelize GHC build.

[Karel Gardas]

On 03/ 7/15 12:09 PM, Herbert Valerio Riedel wrote:

On 2015-03-07 at 11:49:53 +0100, Karel Gardas wrote:

[...]


Is there anything else which may be done to fix that issue? Is someone
already working on some of those? (I mean those reasonable from the
list)?


are you aware of

   https://ghc.haskell.org/trac/ghc/wiki/Building/Shake

and

   https://github.com/snowleopard/shaking-up-ghc
?


I am. Is this agreed way among the GHC developers? I was not sure so I 
mentioned shake just lightly...


Thanks,
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: freebsd-amd64-head (FreeBSD/amd64 HEAD (Gabor Pali)), build 556, Success

[Karel Gardas]

Hi,

due to recent switch to full testsuite run, our buildbots now provides a 
lot of output due to much more failing testcases. The case with FreeBSD 
buildbots even got so far, that server can't handle amount of data and 
leaks some binary trash to the log. I would really be curious if this is 
a leak of runtime memory and so it shows serious bug somewhere in GHC 
rts or what is it exactly... If you are curious investigate output 
attached to the last night freebsd buildots status emails.


Thanks,
Karel
PS: I'm assuming the builder infrastructure as run by Gabor on his 
server is still written in Haskell and compiled by GHC...


On 03/ 4/15 04:49 AM, Builder wrote:

freebsd-amd64-head (FreeBSD/amd64 HEAD (Gabor Pali)), build 556

Build succeeded
Details: http://haskell.inf.elte.hu/builders/freebsd-amd64-head/556.html

git clone| Success
create mk/build.mk   | Success
get subrepos | Success
repo versions| Success
touching clean-check files   | Success
setting version date | Success
booting  | Success
configuring  | Success
creating check-remove-before | Success
compiling| Success
creating check-remove-after  | Success
compiling testremove | Success
simulating clean | Success
checking clean   | Success
making bindist   | Success
making srcdist   | Success
uploading bindist| Success
uploading srcdist| Success
uploading tarball source | Success
testing bindist  | Success
testing  | Success
testsuite summary| Success

Build succeeded
Details: http://haskell.inf.elte.hu/builders/freebsd-amd64-head/556.html




___
ghc-builds mailing list
ghc-bui...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-builds


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

SPARC NCG, how to debug load isn issue.

[Karel Gardas]

Folks,

from time to time I'm attempting to resurrect SPARC NCG. It looks like 
it's off by default since 7.4? release and I feel it's kind of pity. 
I've been able to hack it on 7.6.x and make it functional. I failed on 
7.8 and later. Double float load was broken there.


Now, I'm attempting on fairly recent GHC HEAD as of Jan 17 and I do have 
problem with illegal isn generated into the binary. This is caused by LD 
II64 ... Instr to be translated to SPARC ldd addr,g1 where g1 reg is 
not even, but odd and this fails as spec. says:



The load doubleword integer instructions (LDD, LDDA) move a doubleword
from memory into an r register pair. The more significant word at the
effective memory address is moved into the even r register. The less
significant word (at the effective memory address + 4) is moved into the 
following

odd r register. (Note that a load doubleword with rd = 0 modifies
only r[1].) The least significant bit of the rd field is unused and 
should be set

to zero by software. An attempt to execute a load doubleword instruction
that refers to a mis-aligned (odd) destination register number may cause an
illegal_instruction trap.


I've found out that the problematic source code is HeapStackCheck.cmm 
and the problematic piece is:


if (Capability_context_switch(MyCapability()) != 0 :: CInt ||
Capability_interrupt(MyCapability())  != 0 :: CInt ||
(StgTSO_alloc_limit(CurrentTSO) `lt` (0::I64) 
 (TO_W_(StgTSO_flags(CurrentTSO))  TSO_ALLOC_LIMIT) != 
0)) {

ret = ThreadYielding;
goto sched;


This (0::I64) causes it. So that's the problem description. Now I'm 
attempting to debug it a little bit to find out where the LD II64 Instr 
is generated and I'm not able to find single place which would looks 
familiar with asm I get here:


.Lcq:
ld  [%i1+812],%g1
ldd [%g1+64],%g1
cmp %g1,0
bge .Lcs
nop
b   .Lcr
nop



more importantly when I look into sparc's version on mkLoadInstr, I 
don't see any way how it may generate LD II64:


sparc_mkLoadInstr dflags reg _ slot
  = let platform = targetPlatform dflags
off  = spillSlotToOffset dflags slot
off_w   = 1 + (off `div` 4)
sz  = case targetClassOfReg platform reg of
RcInteger - II32
RcFloat   - FF32
RcDouble  - FF64
_ - panic sparc_mkLoadInstr

in LD sz (fpRel (- off_w)) reg


In whole SPARC NCG I've found the only place which clearly uses LD II64 
and this is in Gen32.hs for loading literal float into reg:


getRegister (CmmLit (CmmFloat d W64)) = do
lbl - getNewLabelNat
tmp - getNewRegNat II32
let code dst = toOL [
LDATA ReadOnlyData $ Statics lbl
 [CmmStaticLit (CmmFloat d W64)],
SETHI (HI (ImmCLbl lbl)) tmp,
LD II64 (AddrRegImm tmp (LO (ImmCLbl lbl))) dst]
return (Any FF64 code)


It's interesting but also iselExpr64 which should be probably here for 
manipulating 64bit data on 32bit platform, so even this is using pairs 
of LD II32 Instrs instead of single LD II64


So I'm kind of out of idea where the LD II64 gets in the flow and is 
later translated into ldd with problematic reg.


Do you have any idea how to debug this issue? Or do you have any idea 
where to read more about general structure of NCG, I've already seen 
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/NCG 
-- but this is kind of dated...


Thanks for any idea how to proceed!
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

GHC HEAD failure [was: Re: [commit: ghc] master: Update Haddock submodule (34d68d8)]

[Karel Gardas]

Hello,

last night build on i386-freebsd, i386/amd64-solaris and smartos-x86 
failed with problem on configuring haddock:


inplace/bin/ghc-cabal check utils/haddock
'ghc-options: -O2' is rarely needed. Check that it is giving a real 
benefit and not just imposing longer compile times on your users.
inplace/bin/ghc-cabal configure utils/haddock dist  
--with-ghc=/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/inplace/bin/ghc-stage1 
--with-ghc-pkg=/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/inplace/bin/ghc-pkg 
--flag in-ghc-tree --disable-library-for-ghci --disable-library-vanilla 
--disable-library-profiling --disable-shared --configure-option=CFLAGS= 
-U__i686 -fno-stack-protector--configure-option=LDFLAGS=
--configure-option=CPPFLAGS=--gcc-options= -U__i686 
-fno-stack-protector
--configure-option=--with-gmp-includes=/usr/include/gmp 
--configure-option=--with-gmp-libraries=/usr/lib 
--with-gcc=/usr/bin/gcc --with-ld=/usr/bin/ld 
--configure-option=--with-cc=/usr/bin/gcc --with-ar=/usr/xpg4/bin/ar 
--with-alex=/buildbot//bin/alex --with-happy=/buildbot//bin/happy

Configuring haddock-2.16.0...
ghc-cabal: At least the following dependencies are missing:
ghc =7.9  7.11
gmake[1]: *** [utils/haddock/dist/package-data.mk] Error 1
gmake: *** [all] Error 2


At least i386-solaris is using ghc 7.8.2 as a bootsrap ghc and 
amd64-solaris is using ghc 7.10.0.20141222 as a bootstrap ghc. This is 
IIRC 7.10 rc1.


I've thought the general policy is to keep GHC buildable by two last 
release generation in the past and if this policy still applies then 
haddock is probably a culprit here. Perhaps it was done by the commit 
below which is the reason I address you directly Mateusz. If not, and 
the failure is caused by something else, then please excuse me for this 
email.


Thanks!
Karel

On 01/23/15 01:12 AM, g...@git.haskell.org wrote:

Repository : ssh://g...@git.haskell.org/ghc

On branch  : master
Link   : 
http://ghc.haskell.org/trac/ghc/changeset/34d68d8e83676c5010e9bc5d4619f24879f222af/ghc


---


commit 34d68d8e83676c5010e9bc5d4619f24879f222af
Author: Mateusz Kowalczykfuuze...@fuuzetsu.co.uk
Date:   Fri Jan 23 00:14:00 2015 +

 Update Haddock submodule



---


34d68d8e83676c5010e9bc5d4619f24879f222af
  utils/haddock | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/haddock b/utils/haddock
index d61bbc7..bf77580 16
--- a/utils/haddock
+++ b/utils/haddock
@@ -1 +1 @@
-Subproject commit d61bbc75890e4eb0ad508b9c2a27b91f691213e6
+Subproject commit bf77580eb40fa960b701296ac828372d127a43dd

___
ghc-commits mailing list
ghc-comm...@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-commits



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: integer-gmp2 issues on Solaris/SPARC

[Karel Gardas]

On 01/19/15 10:54 AM, Herbert Valerio Riedel wrote:

Is it possible for you to test for those mpn_ symbols in integrer-gmp2
configure and if they are presented then you can use your
__gmpn_andn_n foreigner call?


I'm actually rather considering not using those at all when GMP version
is 4.* as they're not part of the official API of GMP 4.x

Btw, how long do we need to keep supporting GMP 4.x (as it lacks a few
other features)?

GMP 5.0.0 has been released over 5 years ago... :-/


It depends on support policy. Speaking about RHEL 6.x and Solaris 11.x, 
both are supported till 2020 respectively till 2022. If however we 
support only newest version line of the OS, then RHEL 7.x is already in 
public (supporting gmp 5.x) but Solaris 12 not. Solaris 12 will probably 
be released sometimes in 2016 (following Oracle's SPARC/Solaris 
roadmap). My hope is, this will include gmp 5.x too. Are you ok waiting 
another year or two for transition?


Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: integer-gmp2 issues on Solaris/SPARC

[Karel Gardas]

On 01/18/15 04:05 PM, Herbert Valerio Riedel wrote:

On 2015-01-18 at 15:42:05 +0100, Karel Gardas wrote:

Hello Herbert,

I'm sorry to bother you, but recent GHC HEAD does have issue on
Solaris/SPARC platform which shows as undefined symbols during the
linkage of stage2 binaries. For example ghc-stage2 link step fails
with:


Btw, what GMP version is that exactly? GMP 3.5.2 doesn't seem to be an
official GMP release?


This is version 4.3.2 in both cases.


...does thegmp.h  header differ?


Unfortunately not. The only difference is in CFLAGS:

$ gdiff -u /usr/include/gmp/gmp.h /tmp/gmp.h
--- /usr/include/gmp/gmp.h  2014-02-05 14:40:13.405522327 +0100
+++ /tmp/gmp.h  2015-01-19 08:35:38.146637514 +0100
@@ -2231,7 +2231,7 @@

 /* Define CC and CFLAGS which were used to build this version of GMP */
 #define __GMP_CC /ws/on11update-tools/SUNWspro/sunstudio12.1/bin/cc
-#define __GMP_CFLAGS -m64 -xO4 -xchip=generic -Ui386 -U__i386 
-xregs=no%frameptr-mt -features=extinl,extensions 
-xustr=ascii_utf16_ushort -xcsi -xthreadvar=%all -D_STDC_99 -xc99=all 
-D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -KPIC -DPIC
+#define __GMP_CFLAGS -m64 -xO4  -xtarget=ultra2 -xarch=sparcvis 
-xchip=ultra2 -Qoption cg -xregs=no%appl -W2,-xwrap_int  -xmemalign=16s 
-mt -features=extinl,extensions -xustr=ascii_utf16_ushort -xcsi 
-xthreadvar=%all -D_STDC_99 -xc99=all -D_XOPEN_SOURCE=600 
-D__EXTENSIONS__=1 -D_XPG6 -KPIC -DPIC


 /* Major version number is the value of __GNU_MP__ too, above and in 
mp.h. */

 #define __GNU_MP_VERSION 4


Let me also add that the gmp.h file does not define mpn_andn_n symbol at 
all neither it declare __gmpn_andn_n function! Since both i386 and sparc 
gmp.h are the same this applies to both.



can you create a simple C program
that calls the mpn_andn operation and compare how linkage differs?


No, I'm not able to use mpn_andn nor mpn_andn_n. What I'm able to 
use is __gmpn_andn_n. On i386 this pass with implicitly declared 
symbol warning:


gmp_test.c: In function ‘main’:
gmp_test.c:10:5: warning: implicit declaration of function ‘__gmpn_andn_n’

on sparc fails on linkage:

$ gcc -Wall gmp_test.c -lgmp
gmp_test.c: In function ‘main’:
gmp_test.c:10:5: warning: implicit declaration of function ‘__gmpn_andn_n’
Undefined   first referenced
 symbol in file
__gmpn_andn_n   /var/tmp//ccSHaGtf.o
ld: fatal: symbol referencing errors. No output written to a.out
collect2: ld returned 1 exit status


My testing program is:

$ cat gmp_test.c

#include gmp/gmp.h

#include stdlib.h


int
main()
{
__gmpn_andn_n((mp_limb_t*)NULL, (const mp_limb_t*)NULL, (const 
mp_limb_t*)NULL, (mp_size_t)1);

return 0;
}


The big issue here is that i386/solaris gmp library so file provides 
this __gmpn_andn_n symbol but have not declared it in gmp.h at all in a 
form of mpn_andn_n define. So basically your:
-- void mpn_andn_n (mp_limb_t *rp, const mp_limb_t *s1p, const mp_limb_t 
*s2p,

--  mp_size_t n)
foreign import ccall unsafe gmp.h __gmpn_andn_n
  c_mpn_andn_n :: MutableByteArray# s - ByteArray# - ByteArray# - 
GmpSize#

  - IO ()


works on i386, but not on sparc.

Is it possible for you to test for those mpn_ symbols in integrer-gmp2 
configure and if they are presented then you can use your __gmpn_andn_n 
foreigner call?


Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

integer-gmp2 issues on Solaris/SPARC

[Karel Gardas]

Hello Herbert,

I'm sorry to bother you, but recent GHC HEAD does have issue on 
Solaris/SPARC platform which shows as undefined symbols during the 
linkage of stage2 binaries. For example ghc-stage2 link step fails with:


Undefined   first referenced
 symbol in file
__gmpn_andn_n 
/home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o)
__gmpn_and_n 
/home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o)
__gmpn_ior_n 
/home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o)
__gmpn_xor_n 
/home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o)
ld: fatal: symbol referencing errors. No output written to 
ghc/stage2/build/tmp/ghc-stage2



All binaries fail with the same set of unresolved symbols. I can tell 
you that I don't see this issue on Solaris/i386 nor on Solaris/amd64 
builds as you can verify here: http://haskell.inf.elte.hu/builders/


I'm talking here about exact Solaris 11.1 on SPARC and Solaris 11.1 on 
AMD64 box. Both Solarises provide the same version of libgmp:


$ uname -p
sparc
$ ls -la /usr/lib/libgmp.so*
lrwxrwxrwx   1 root root  15 Feb 20  1999 /usr/lib/libgmp.so 
- libgmp.so.3.5.2
lrwxrwxrwx   1 root root  15 Feb 20  1999 
/usr/lib/libgmp.so.3 - libgmp.so.3.5.2
-r-xr-xr-x   1 root bin  1093328 Sep 19  2012 
/usr/lib/libgmp.so.3.5.2

$


$ uname -p
i386
$ ls -la /usr/lib/libgmp.so*
lrwxrwxrwx   1 root root  15 Oct 18  2012 /usr/lib/libgmp.so 
- libgmp.so.3.5.2
lrwxrwxrwx   1 root root  15 Oct 18  2012 
/usr/lib/libgmp.so.3 - libgmp.so.3.5.2
-r-xr-xr-x   1 root bin   878276 Feb  5  2014 
/usr/lib/libgmp.so.3.5.2

$


And yet on i386/amd64 the symbol (one from the failing set as an 
example) __gmpn_andn_n is defined:


$ nm /usr/lib/libgmp.so|grep __gmpn_andn_n
[86]|375728|   101|FUNC |GLOB |0|14 |__gmpn_andn_n

but on SPARC it's not:

$ nm /usr/lib/libgmp.so|grep __gmpn_andn_n
$


Do you have any magical knob which I can switch on to work around this 
issue by not needing those four symbols above?


Thanks!
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Status and future of the LLVM backend

[Karel Gardas]

On 12/ 8/14 03:49 PM, Joachim Breitner wrote:

So what does that tell us? Maybe Peter can help us: Is it normal for a
Debian system to pretend that its a pre-v6 ARM, even if the actual
hardware is not?


Sorry to get into this, but are you using EABI[1] port of HardFloat[2] 
port? Wheezy claims to support[2], the release before this was[1].


I'm not sure what you use so I'm asking, anyway, if you use[1], then 
it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 
debian port in the past which was running happily on i686 but pretend to 
be i386 to be compatible with all the supported hardware...


Hope that helps,

Karel


[1]: https://wiki.debian.org/ArmEabiPort
[2]: https://wiki.debian.org/ArmHardFloatPort
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Status and future of the LLVM backend

[Karel Gardas]

On 12/ 8/14 04:44 PM, Joachim Breitner wrote:

Hi,


Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas:

On 12/ 8/14 03:49 PM, Joachim Breitner wrote:

So what does that tell us? Maybe Peter can help us: Is it normal for a
Debian system to pretend that its a pre-v6 ARM, even if the actual
hardware is not?


Sorry to get into this, but are you using EABI[1] port of HardFloat[2]
port? Wheezy claims to support[2], the release before this was[1].



I’m currently working on what Debian calls armel, so [1]. We’ll also
have to get it working on armhf (which seems to be [2]). Maybe things
are different there


Yes, but [2] is what Ubuntu is using and it was all right in the past at 
least modulo ghci/linker support which Ben was fixing.



I'm not sure what you use so I'm asking, anyway, if you use[1], then
it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386
debian port in the past which was running happily on i686 but pretend to
be i386 to be compatible with all the supported hardware...


Yes, that makes sense.

In that case, the use of the slow spinlock implementation is correct,
and GHC’s build system needs to be fixed to work in that situation,
right?


Yes, probably, I've not followed whole thread of discussion unfortunately.
BTW, IIRC this is configure/aclocal.m4 check what's the target ARM 
platrform capability, I'm a little bit surprised this is not working for 
you now. Also please make sure generated platform details are correct in 
settings file...


Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Cross-compiling GHC for ARM (RPi)

[Karel Gardas]

Two obvious questions:

1) have you installed your ncurses into your sysroot?

2) have you passed your sysroot to really all gcc invocations?

Your description looks like at least one answer to above question should 
be no.


For example I used custom bash script to solve (2), see [1].

Cheers,
Karel
[1]: 
https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/


On 12/ 1/14 12:43 AM, Xandaros wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm having some trouble cross-compiling GHC (or just making a
cross-compiler, which is what I am trying to do for now).

I got my toolchain through crosstool-ng. I just took the
arm-unknown-linux-gnueabi sample and disabled the render the toolchain
read-only option.

Unfortunately nt-ng does not come with ncurses, so I also compiled and
installed that. I set the prefix to
~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot,
where ~/x-tools/arm-unknown-linux-gnueabi is where my toolchain is located.

I copied the mk/build.mk.sample file to mk/build.mk and uncommented the
quick-cross option. I left everything else as-is.

After configuring I executed make, which runs for quite a while but
eventually it complains about not being able to find the curses headers.

What do I do to fix this? I wouldn't mind using a different toolchain if
I can get it to work, so I am open for anything.

Configure summary of ncurses and last lines of output of make:
http://hastebin.com/uwuwenucux.txt

I hope you can help me resolve this, I've been trying to do this for a
long time now :/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUe6uhAAoJEGBf7SEXmH6sIMkH/3eK500hnjjN3+hv/7P0YmY2
QVcDWJxRMgnFCyFA9oxAeJYqKeIps2H3555NSLdB19DK7QCG1x4TJpUBGCz09PfX
mH8ZN2qIirHIYUHOZa5JdE8cqvWd3hI1syr22PsxqyI4tkDuIfKsAp8IbJOd/vSX
9oqKjHe0OYHKIoUUlHST1AI2lElMby69nxBMprhU8yugIyEFSmQg+nuxG2Hq5GA4
SgOExWeuJHrxIAW0WZ8vipw7PG3IfJTzDSCMzIAPfri8TVhy2UNNVpjg4aaq//X0
TXXweFS1O/EpDSuRkU/2b5nGlxbaNObLI5eAJ0Lot7Pl5Oa1afK5l5ZWYipx+Fk=
=ol51
-END PGP SIGNATURE-

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload

[Karel Gardas]

On 11/24/14 01:50 PM, Herbert Valerio Riedel wrote:

On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote:

linker_unload:
/5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a:
unknown symbol `__gmpn_rshift'



Herbert, perhaps this is integer-gmp2 breakage?


...can't rule it out, but I haven't seen that failure anywhere else so
far (including http://haskell.inf.elte.hu/builders/) and can't reproduce
it myself either :-/


Have you tested RHEL 6.x? IIRC it is also using older GMP like 
Solaris... Also this is probably not tested on any builder...


Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload

[Karel Gardas]

On 11/25/14 08:18 AM, Herbert Valerio Riedel wrote:

Would it be possible to update your `sudo apt-get update`  `sudo
apt-get dist-upgrade` your Linux environment with the latest bugfixes to
Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already
fixed upstream...


I'm not sure, but IMHO this will lead to upgrade to 14.04.1. What you 
should use is probably

`sudo apt-get update`   `sudo apt-get upgrade`

Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

GHC HEAD breakage by pthread_setname_np usage.

[Karel Gardas]

Hello Simon,

I'm sorry to disturb you, but your recent patch:

commit 674c631ea111233daa929ef63500d75ba0db8858
Author: Simon Marlow marlo...@gmail.com
Date:   Fri Oct 10 14:26:19 2014 +0100

Name worker threads using pthread_setname_np

This helps identify threads in gdb particularly in processes with a
lot of threads.



breaks build on FreeBSD and Solaris at least. The problem is that 
pthread_setname_np is GNU extension and so far I've seen it just in 
linux using glibc =2.12, modern NetBSD and modern QNX. Builds on 
Solaris and FreeBSD result in unresolved symbol failure. Two examples 
showing this are here:


http://haskell.inf.elte.hu/builders/smartos-x86-head/147/10.html
http://haskell.inf.elte.hu/builders/freebsd-amd64-head/411/10.html

The problem is that I cannot simply #ifdef usage of this since it's 
using `name' parameter of the createOSThread function and if I #ifdef 
this, then the compiler emits obvious warning:


rts/posix/OSThreads.c: In function ‘createOSThread’:

rts/posix/OSThreads.c:132:40:  warning: unused parameter ‘name’


which is probably going to break validate build which builds with -Werror.

Perhaps if pthread_setname_np is not available on the target platform we 
can define it ourself (as empty macro or inline function doing nothing?) 
and use that, but in this case we would probably need proper configure 
check for the presence of this function.


As rts is your domain, I'm just writing this in a hope that you will 
either revert the patch for now or solve it in a way you like.


Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Broken build: 32-bit FreeBSD, SmartOS, Solaris

[Karel Gardas]

On 10/10/14 09:19 AM, Páli Gábor János wrote:

Hello there,

Looks one of the recent commits broke the x86 builds on multiple
platforms [1][2][3].  The common error message basically is as
follows:

rts/Linker.c: In function 'mkOc':
rts/Linker.c:2372:6:
  error: 'ObjectCode' has no member named 'symbol_extras'



It looks like this patch is the culprit:

5300099ed rts/Linker.c (Simon Marlow  2014-10-01 
13:15:05 +0100 2372)oc-symbol_extras = NULL;



Note that the x86_64 counterparts of the affected builders completed
their builds fine -- except for Solaris, but that has been broken
already for a long time (relatively).


Yeah, I'll need to fix that. So far I invested my energy in fixing 
Solaris/i386 testcase issues...


Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Broken build: 32-bit FreeBSD, SmartOS, Solaris

[Karel Gardas]

Indeed, but this looks like completely unrelated to the issue originally 
reported. Kind of libffi misdetection of target platform? i.e. why it 
compiles win32 related file on macosx?


Just trying to categorize not to decrease importance of this issue!

Karel

On 10/10/14 10:47 PM, Carter Schonwald wrote:

likewise, 32bit OS X seems to be broken on HEAD too

http://lpaste.net/112412 is the relevant bit

make[5]:  Nothing  to  be  done  for  `all'.
depbase=`echo  src/x86/win32.lo  |  sed  's|[^/]*$|.deps/|;s|\.lo$||'`;\
/bin/sh  ./libtool --mode=compile gcc-4.9 -DHAVE_CONFIG_H -I. -I..  -I. 
-I../include -Iinclude -I../src  -I. -I../include -Iinclude -I../src -U__i686 -m32 
-fno-stack-protector -w -MT src/x86/win32.lo -MMD -MP -MF $depbase.Tpo -c -o 
src/x86/win32.lo ../src/x86/win32.S\
mv  -f  $depbase.Tpo  $depbase.Plo
libtool:  compile:   gcc-4.9  -DHAVE_CONFIG_H  -I.  -I..  -I.  -I../include  
-Iinclude  -I../src  -I.  -I../include  -Iinclude  -I../src  -U__i686  -m32  
-fno-stack-protector  -w  -MT  src/x86/win32.lo  -MMD  -MP  -MF  
src/x86/.deps/win32.Tpo  -c  ../src/x86/win32.S   -fno-common  -DPIC  -o  
src/x86/.libs/win32.o
../src/x86/win32.S:1283:section  difference  relocatable  subtraction  expression,  
.LFE5  minus  .LFB5  using  a  symbol  at  the  end  of  section  will  not 
 produce  an  assembly  time  constant
../src/x86/win32.S:1283:use  a  symbol  with  a  constant  value  created  with 
 an  assignment  instead  of  the  expression,  L_const_sym  =  .LFE5  -  .LFB5
../src/x86/win32.S:1275:section  difference  relocatable  subtraction  expression,  
.LEFDE5  minus  .LASFDE5  using  a  symbol  at  the  end  of  section  will 
 not  produce  an  assembly  time  constant
../src/x86/win32.S:1275:use  a  symbol  with  a  constant  value  created  with 
 an  assignment  instead  of  the  expression,  L_const_sym  =  .LEFDE5  -  
.LASFDE5
../src/x86/win32.S:unknown:missing  indirect  symbols  for  section  
(__IMPORT,__jump_table)
make[5]:  ***  [src/x86/win32.lo]  Error  1


On Fri, Oct 10, 2014 at 9:40 AM, Páli Gábor János pali.ga...@gmail.com
mailto:pali.ga...@gmail.com wrote:

2014-10-10 13:30 GMT+02:00 cg chengan...@gmail.com
mailto:chengan...@gmail.com:
  How can I configure to build x86_64?

  When I build GHC (with msys2), it always builds i386 and I haven't
spotted
  the option in ./configure to choose a x86_64 release.

This is implicitly determined by the toolchain you use.  So, probably
you have the i686 msys2 installed, while you would need the x86_64
version.  Given, that your operating system (and thus your hardware)
is also x86_64.
___
ghc-devs mailing list
ghc-devs@haskell.org mailto:ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

tar --help is failing on Solaris.

[Karel Gardas]

Hello Mikhail,

you are the author of the patch eaf2aae18603965ff668384b391fcaa14de19823 
in libraries/Cabal which you have merged into GHC HEAD on September 25 
in the patch 4be50969491aa471d6c9ab3b9339036a355d45c6


The problem is that your patch breaks build on Solaris, here is the log 
from the Solaris/x86 builder:

http://haskell.inf.elte.hu/builders/solaris-x86-head/178/10.html

Could you be so kind and revert this patch or fix it to also work on 
Solaris? For Solaris the change should be easy, simply if you invoke 
Solaris' tar with --help, it'll fail with exit code 1 and help message 
printed into the stderr. If you are curious if it supports --format, 
then no.


Please let me know if you are able to push fix or revert during next 
week or if I shall deal with it myself. I can't just fix that now myself 
since I'm overloaded with other tasks till Wednesday night...


Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: tar --help is failing on Solaris.

[Karel Gardas]

Hi Mikhail,

On 09/27/14 09:09 PM, Mikhail Glushenkov wrote:

On 27 September 2014 20:19, Karel Gardaskarel.gar...@centrum.cz  wrote:


[...]
Could you be so kind and revert this patch or fix it to also work on
Solaris? For Solaris the change should be easy, simply if you invoke
Solaris' tar with --help, it'll fail with exit code 1 and help message
printed into the stderr. If you are curious if it supports --format, then
no.


Should be fixed now. Thanks for the heads-up!


Have you already pushed? I don't see it fixed on my end yet:


inplace/bin/ghc-cabal configure libraries/binary dist-boot  
--with-ghc=/opt/ghc-7.8.2/bin/ghc 
--with-ghc-pkg=/opt/ghc-7.8.2/bin/ghc-pkg 
--package-db=/export/home/karel/vcs/ghc-src/tar-test/libraries/bootstrapping.conf 
--disable-library-for-ghci --enable-library-vanilla 
--disable-library-profiling --disable-shared 
--with-hscolour=/export/home/karel/.cabal/bin/HsColour 
--configure-option=CFLAGS= -U__i686 -fno-stack-protector
--configure-option=LDFLAGS=--configure-option=CPPFLAGS=
--gcc-options= -U__i686 -fno-stack-protector
--configure-option=--with-gmp-includes=/usr/include/gmp/ 
--configure-option=--with-gmp-libraries=/usr/lib/   --constraint 
binary == 0.7.1.0   --constraint Cabal == 1.21.1.0   --constraint 
hpc == 0.6.0.2   --constraint bin-package-db == 0.0.0.0 
--constraint hoopl == 3.10.0.2   --constraint transformers == 
0.4.1.0   --constraint terminfo == 0.4.0.0 --with-gcc=/usr/bin//gcc 
--configure-option=--with-cc=/usr/bin//gcc 
--with-ar=/usr/xpg4/bin//ar 
--with-alex=/export/home/karel/.cabal/bin/alex 
--with-happy=/export/home/karel/.cabal/bin/happy

Configuring binary-0.7.1.0...
ghc-cabal: '/usr/bin/tar' exited with an error:
Usage: tar {c|r|t|u|x}[BDeEFhilmnopPTvw@/[0-7]][bf][X...] [j|z|Z] 
[blocksize]

[tarfile] [size] [exclude-file...] {file | -I include-file | -C directory
file}...
gmake[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1
gmake: *** [all] Error 2

and I've got whole new ghc tree for this test...

Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Status updates

[Karel Gardas]

  - Gabor has set up some build documentation for us based on HEAD,
hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix
haskell.org/ghc to link to this properly (there may be other dead
links, please let me know).


It’s a blank page for me.


Should probably be http://haskell.inf.elte.hu/builders/

Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

HEAD fails to bootstrap with HEAD?

[Karel Gardas]

Hello,

I've noticed that probably after cabal/ghc-pkg changes done recently 
HEAD fails to build with HEAD in following way:


[80 of 80] Compiling Main ( utils/ghc-cabal/Main.hs, 
bootstrapping/Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ...
touch utils/ghc-cabal/dist/build/tmp/ghc-cabal
cp utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal
inplace/bin/mkdirhier compiler/stage1/build//.
rm -f compiler/stage1/build/Config.hs
Creating compiler/stage1/build/Config.hs ...
done.
inplace/bin/ghc-cabal configure libraries/Cabal/Cabal dist-boot  
--with-ghc=/opt/ghc-7.9.20140906-amd64/bin/ghc 
--with-ghc-pkg=/opt/ghc-7.9.20140906-amd64/bin/ghc-pkg 
--package-db=/export/home/karel/vcs/ghc-src/head/libraries/bootstrapping.conf 
--disable-library-for-ghci --enable-library-vanilla 
--disable-library-profiling --disable-shared 
--with-hscolour=/export/home/karel/.cabal/bin/HsColour 
--configure-option=CFLAGS= -m64 -fno-stack-protector
--configure-option=LDFLAGS= -m64   --configure-option=CPPFLAGS= -m64 
  --gcc-options= -m64 -fno-stack-protector -m64   
--configure-option=--with-gmp-includes=/usr/include/gmp 
--configure-option=--with-gmp-libraries=/usr/lib/   --constraint 
Cabal == 1.21.1.0   --constraint hpc == 0.6.0.1   --constraint 
binary == 0.7.1.0   --constraint bin-package-db == 0.0.0.0 
--constraint hoopl == 3.10.0.1   --constraint transformers == 
0.4.1.0   --constraint terminfo == 0.4.0.0 --with-gcc=/usr/bin/gcc 
--configure-option=--with-cc=/usr/bin/gcc --with-ar=/usr/xpg4/bin/ar 
--with-alex=/export/home/karel/.cabal/bin/alex 
--with-happy=/export/home/karel/.cabal/bin/happy

Configuring Cabal-1.21.1.0...
ghc-cabal: '/opt/ghc-7.9.20140906-amd64/bin/ghc-pkg' exited with an error:
ghc-pkg: ghc no longer supports single-file style package databases
(/export/home/karel/vcs/ghc-src/head/libraries/bootstrapping.conf) use
'ghc-pkg init' to create the database with the correct format.
gmake[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1
gmake: *** [all] Error 2


I've been able to solve this by:

$ rm libraries/bootstrapping.conf
$ /opt/ghc-7.9.20140906-amd64/bin/ghc-pkg init libraries/bootstrapping.conf

however it's kind of impractical to do that on buildbot (solaris/amd64). 
Is it possible to fix that somehow?


Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: windows-x86-head (Windows/x86 HEAD (Gabor Pali)), build 2, Success

[Karel Gardas]

Gabor,

thanks a lot for your fantastic job on getting windows builder running. 
It's great to have that in the pool and not need to speculate if the 
change breaks windows build or not sometimes in the future when someone 
attempts to build that. Now it's one night turn over and this is great.


Thanks a lot!
Karel

On 08/23/14 07:33 AM, Builder wrote:

windows-x86-head (Windows/x86 HEAD (Gabor Pali)), build 2

Build succeeded
Details: http://haskell.inf.elte.hu/builders/windows-x86-head/2.html

git clone   | Success
create mk/build.mk  | Success
get subrepos| Success
repo versions   | Success
touching clean-check files  | Success
setting version date| Success
booting | Success
configuring | Success
creating check-remove-before| Success
compiling   | Success
creating check-remove-after | Success
compiling testremove| Success
simulating clean| Success
checking clean  | Success
making bindist  | Success
making srcdist  | Success
uploading bindist   | Success
uploading srcdist   | Success
uploading windows extra src tarball | Success
uploading tarball source| Success
testing bindist | Success
testing | Success
testsuite summary   | Success

Build succeeded
Details: http://haskell.inf.elte.hu/builders/windows-x86-head/2.html




___
ghc-builds mailing list
ghc-bui...@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-builds


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ARM64 Task Force

[Karel Gardas]

On 08/12/14 11:03 AM, Luke Iannini wrote:

It looks like it's jumping somewhere strange; lldb tells me it's to
0x100e05110: .long 0x ; unknown opcode
0x100e05114: .long 0x ; unknown opcode
0x100e05118: .long 0x ; unknown opcode
0x100e0511c: .long 0x ; unknown opcode
0x100e05120: .long 0x ; unknown opcode
0x100e05124: .long 0x ; unknown opcode
0x100e05128: .long 0x ; unknown opcode
0x100e0512c: .long 0x ; unknown opcode

If I put a breakpoint on StgRun and step by instruction, I seem to make
it to about:
https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e/rts/StgCRun.c#L770
(give or take a line)


strange that it's in the middle of the stp isns block. Anyway, this 
looks like a cpu exception doesn't it? You will need to find out the reg 
which holds the exception reason value and then look on it in your 
debugger to find out what's going wrong there.


Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: CPP usage in GHC.

[Karel Gardas]

Actually probably not debris leftover but needed code. I just removed -x 
assembler-with-cpp and got this:


gcc: ghc/Main.hs: linker input file unused because linking not done

so we definitely need some -x to set language even for GNU C. Tested 
also with old 3.4.x. From langs available, assembler-with-cpp looks like 
the best option unfortunately...


Karel

On 08/12/14 01:35 AM, Carter Schonwald wrote:

Oo.  Then it's possibly debris leftover from Austin's initial clang
compatibility work predating the improvements via the settings file work.

I'm Afk right now, but that probably can be safely removed from ghc,
especially since the configure script for clang cpp adds that anyways
now I think?  I might be wrong though.

On Monday, August 11, 2014, Karel Gardas karel.gar...@centrum.cz
mailto:karel.gar...@centrum.cz wrote:

On 08/11/14 11:18 PM, Carter Schonwald wrote:

why should this flag be passed to cpp when invoked on HS files?
It'd be
easy to expose another field in the settings file for this other
invokecation.. though i should look more closely at the use site
before
opinining :)


Hmm, isn't doCpp function what's invoked when cpp is invoked for HS
files? If so, then -x assembler-with-cpp is already used for HS
files anyway.

Karel



On Mon, Aug 11, 2014 at 4:27 PM, Karel Gardas
karel.gar...@centrum.cz
mailto:karel.gar...@centrum.cz wrote:

 On 08/11/14 08:48 PM, Carter Schonwald wrote:

 What i'm hearing you say is we actually need TWO sets
of CPP
 flags, one
 for normal haskell, and another for the CPP used on the
assembler?
 wheres this hardcoding?


 DriverPipeline.hs -- grep for assembler-with-cpp and you
will find it.

 IMHO best would be to move this -x assembler-with-cpp
into the
 hs-cpp-flags managed by configure. This way it may be even
possible
 to use system supplied plain cpp instead of cpp builtinto
GNU C.

 Karel





___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: CPP usage in GHC.

[Karel Gardas]

On 08/11/14 02:32 PM, Karel Gardas wrote:

Hmm, seeing CPPHS give me an idea about either

- prioritizing CPPHS usage, when configure detects CPPHS availability it
is then set as with --with-hs-cpp option and used as a preprocessor


 https://phabricator.haskell.org/D142 -- implements this option

Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: CPP usage in GHC.

[Karel Gardas]

On 08/11/14 11:18 PM, Carter Schonwald wrote:

why should this flag be passed to cpp when invoked on HS files? It'd be
easy to expose another field in the settings file for this other
invokecation.. though i should look more closely at the use site before
opinining :)


Hmm, isn't doCpp function what's invoked when cpp is invoked for HS 
files? If so, then -x assembler-with-cpp is already used for HS files 
anyway.


Karel




On Mon, Aug 11, 2014 at 4:27 PM, Karel Gardas karel.gar...@centrum.cz
mailto:karel.gar...@centrum.cz wrote:

On 08/11/14 08:48 PM, Carter Schonwald wrote:

What i'm hearing you say is we actually need TWO sets of CPP
flags, one
for normal haskell, and another for the CPP used on the assembler?
wheres this hardcoding?


DriverPipeline.hs -- grep for assembler-with-cpp and you will find it.

IMHO best would be to move this -x assembler-with-cpp into the
hs-cpp-flags managed by configure. This way it may be even possible
to use system supplied plain cpp instead of cpp builtinto GNU C.

Karel




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

CPP usage in GHC.

[Karel Gardas]

Folks,

in my attempt to lower number of failing tests on Solaris I've found 
several tests which fail on just difference in file name report. My ghc 
reports warning/error in /tmp/ghcsomething/some different thing 
while expected is clear Tsomething.hs.


See http://haskell.inf.elte.hu/builders/solaris-x86-head/125/21.html and 
search for T7145b as an example of this behavior.


The reason why this happen is that Solaris GNU C 4.x does not emit line 
markers in preprocessed file when it's preprocessed with -x 
assembler-with-cpp. The reason behind this is documented in this 
thread[1] on GCC mailing list. Simply speaking Sun's assembler in the 
past chokes on some linemarkers generated. This was apparently case of 
as on older Solaris then 10 version and perhaps this will be fixed in 
future major GCC release as Solaris 9 is not supported anymore. Anyway, 
we still do have a case with GNU C compilers provided by Solaris 10 and 
Solaris 11. FYI: Solaris' 10 GNU C 3.4.x is OK, Solaris 11's GNU C 4.5.2 
is broken and with this all more modern 4.x releases so probably also 
all 4.x release provided by Solaris 11.1/11.2.


So far I've solved the issue of those failing tests by passing 
--with-hs-cpp=/usr/sfw/bin/gcc -- so configured this way GHC will use 
old not-buggy GNU C 3.4.x on my Solaris 11 builder as CPP and otherwise 
it'll use /usr/bin/gcc (GNU C 4.5.2) and everything will pass fine 
hopefully.


Anyway, the thread[1] also contains a question which also rings in my 
head and that is: why we use -x assembler-with-cpp at all? Isn't simple 
-E enough. Or isn't simple usage of system provided CPP enough 
/usr/lib/cpp on Solaris)? Or what will happen if we for example change 
-x assembler-with-cpp to -x c or -x c-header or something like that? 
Please note that the testcase is OK with -x c/c-header even using this 
buggy GNU C 4.5.2 since the compiler/cpp is really buggy just for the 
case of -x assembler-with-cpp.


Thanks!
Karel

[1]: https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload validate related issue (how to duplicate that?).

[Karel Gardas]

Hi Edward,

thanks for dealing with this. I've found a little bit different reason. 
validate runs with ghc installed in bindisttest/install   dir/ and the 
tests invokes ghc-pkg to get gmp library path. The dir above is then 
returned quoted: ./install   dir/.
What I did in my linker_unload fix is to cut -d ' ' -f 1-1 IIRC which 
returned /install and nothing more (quotes missing). The shell then 
complains with the message below.


Anyway, this is already fixed by reverting the patch and I already 
validated and pushed another version of it which correctly use head -1 
to get the intended first directory name...


Hopefully this time I've not broken anything.

Thanks!
Karel

On 08/ 6/14 12:04 PM, Edward Z. Yang wrote:

Austin and I chatted about it, and it's probably because the test is not
creating ghcconfig.h early enough.  I haven't looked further on how to
fix it though.

Edward

Excerpts from Karel Gardas's message of 2014-08-06 10:16:20 +0100:


Folks,

I've noted that validate is failing on Linux recently due to issue in
linker_unload. As I've submitted some patch to this test case recently
which fixes this on Solaris I'm kind of curious if I broke it or not.
Anyway, strange thing is: when I configure ghc and run the test by
(g)make TEST=linker_unload on both Linux and Solaris I get no failure.
When I validate on Linux (validate is not working on Solaris yet), then
I get failure in linker_unload:

Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
/bin/sh: 1: Syntax error: Unterminated quoted string
make[3]: *** [linker_unload] Error 2

*** unexpected failure for linker_unload(normal)


when I try to run:

cd testsuite
make TEST=linker_unload

inside this validation tree I again get no failure in this test:

[...]
=  linker_unload(normal) 2522 of 4082 [0, 0, 0]
cd ./rts  $MAKE -s --no-print-directory linker_unload/dev/null
  linker_unload.run.stdout 2linker_unload.run.stderr

OVERALL SUMMARY for test run started at Wed Aug  6 10:55:17 2014 CEST
   0:00:08 spent to go through
  4082 total tests, which gave rise to
 13459 test cases, of which
 13458 were skipped

 0 had missing libraries
 1 expected passes
 0 expected failures

 0 caused framework failures
 0 unexpected passes
 0 unexpected failures

make[1]: Leaving directory `/home/karel/src/validate-test/testsuite/tests'

I've also noted that this test case fails on Solaris builders with
strange error:

=  linker_unload(normal) 170 of 4082 [0, 0, 1]
cd ./rts  $MAKE -s --no-print-directory linker_unload/dev/null
  linker_unload.run.stdout 2linker_unload.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:
Stderr:
linker_unload: internal error: loadObj: can't read
`/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/bindisttest/install/libHSinteg_BcPVjqcazPNGsNFG4agFty.a'
(GHC version 7.9.20140806 for i386_unknown_solaris2)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
gmake[3]: *** [linker_unload] Abort (core dumped)


So the question is: why validate fails and why builder fails on this
particular test and why my common testing on both Solaris and Linux is
not able to duplicate the issue? What's so different between validate
and builders and between my common: perl boot; ./configuresome
params; gmake -j12; cd testsuite; gmake THREADS=12 fast
?

Thanks!
Karel




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ARM64 Task Force

[Karel Gardas]

On 08/ 8/14 01:58 AM, Luke Iannini wrote:

I'm now studying David's patches to LLVM to learn how to add the
ARM64/GHC calling convention to LLVM.


Here is also original ARM/GHC calling convention submission. It's always 
good to have more examples as reference...


http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044173.html

Good luck with the ARM64/GHC porting work!

Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

linker_unload validate related issue (how to duplicate that?).

[Karel Gardas]

Folks,

I've noted that validate is failing on Linux recently due to issue in 
linker_unload. As I've submitted some patch to this test case recently 
which fixes this on Solaris I'm kind of curious if I broke it or not. 
Anyway, strange thing is: when I configure ghc and run the test by 
(g)make TEST=linker_unload on both Linux and Solaris I get no failure. 
When I validate on Linux (validate is not working on Solaris yet), then 
I get failure in linker_unload:


Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
/bin/sh: 1: Syntax error: Unterminated quoted string
make[3]: *** [linker_unload] Error 2

*** unexpected failure for linker_unload(normal)


when I try to run:

cd testsuite
make TEST=linker_unload

inside this validation tree I again get no failure in this test:

[...]
= linker_unload(normal) 2522 of 4082 [0, 0, 0]
cd ./rts  $MAKE -s --no-print-directory linker_unload/dev/null 
linker_unload.run.stdout 2linker_unload.run.stderr


OVERALL SUMMARY for test run started at Wed Aug  6 10:55:17 2014 CEST
 0:00:08 spent to go through
4082 total tests, which gave rise to
   13459 test cases, of which
   13458 were skipped

   0 had missing libraries
   1 expected passes
   0 expected failures

   0 caused framework failures
   0 unexpected passes
   0 unexpected failures

make[1]: Leaving directory `/home/karel/src/validate-test/testsuite/tests'

I've also noted that this test case fails on Solaris builders with 
strange error:


= linker_unload(normal) 170 of 4082 [0, 0, 1]
cd ./rts  $MAKE -s --no-print-directory linker_unload /dev/null 
linker_unload.run.stdout 2linker_unload.run.stderr

Wrong exit code (expected 0 , actual 2 )
Stdout:
Stderr:
linker_unload: internal error: loadObj: can't read 
`/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/bindisttest/install/libHSinteg_BcPVjqcazPNGsNFG4agFty.a'

(GHC version 7.9.20140806 for i386_unknown_solaris2)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
gmake[3]: *** [linker_unload] Abort (core dumped)


So the question is: why validate fails and why builder fails on this 
particular test and why my common testing on both Solaris and Linux is 
not able to duplicate the issue? What's so different between validate 
and builders and between my common: perl boot; ./configure some 
params; gmake -j12; cd testsuite; gmake THREADS=12 fast

?

Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload validate related issue (how to duplicate that?).

[Karel Gardas]

Just for the record validate fails since it is using ghc installed into 
bindisttest/install   dir/ subdirectory. The spaces here are really 
nasty test as my fix to linker_unload has not counted with the 
possibility of having ghc installed in such location (cut -d ' ' ... 
does bad thing in this case). So yes, that was me who broke validate but 
this should be already fixed by revert of problematic patch.


Sorry for that,
Karel

On 08/ 6/14 11:16 AM, Karel Gardas wrote:

So the question is: why validate fails and why builder fails on this
particular test and why my common testing on both Solaris and Linux is
not able to duplicate the issue? What's so different between validate
and builders and between my common: perl boot; ./configure some
params; gmake -j12; cd testsuite; gmake THREADS=12 fast
?

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: phabricator issue with git submodules.

[Karel Gardas]

Hello Edward,

I've done that, see https://phabricator.haskell.org/D96 -- but now I'm 
curious but since this is done in this way, basically speaking 
library/unix + libraries/primitive now points to commits done in my 
forks of those libs on github.com waiting for approval since I already 
pushed appropriate pull requests. Now this also means that D96 is 
probably not includable in GHC HEAD since it points to currently 
non-existing patches (in public libraries/unix + primitive). Am I right 
that this works in this way?


Thanks,
Karel

On 07/26/14 09:39 PM, Edward Z. Yang wrote:

Hello Karel,

When your submodules get updated, you need to add them to your commit
(since the parent repository maintains pointers to the submodules).
Then they will no longer show up as dirty and you can submit the
Phabricator patch.

Edward

Excerpts from Karel Gardas's message of 2014-07-25 22:48:21 +0100:


Hi,

just fixing few warning issues on Solaris/x86. The changes spread over
main ghc tree and libraries/primitive and libraries/unix. I already
commited changes and pushed to my github.com's forks of
libraries/primitive and libraries/unix. The git status looks then:

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use git push to publish your local commits)

Changes not staged for commit:
(use git addfile... to update what will be committed)
(use git checkout --file... to discard changes in working directory)

  modified:   libraries/primitive (new commits)
  modified:   libraries/unix (new commits)

no changes added to commit (use git add and/or git commit -a)


and yet phabricator still complains about it:

$ arc diff
You have unstaged changes in this working copy.

Working copy: /export/home/karel/vcs/ghc-src/validate-fixes/

Unstaged changes in working copy:
  libraries/primitive
  libraries/unix


  Do you want to amend these files to the commit? [y/N]

Usage Exception: Stage and commit (or revert) them before proceeding.

I pressed enter in question above.

Is that a known issue or am I doing something wrong here?

Thanks!
Karel




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Fatal git error on .git/modules/libffi-tarballs

[Karel Gardas]

Hello,

while working on HEAD and after a few iteraction of ./validate my git 
complains with:


$ git status
fatal: Not a git repository: 
/export/home/karel/vcs/ghc-src/ghc-git-test-2/.git/modules/libffi-tarballs

karel@silence:~/vcs/ghc-src/ghc-solaris-validate-fix$

Is this a known error or is there any known workaround for this issue?

Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

HEAD build fails on compiling haddoc

[Karel Gardas]

Hello,

I'm trying to compile HEAD on amd64-solaris2 platform, but the build 
fails with:


inplace/bin/ghc-stage2 -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc -fPIC 
-dynamic  -H32m -O-hide-all-packages -i -iutils/haddock/driver 
-iutils/haddock/src 
-iutils/haddock/haddock-library/vendor/attoparsec-0.10.4.0 
-iutils/haddock/haddock-library/src -iutils/haddock/dist/build 
-iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build 
-Iutils/haddock/dist/build/autogen-optP-DIN_GHC_TREE -optP-include 
-optPutils/haddock/dist/build/autogen/cabal_macros.h -package 
Cabal-1.20.0.1 -package array-0.5.0.0 -package base-4.7.1.0 -package 
bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 
-package directory-1.2.1.0 -package filepath-1.3.0.2 -package 
ghc-7.9.20140715 -package xhtml-3000.2.1 -funbox-strict-fields -Wall 
-fwarn-tabs -O2 -XHaskell2010  -no-user-package-db -rtsopts  -odir 
utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir 
utils/haddock/dist/build   -c utils/haddock/src/Haddock/GhcUtils.hs -o 
utils/haddock/dist/build/Haddock/GhcUtils.dyn_o


utils/haddock/src/Haddock/GhcUtils.hs:105:21:
Not in scope: data constructor ‘TyFamInstEqn’
Perhaps you meant ‘TyFamInstD’ (imported from GHC)

utils/haddock/src/Haddock/GhcUtils.hs:105:36:
‘tfie_rhs’ is not a (visible) constructor field name
gmake[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 1
gmake: *** [all] Error 2


is this just issue on my system or general issue which waits for someone 
to resolve it?


Since I built HEAD successfully just two days ago, this patch may looks 
suspiciously:


commit 9b8ba62991ae22420a0c4486127a3b22ee7f22bd
Author: Simon Peyton Jones simo...@microsoft.com
Date:   Tue Jul 15 07:43:55 2014 +0100

Entirely re-jig the handling of default type-family instances 
(fixes Trac #9063)


In looking at Trac #9063 I decided to re-design the default
instances for associated type synonyms.  Previously it was all
jolly complicated, to support generality that no one wanted, and
was arguably undesirable.

Specifically

* The default instance for an associated type can have only
  type variables on the LHS.  (Not type patterns.)

* There can be at most one default instances declaration for
  each associated type.

To achieve this I had to do a surprisingly large amount of refactoring
of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type
of the LHS patterns.

That change in HsDecls has a (trivial) knock-on effect in Haddock, so
this commit does a submodule update too.

The net result is good though.  The code is simpler; the language
specification is simpler.  Happy days.

Trac #9263 and #9264 are thereby fixed as well.


but I'm not expert so no offense! And if this is a mistake on my side, 
then I'm really sorry for false alarm.


Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: HEAD build fails on compiling haddoc

[Karel Gardas]

Yes, I did both `get' and `pull' as it was really (months) old repo. 
Anyway, let's see if builders catch this over night. If not, it was just 
my poor error for which I apologize.


Thanks,
Karel

On 07/15/14 02:28 PM, Simon Peyton Jones wrote:

I pushed a change to Haddock, and a change to GHC.  They should match up.  Did 
you do ./sync-all pull?

I may have screwed up.  I sent a long message to ghc-devs this morning 
explaining what I did.  Maybe some guru can help.

Simon

| -Original Message-
| From: Karel Gardas [mailto:karel.gar...@centrum.cz]
| Sent: 15 July 2014 13:19
| To: ghc-devs; Simon Peyton Jones
| Subject: HEAD build fails on compiling haddoc
|
|
| Hello,
|
| I'm trying to compile HEAD on amd64-solaris2 platform, but the build
| fails with:
|
| inplace/bin/ghc-stage2 -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc -fPIC
| -dynamic  -H32m -O-hide-all-packages -i -iutils/haddock/driver
| -iutils/haddock/src
| -iutils/haddock/haddock-library/vendor/attoparsec-0.10.4.0
| -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -
| iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build
| -Iutils/haddock/dist/build/autogen-optP-DIN_GHC_TREE -optP-include
| -optPutils/haddock/dist/build/autogen/cabal_macros.h -package
| Cabal-1.20.0.1 -package array-0.5.0.0 -package base-4.7.1.0 -package
| bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-
| 1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package
| ghc-7.9.20140715 -package xhtml-3000.2.1 -funbox-strict-fields -Wall
| -fwarn-tabs -O2 -XHaskell2010  -no-user-package-db -rtsopts  -odir
| utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir
| utils/haddock/dist/build   -c utils/haddock/src/Haddock/GhcUtils.hs -o
| utils/haddock/dist/build/Haddock/GhcUtils.dyn_o
|
| utils/haddock/src/Haddock/GhcUtils.hs:105:21:
|  Not in scope: data constructor 'TyFamInstEqn'
|  Perhaps you meant 'TyFamInstD' (imported from GHC)
|
| utils/haddock/src/Haddock/GhcUtils.hs:105:36:
|  'tfie_rhs' is not a (visible) constructor field name
| gmake[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 1
| gmake: *** [all] Error 2
|
|
| is this just issue on my system or general issue which waits for
| someone to resolve it?
|
| Since I built HEAD successfully just two days ago, this patch may looks
| suspiciously:
|
| commit 9b8ba62991ae22420a0c4486127a3b22ee7f22bd
| Author: Simon Peyton Jonessimo...@microsoft.com
| Date:   Tue Jul 15 07:43:55 2014 +0100
|
|  Entirely re-jig the handling of default type-family instances
| (fixes Trac #9063)
|
|  In looking at Trac #9063 I decided to re-design the default
|  instances for associated type synonyms.  Previously it was all
|  jolly complicated, to support generality that no one wanted, and
|  was arguably undesirable.
|
|  Specifically
|
|  * The default instance for an associated type can have only
|type variables on the LHS.  (Not type patterns.)
|
|  * There can be at most one default instances declaration for
|each associated type.
|
|  To achieve this I had to do a surprisingly large amount of
| refactoring
|  of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the
| type
|  of the LHS patterns.
|
|  That change in HsDecls has a (trivial) knock-on effect in Haddock,
| so
|  this commit does a submodule update too.
|
|  The net result is good though.  The code is simpler; the language
|  specification is simpler.  Happy days.
|
|  Trac #9263 and #9264 are thereby fixed as well.
|
|
| but I'm not expert so no offense! And if this is a mistake on my side,
| then I'm really sorry for false alarm.
|
| Thanks!
| Karel



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Huge space leak of GHC API 7.8.x?

[Karel Gardas]

On 07/14/14 09:00 AM, Kazu Yamamoto (山本和彦) wrote:

 Mac (64bit)  Linux (64bit)
GHC 7.6.3: 20MB4MB
GHC 7.8.3:106MB   13MB


On Solaris 11 i386 (32bit binary) I see:

GHC 7.8.2: 91MB (size), 81MB (RSS)
GHC 7.6.3  53MB (size), 44MB (RSS)

Cheers,
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 64bit Solaris was: Re: 7.8.1 plan

[Karel Gardas]

On 07/14/14 02:53 PM, Christian Maeder wrote:

Hi Karel,

usually I do not build HEAD. My attempt starting to do so failed as
follows:

git clone git://git.haskell.org/ghc.git
cd ghc
./sync-all get
autoreconf


^ I'm not sure, but shouldn't that be `perl boot' ?


./configure


^ if you don't have x86_64-solaris ghc yet on your system, you will 
probably need to cross-compile with --target= param.



Is there somewhere a x86_64-solaris2 binary-dist (for Solaris 10) to try
out first?


I haven't tried that yet as my primary target is Solaris 11.

Karel


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Two days old build breakage on i386.

[Karel Gardas]

Hello,

builders running on i386 building for this platform caught issue which 
shows as a build breakage:


ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140624 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1Q6
assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 
0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]

freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** 
[libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed


Have a look for example on linux-i386 buildot log here: 
http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html


Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so 
it's OS independent and probably 32bit/i386 platform specific and it's 
two days old breakage now. The last two night builds fail on all 
mentioned buildbots. I'm not sure but perhaps:


commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
Author: Johan Tibell johan.tib...@gmail.com
Date:   Mon Jun 9 11:43:21 2014 +0200

triggers that issue? I'm not claiming that the commit is actual culprit, 
this may be just recently un-hidden issue in linear regs allocator on i386!


Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Two days old build breakage on i386.

[Karel Gardas]

On 06/26/14 12:37 PM, Johan Tibell wrote:

I think it's reasonable to say my change triggers the issue, but I don't
know why and I need someone who understand the register allocator better
(e.g. Simon M) to at least give me some pointers on how to debug this.
If this is causing more trouble than build bot breakages (which is bad
enough), let me know and I'll either revert temporarily and or try to
work around the issue.


it does not hurt me as long as it does not go to 7.10 release so it's 
enough time to fix that. So feel free not to revert your patch 
especially if you do have some time to look into real culprit in regs alloc.



Also, how do I repro this if I don't have a x86 machine lying around?
Have people been successful working on these kind of issues in a VM?


My simplest way is to install VirtualBox and inside it i386-ubuntu, give 
it 2 GB RAM, 15GB drive and this should get you going really quickly. 
Then you will need to:


sudo apt-get install gcc ghc make git (in ubuntu)

which should be enough and then just follow ghc's wiki to obtain source 
tree and bootstrap on linux...


Roughly it should be that IMHO. If not, I may do that myself and send 
you exact stepts to follow...


Thanks!
Karel




On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas karel.gar...@centrum.cz
mailto:karel.gar...@centrum.cz wrote:


Hello,

builders running on i386 building for this platform caught issue
which shows as a build breakage:

ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140624 for i386-unknown-linux):
RegAllocLinear.__allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1Q6
assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861
Please report this as a GHC bug:
http://www.haskell.org/ghc/__reportabug
http://www.haskell.org/ghc/reportabug
make[1]: ***
[libraries/ghc-prim/dist-__install/build/GHC/__PrimopWrappers.o] Error 1
libraries/ghc-prim/ghc.mk:4 http://ghc.mk:4: recipe for target
'libraries/ghc-prim/dist-__install/build/GHC/__PrimopWrappers.o' failed

Have a look for example on linux-i386 buildot log here:
http://haskell.inf.elte.hu/__builders/validator1-linux-x86-__head/18/7.html
http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html

Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386
so it's OS independent and probably 32bit/i386 platform specific and
it's two days old breakage now. The last two night builds fail on
all mentioned buildbots. I'm not sure but perhaps:

commit d8abf85f8ca176854e9d5d0b12371c__4bc402aac3
Author: Johan Tibell johan.tib...@gmail.com
mailto:johan.tib...@gmail.com
Date:   Mon Jun 9 11:43:21 2014 +0200

triggers that issue? I'm not claiming that the commit is actual
culprit, this may be just recently un-hidden issue in linear regs
allocator on i386!

Thanks!
Karel




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Revert Per-thread allocation counters and limits (f0fcc41)

[Karel Gardas]

Hello Simon,

I'm sorry to disturb you, but I've noticed that your revert patch below 
contains this change:


diff --git a/includes/CodeGen.Platform.hs b/includes/CodeGen.Platform.hs
index f3abb3d..3d6dd41 100644
--- a/includes/CodeGen.Platform.hs
+++ b/includes/CodeGen.Platform.hs
@@ -741,8 +741,10 @@ globalRegMaybe CurrentTSO   = Just 
(RealRegSingle REG_CurrentTSO)

 # ifdef REG_CurrentNursery
 globalRegMaybe CurrentNursery   = Just (RealRegSingle 
REG_CurrentNursery)

 # endif
-#endif
 globalRegMaybe _= Nothing
+#else
+globalRegMaybe = panic globalRegMaybe not defined for this platform
+#endif


and I'm not sure if this is intentional or just overlooked addition. The 
problem with this line is that it causes stage1 panic on unregisterised 
build on PPC64 platform:


http://haskell.inf.elte.hu/builders/linux-ppc64-head/41/10.html

and we have not had such panic before the patch:

http://haskell.inf.elte.hu/builders/linux-ppc64-head/31/10.html -- well, 
you see that dll-split segfaults, but at least ghc-stage1 is proved to 
work well here.


Kudos to Gabor Pali who spotted this on PPC64 builder...

Thanks!
Karel

On 05/ 4/14 11:45 PM, g...@git.haskell.org wrote:

Repository : ssh://g...@git.haskell.org/ghc

On branch  : master
Link   : 
http://ghc.haskell.org/trac/ghc/changeset/f0fcc41d755876a1b02d1c7c79f57515059f6417/ghc


---


commit f0fcc41d755876a1b02d1c7c79f57515059f6417
Author: Simon Marlowmarlo...@gmail.com
Date:   Sun May 4 20:27:42 2014 +0100

 Revert Per-thread allocation counters and limits

 Problems were found on 32-bit platforms, I'll commit again when I have a 
fix.

 This reverts the following commits:
54b31f744848da872c7c6366dea840748e01b5cf
b0534f78a73f972e279eed4447a5687bd6a8308e



---


f0fcc41d755876a1b02d1c7c79f57515059f6417
  compiler/cmm/CmmLayoutStack.hs |   9 +-
  compiler/codeGen/StgCmmForeign.hs  | 268 ++---
  includes/CodeGen.Platform.hs   |   4 +-
  includes/rts/Constants.h   |   6 -
  includes/rts/Flags.h   |   8 -
  includes/rts/Threads.h |   8 +-
  includes/rts/storage/TSO.h |  31 +--
  libraries/base/Control/Exception.hs|   1 -
  libraries/base/Control/Exception/Base.hs   |   1 -
  libraries/base/GHC/Conc.lhs|   6 -
  libraries/base/GHC/Conc/Sync.lhs   |  92 +--
  libraries/base/GHC/IO/Exception.hs |  21 +-
  rts/HeapStackCheck.cmm |   4 +-
  rts/Linker.c   |   4 -
  rts/Prelude.h  |   2 -
  rts/RaiseAsync.c   |  54 -
  rts/RaiseAsync.h   |   4 -
  rts/RtsFlags.c |  10 -
  rts/RtsStartup.c   |   1 -
  rts/Schedule.c |  19 --
  rts/Threads.c  |  77 +++---
  rts/package.conf.in|   2 -
  rts/sm/Storage.c   |   6 -
  rts/win32/libHSbase.def|   1 -
  testsuite/tests/concurrent/should_run/all.T|   7 -
  .../tests/concurrent/should_run/allocLimit1.hs |   9 -
  .../tests/concurrent/should_run/allocLimit1.stderr |   1 -
  .../tests/concurrent/should_run/allocLimit2.hs |  17 --
  .../tests/concurrent/should_run/allocLimit3.hs |  15 --
  .../tests/concurrent/should_run/allocLimit3.stderr |   1 -
  .../tests/concurrent/should_run/allocLimit3.stdout |   1 -
  .../tests/concurrent/should_run/allocLimit4.hs |  31 ---
  utils/deriveConstants/DeriveConstants.hs   |   1 -
  33 files changed, 144 insertions(+), 578 deletions(-)

Diff suppressed because of size. To see it, use:

 git diff-tree --root --patch-with-stat --no-color --find-copies-harder 
--ignore-space-at-eol --cc f0fcc41d755876a1b02d1c7c79f57515059f6417
___
ghc-commits mailing list
ghc-comm...@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-commits



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Revert Per-thread allocation counters and limits (f0fcc41)

[Karel Gardas]

On 05/13/14 10:06 AM, Peter Trommler wrote:

Hi Karel,

This issue is ticket #9055, which also contains a patch. Could we please merge 
it?


I'm the second petitioner for the merge of your fix! Thanks a lot for 
pointing this out and providing the patch!


Cheers,
Karel
___
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)

[Karel Gardas]

On 05/ 3/14 08:35 AM, Herbert Valerio Riedel wrote:

On 2014-05-03 at 08:31:47 +0200, Mateusz Kowalczyk wrote:

[...]


I just tried to compile a snapshot involving this commit and got a
compile failure:

http://lpaste.net/103540

I was compiling with GHC 7.8.2 on a 32-bit machine.


The nightly 32bit GHC HEAD PPA build failed as well, see

  
https://launchpadlibrarian.net/174440396/buildlog_ubuntu-precise-i386.ghc-head_7.9.20140502-1_FAILEDTOBUILD.txt.gz


All builders (solaris/freebsd/smartos) fail too. Example:

http://haskell.inf.elte.hu/builders/solaris-x86-head/47/10.html

build a day ago was ok: 
http://haskell.inf.elte.hu/builders/solaris-x86-head/46.html


Thanks,
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

checking clean reporting a lot of non-deleted files.

[Karel Gardas]

Hello Herbert,

I hope you are the right person to ask, but it looks like after folding 
base/template-haskell/ghc-prim/integer-gmp/ etc. libraries to ghc tree 
the build's checking clean step reports a lot of non-deleted files. This 
makes our builder logs quite huge:


http://haskell.inf.elte.hu/builders/solaris-x86-head/36/14.html

the situation just few days ago was quite different:

http://haskell.inf.elte.hu/builders/solaris-x86-head/33/14.html

Do you think this is caused by your change? If not, do you have an idea 
what's going wrong here?


Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

strip related failure [was: Re: solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32, Failure]

[Karel Gardas]

Folks,

last two/three builds on Solaris builder fails due to a reason that 
someone added (probably) stripping of installed libraries. My bet is on 
8992d5269804b727fb77249511e89df678526907 -- hence ccing you Herbert, but 
I'm not sure...


The problem is that invoked strip command line is incompatible with 
Solaris' strip which then fails with:


strip: --strip-unneeded: cannot open file: No such file or directory

the problem is usage of --strip-unneeded command-line argument? It looks 
like this argument is supported by just GNU strip. Do we really need to 
use it? If not, removing this may solve the issue. If yes, then I'll 
need to come with some workaround for Solaris...


Detailed log of failure is at the bottom of 
http://haskell.inf.elte.hu/builders/solaris-x86-head/32/20.html


Thanks!
Karel

On 04/18/14 05:03 AM, Builder wrote:

solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32

Build failed
Details: http://haskell.inf.elte.hu/builders/solaris-x86-head/32.html

git clone| Success
create mk/build.mk   | Success
get subrepos | Success
repo versions| Success
touching clean-check files   | Success
setting version date | Success
booting  | Success
configuring  | Success
creating check-remove-before | Success
compiling| Success
creating check-remove-after  | Success
compiling testremove | Success
simulating clean | Success
checking clean   | Success
making bindist   | Success
making srcdist   | Success
uploading bindist| Success
uploading srcdist| Success
uploading tarball source | Success
testing bindist  | Failure: Just (ExitFailure 2)

Build failed
Details: http://haskell.inf.elte.hu/builders/solaris-x86-head/32.html




___
ghc-builds mailing list
ghc-bui...@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-builds


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: strip related failure [

[Karel Gardas]

Fantastic! This was less then minute for a fix after issue was created!

Thanks a lot!
Karel

On 04/18/14 12:26 PM, Johan Tibell wrote:

On Fri, Apr 18, 2014 at 12:20 PM, Herbert Valerio Riedel
hvrie...@gmail.com mailto:hvrie...@gmail.com wrote:

This sounds as if you'd want to file an issue and/or pull-request ASAP
for Cabal 1.20 before it gets released;


Just fixed this on the 1.20 branch:
https://github.com/haskell/cabal/commit/8af39a5f827dcf5b5ca68badc2955e4cccbb039d

-- Johan




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04

[Karel Gardas]

On 04/11/14 11:47 AM, kyra wrote:

Hi,

I have unpacked ghc-7.8.1-i386-unknown-linux-deb7.tar.xz to
~/data/Work/ghc-7.8.1-i386.

Now I have the following:

awson@awsonvirt:~/data/Work/ghc-7.8.1-i386$ ./configure
--prefix=/home/awson/data/ghc-7.8.1-i386
checking for path to top of build tree...
utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: line 3:
/home/awson/data/Work/ghc-7.8.1-i386/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd:
No such file or directory
configure: error: cannot determine current directory

ghc-pwd is definitely there but it does not start it seems. Perhaps, the
system lacks some shared libs or something.

There absolutely no problems with 64-bit ghc.


Yes, you get the error like that when you try to execute different ABI 
or unsuppored ABI binary. Do that with ARM binary on x86 and you will 
get the same error for example.


What you have forgotten is to install i386 libs on your purely amd64 
xubuntu probably...


Cheers,
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: 64bit Solaris was: Re: 7.8.1 plan

[Karel Gardas]

Hi,

thanks to an advice put by Alain (cced), I've grabbed the copy of 
SmartOS and installed GHC there. It looks like this package is AMD64 
based. I've then moved it to my Solaris 11.1 and it runs fine and 
compile the code well:


$ ghc --make HelloWorld.lhs
[1 of 1] Compiling Main ( HelloWorld.lhs, HelloWorld.o )
Linking HelloWorld ...
$ ./HelloWorld
Hello world!
$ file HelloWorld
HelloWorld: ELF 64-bit LSB executable AMD64 Version 1, dynamically 
linked, not stripped

$ ldd HelloWorld
libiconv.so.2 =  /opt/local/lib/libiconv.so.2
libgmp.so.10 =   /opt/local/lib/libgmp.so.10
libm.so.2 =  /lib/64/libm.so.2
librt.so.1 = /lib/64/librt.so.1
libdl.so.1 = /lib/64/libdl.so.1
libc.so.1 =  /lib/64/libc.so.1
libumem.so.1 =   /lib/64/libumem.so.1
	libgcc_s.so.1 =	 
/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libgcc_s.so.1



Well, so this is IMHO a easier way to bootstrap GHC HEAD on 
Solaris/AMD64. I currently do not have a time to deal with it, but 
hopefully will find some during the weekend -- well, if nobody is 
faster, otherwise I will devote my weekend ghc hobby time to SPARC NCG 
debugging. :-)


Cheers,
Karel

On 04/10/14 09:39 AM, Christian Maeder wrote:

Hi,

I've tried to cross-compile
https://ghc.haskell.org/trac/ghc/ticket/8910
but did not succeed, yet.

There seem to be problems with Int64 and/or Word data types.
The proper start would be to make a careful comparison of the test-suite
results, but there are already failures for the 32bit version (under
Solaris 10). Unfortunately I don't have time to look into it further.

Cheers Christian

Am 09.04.2014 16:49, schrieb Pavel Ryzhov:

Hi Karel,

That is great!

Do you know if there any plans for 64-bit build of GHC for Solaris 11?

Regards,
Pavel

On 09 Apr 2014, at 10:49, Karel Gardas karel.gar...@centrum.cz wrote:



Hi Pavel,

I've too built binary dist for Solaris 11 and Solaris 10. The
advantage of Solaris 11 build is that it supports shared libs and is
built using system provided gmp and ffi libs.

Solaris 2.10:
https://app.box.com/s/s1bysqga0x5f3itysu7g
https://app.box.com/s/fbfki0szetnp4pghpeuk

Solaris 2.11:
https://app.box.com/s/zstci63pt10t4yix74s8
https://app.box.com/s/9375dyx8hwu9cnox2lgi

The first link is binary tarball while the second is sha256.

Karel

On 04/ 9/14 07:31 AM, Pavel Ryzhov wrote:

Hi,

I made Solaris 11 x86 bindist. It seems to be working fine. I will try
to make IPS package later than.

https://s3-eu-west-1.amazonaws.com/ghc-paulrz/ghc-7.8.1-i386-unknown-solaris2.tar.bz2

sha256:
268b91eee42aa1f100062857416a4b69045bbb36fca9fafd6fb7adb8db8bc6b2

Regards,
Pavel Ryzhov

On 08 Apr 2014, at 21:39, Carter Schonwald carter.schonw...@gmail.com
mailto:carter.schonw...@gmail.com wrote:


ok, did a sha256 on my bindist
98ab924806a8af6ffde5365be64eb5fb826a38d3827ac31720cc89542f235592 for
https://s3.amazonaws.com/wellposed.com/opensource/ghc/releaseBuilds-unofficial/ghc-7.8.1-x86_64-apple-darwin.tar.bz2



On Tue, Apr 8, 2014 at 1:17 PM, Páli Gábor János pali.ga...@gmail.com
mailto:pali.ga...@gmail.com wrote:

2014-04-08 15:28 GMT+02:00 Austin Seipp aus...@well-typed.com
mailto:aus...@well-typed.com:
 Feel free to make builds - I'll add them as they come in and will
 announce soon...

The FreeBSD builds are now available, along with the respective SHA256
sums and the updated README file, as usual:

http://haskell.inf.elte.hu/ghc/ghc-7.8.1-i386-portbld-freebsd.tar.bz2
http://haskell.inf.elte.hu/ghc/ghc-7.8.1-x86_64-portbld-freebsd.tar.bz2

http://haskell.inf.elte.hu/ghc/SHA256SUMS
http://haskell.inf.elte.hu/ghc/README.html
___
ghc-devs mailing list
ghc-devs@haskell.org mailto:ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org mailto:ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs






___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs






___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Offering GHC builder build slaves

[Karel Gardas]

On 04/ 9/14 03:41 AM, Alain O'Dea wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-04-08 08:17 PM, Karel Gardas wrote:

On 04/ 8/14 03:16 PM, Alain O'Dea wrote:

The two build slaves I intend to run are: - x86_64 Solaris (on
SmartOS)


Please name it smartos-x86 then. I'm running real Solaris 11.1 as
a builder here so let's make it different name builder and see if
there are any incompatibilities between those two (I hope still
very close) platforms.

BTW: what's your platform triple detected by config.guess?

Thanks! Karel


Hi Karel,

My platform triple detected by config.guess is:
x86_64-unknown-solaris2

I got that by running `cat config.status | grep TargetPlatformFull`.


Hi Alain,

hmm, that's after GHC own platform processing is done, but what does

sh config.guess

tells you? E.g. on my two Solaris 11 I get:

$ sh config.guess
i386-pc-solaris2.11

$ sh config.guess
sparc-sun-solaris2.11

BTW: also if you are building GHC on AMD64/Solaris/err/SmartOS, then I 
think Christian (cced) may be interested as he is currently working on 
cross-compiling from i386/Solaris to AMD64/Solaris and he is hit by some 
bugs along the way. So if you do have already binary for GHC on that, 
then perhaps it'll work on Solaris too...


You may wonder why I'm so picky about Solaris, but I've just been hit on 
Solaris 10 by bugs (in linker) which are not presented on Solaris 11 so 
in the past I needed to switch off shared libs on Solaris 10 and keep 
this functionality on Solaris 11 so I'm curious what third member to 
Solaris family will bring here. I hope SmartOS is still more closer to 
Solaris 11 than Solaris 10 thanks to its roots in OpenSolaris project...


Thanks,
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs