git issues or repository issues?

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

Re: ghcup failed

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"

Ampere A1 instances for builder/marge?

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

Re: On CI

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

Re: [ANNOUNCE] GHC 9.0.1 released

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

Re: [ANNOUNCE] GHC 9.0.1 released

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!

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

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

Re: Old build system broken

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

Re: Compilation time

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

Re: GHC 8.2.1-rc2 source tarball availability

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

Re: Setting Up a OpenBSD System for Building GHC Wiki Page

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

Re: Setting Up a OpenBSD System for Building GHC Wiki Page

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

Re: Building head on Openbsd

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

Re: Building head on Openbsd

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

Re: Attempt at a real world benchmark

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

Re: Compiling on OpenBSD-current

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

Re: Status of Harbormaster

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,

Re: Solaris feature_tests.h

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

Re: GHC build currently broken on OS X and Windows

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

Re: CMM-to-ASM: Register allocation wierdness

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,

Re: 8.0.1 source tarballs available (yet again)

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

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

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 derive

Re: [ANNOUNCE] GHC 8.0.1 source tarball available

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

Re: Mentor for a JVM backend for GHC

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

Re: GHC 8.0.1-rc4 source tarball availability

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

Re: GHC build time graphs

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

Re: GHC build time graphs

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

Re: GHC build time graphs

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

Re: GHC build time graphs

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

Re: [ANNOUNCE] Shaking up GHC

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

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

/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

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

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

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

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

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

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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

derstand 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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

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,

Re: Flag warnings show intermediate hscpp filenames on SmartOS

/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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

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

Re: Cannot have GHC in ARMv6 architecture

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"

Re: Cannot have GHC in ARMv6 architecture

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

Re: Cannot have GHC in ARMv6 architecture

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.

Re: Cannot have GHC in ARMv6 architecture

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.

Re: Cannot have GHC in ARMv6 architecture

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

Re: Two step allocator for 64-bit systems

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

Re: GHC 7.10.2 plans

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

Re: New GHC performance dashboard

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

Re: Some test data

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

Re: RFC: Native -XCPP Proposal

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

Re: Phabricator as bug tracker system (off topic)

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

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

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

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3

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

HEAD not buildable by 7.10.1 RC3?

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

How to better parallelize GHC build.

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

Re: How to better parallelize GHC build.

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

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

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

SPARC NCG, how to debug load isn issue.

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

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

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

Re: integer-gmp2 issues on Solaris/SPARC

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

Re: integer-gmp2 issues on Solaris/SPARC

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

integer-gmp2 issues on Solaris/SPARC

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

Re: Status and future of the LLVM backend

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

Re: Status and future of the LLVM backend

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

Re: Cross-compiling GHC for ARM (RPi)

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,

Re: linker_unload

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

Re: linker_unload

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,

GHC HEAD breakage by pthread_setname_np usage.

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

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

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

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

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

tar --help is failing on Solaris.

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

Re: tar --help is failing on Solaris.

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

Re: Status updates

- 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

HEAD fails to bootstrap with HEAD?

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

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

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.

Re: ARM64 Task Force

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

Re: CPP usage in GHC.

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

Re: CPP usage in GHC.

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

Re: CPP usage in GHC.

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

CPP usage in GHC.

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

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

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

Re: ARM64 Task Force

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

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

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

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

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

Re: phabricator issue with git submodules.

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

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

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

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

Re: HEAD build fails on compiling haddoc

. 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

Re: Huge space leak of GHC API 7.8.x?

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

Re: 64bit Solaris was: Re: 7.8.1 plan

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

Two days old build breakage on i386.

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

Re: Two days old build breakage on i386.

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

Re: [commit: ghc] master: Revert Per-thread allocation counters and limits (f0fcc41)

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

Re: [commit: ghc] master: Revert Per-thread allocation counters and limits (f0fcc41)

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

Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)

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

checking clean reporting a lot of non-deleted files.

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:

strip related failure [was: Re: solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32, Failure]

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

Re: strip related failure [

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

Re: Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04

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

Re: 64bit Solaris was: Re: 7.8.1 plan

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

Re: Offering GHC builder build slaves

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

  1   2   >