Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe

Hi, when trying to compile a ghc HEAD on LLVM ARM, I end up getting an exception: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140911 for arm-apple-ios): globalRegMaybe After some digging I found that a new call to globalRegMaybe was introduced here:

Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe

in a bug report and attach a patch - I'm afraid this mail may have gone unnoticed :-) Janek Dnia piątek, 12 września 2014, Moritz Angermann napisał: Hi, when trying to compile a ghc HEAD on LLVM ARM, I end up getting an exception: ghc-stage1: panic! (the 'impossible' happened

Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe

-boun...@haskell.org] On Behalf Of Moritz | Angermann | Sent: 15 September 2014 10:19 | To: ghc-devs@haskell.org | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe | | Hi Janek, | | yea :) I think it went by unnoticed. Patch is already in Phab, | | https

Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe

, a priority, they are less likely to get lost. It's also easier for people to say on a ticket is the design right? than it is on Phab which is optimised for *code* review. Simon | -Original Message- | From: Moritz Angermann [mailto:mor...@lichtzwerge.de] | Sent: 15 September 2014

Re: FFI library error building GHC

— Moritz Angermann +49 170 54 33 0 74 mor...@lichtzwerge.de lichtzwerge GmbH Freisinger Landstr. 25 85748 Garching b. München Amtsgericht München HRB 207882 Geschäftsführung: Moritz Angermann, Ralf Sangl USt-Id: DE291948767 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte

Re: FFI library error building GHC

on x86_64, unfortunately I haven't found any way to solve it. Reverting the commit that upgrades to libffi-3.1 still showed this issue. I'd love to see this fixed, as I am unable to do any development on GHC until it's fixed :( On Sat, Sep 20, 2014 at 3:15 AM, Moritz Angermann mor

Building head with head

Hi, today I tried to build head with head on os x. The result was: 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/ghc-cabal configure libraries/binary dist-boot

Re: 7.10 STABLE freeze date

___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs — Moritz Angermann +49 170 54 33 0 74 mor...@lichtzwerge.de lichtzwerge GmbH Freisinger Landstr. 25 85748 Garching b. München Amtsgericht München HRB 207882

Out Of Process Template Haskell

Hi, as you may or may not know, template haskell is not available to cross compilers. And therefore cross compiler are devoid of an important feature of haskell. We are currently building ghc cross compiler as stage1 compiler with a foreign target. This means that we use a stage0 compiler

Looking up importDecl and Unique inequality

Hi *, I'm still trying to get a stage1 compiler with TH support. After some experimenting, I managed to adjust ghc-7.8 sufficiently to build and not complain about compiling TH code right away. I'm now stuck with importDecl trying to import Language.Haskell.TH.Lib.ExpQ (as that is

Re: Remote GHCi

I’m not sure how much I can actually contribute to this, but I’ll just add a few pointers to nothing gets lost. I’m not very familiar with remote ghci, but I think that there is some overlap between remote ghci and out of process template haskell compilation[1][2]. Most of ghcjs’s TH code is in

Re: GHC build currently broken on OS X and Windows

Sorry about that :( > On Jul 22, 2016, at 5:02 AM, Karel Gardas wrote: > > > 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

Re: Request for feedback: deriving strategies syntax

option in [2]. However, I'd appreciate further discussion on >> the above options, which one you prefer, and if you have other >> suggestions for syntax to use. >> >> Ryan S. >> - >> [1] https://ghc.haskell.org/trac/ghc/ticket/10598 >>

Re: Cross-compiling Template Haskell via -fexternal-interpreter and IPC

Great work Alberto, I’m in favor of adding some form of network layer, as there are scenarios where you have to run the th compilation process on a different machine. This would be the case for iOS for example. When I toyed with this ~2years ago, trying to port the out of process th solution

Improving the contributing to ghc experience

Friends, as you all have seen over the last few days, making the contributing to ghc experience easier for those who have not yet contributed to ghc, is a topic of interest to many of us. I’d like to thank Edward Z. Yang for seizing the opportunity to convince us to test drive the ghc-proposal

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

I don't think Phabricator tries to be or emulate fit in any way; I think this is a misconception. The way I see it, phabricator is just a glorified diff-dump, which is supposed to work with any VCS in principle. All that arc essentially does is, compute the diff from an offset (e.g. master) to

Re: How, precisely, can we improve?

Friends, after the recent discussion here and on #ghc, I’ve taken the liberty to extract a small part of this into a proposal[1]. In essence this does not cover *all* of the wiki, but the commentary and documentation part, after Herbert mentioned that would be something he could see happening.

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

>> Hence you can go wild on your local branches (use what ever >> development model suites your needs) and get one final squashed commit >> with an extensive summary. >> > Sure, but this leads to generally unreviewable patches IMHO. In order to > stay sane I generally split up my work into a set

Re: How, precisely, can we improve?

gating > people to think to use this feature? Most, even those who know it's an > option, aren't going to think to do this in the heat of trying to > track down an answer to something. > > On Wed, Sep 28, 2016 at 11:08 PM, Moritz Angermann > <mor...@lichtzwerge.de> wrote

Re: How, precisely, can we improve?

Just a quick note: Google provides the “Date range” filter found under search options. This allows to narrow down the date range. > On Sep 29, 2016, at 11:55 AM, Bardur Arantsson wrote: > > On 2016-09-29 04:43, Richard Eisenberg wrote: >> Here's a pre-proposal (which could

Re: How, precisely, can we improve?

hut down > student accounts hosting papers. I had to do some archaeology on an > obscure Chinese FTP server to find some of Don Stewart's papers and > slides recently. > > I believe there can be a convincing solution to all of this and more. > > On Wed, Sep 28, 2016 at 11

Re: Making (useful subsets of) bytecode portable between targets

There is https://github.com/ghc-proposals/ghc-proposals Sent from my iPhone > On 25 Nov 2016, at 11:30 PM, Shea Levy wrote: > > Simon Marlow writes: > >> The right thing is to have a clean separation between runtime >> imports and compile-time imports.

Re: Making (useful subsets of) bytecode portable between targets

M T Chakravarty <c...@justtesting.org> > wrote: > > Sorry, but I don’t think running on the device is practical. How do you want > to do CI, for example? > > Manuel > >> Moritz Angermann <mor...@lichtzwerge.de>: >> >> >>> On No

Re: Making (useful subsets of) bytecode portable between targets

Hi, just to also note: that this completely ignores any host / target IO actions that TH might want to run. cheers, moritz > On Nov 24, 2016, at 12:51 PM, Moritz Angermann <mor...@lichtzwerge.de> wrote: > > It's certainly far from ideal, but for CI, what obstacles ar

Re: Making (useful subsets of) bytecode portable between targets

cess to, and use this to authenticate access to the runner. >> See https://docs.travis-ci.com/user/encryption-keys/ >> >> Edward >> >> Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100: >>> If you use Travis CI or such, do you re

Re: Status of "Improved LLVM backend"

> On Nov 27, 2016, at 10:17 PM, Michal Terepeta > wrote: > > > Hi, > > > > I’m trying to implement a bitcode producing llvm backend[1], which would > > potentially > > allow to use a range of llvm versions with ghc. However, this is only > > tangentially > >

Re: Status of "Improved LLVM backend"

Hi, I’m trying to implement a bitcode producing llvm backend[1], which would potentially allow to use a range of llvm versions with ghc. However, this is only tangentially relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are other complications besides the

Re: Telemetry (WAS: Attempt at a real world benchmark)

Hi, I’m mostly against any tracking. For privacy reasons, but also what is the data going to tell? Would I track timings, used extensions and ghc version, module size, per compiled module, per compiled project or per ghc invocation? What are the reasons we believe the packages in hackage, or

Re: Attempt at a real world benchmark

> On Dec 9, 2016, at 1:00 PM, Joachim Breitner <m...@joachim-breitner.de> wrote: > > Hi, > > Am Freitag, den 09.12.2016, 09:50 +0800 schrieb Moritz Angermann: >> Hi, >> >> let me thank you perusing this! >> >>>> I am not sure how

Re: Attempt at a real world benchmark

>> Actually, now that I think about it: What about if this were integrated >> into the Cabal infrastructure? If I specify "upload-perf-numbers: True" >> in my .cabal file, any project on (e.g.) GitHub that wanted to opt-in >> could do so, they could build using Travis, and voila! >> > >

Re: Attempt at a real world benchmark

Hi, let me thank you perusing this! >> I am not sure how useful this is going to be: >> + Tests lots of common and important real-world libraries. >> − Takes a lot of time to compile, includes CPP macros and C code. >> (More details in the README linked above). > > another problem with the

Re: Status of "Improved LLVM backend"

> > > > I don’t know if generating llvm from stg instead of cmm would be a > > > > better > > > > approach, which is what ghcjs and eta do as far as I know. > > > > > > Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty > > > low-level > > > representation compared to STG)?

Re: Measuring performance of GHC

Hi, I see the following challenges here, which have partially be touched by the discussion in the mentioned proposal. - The tests we are looking at, might be quite time intensive (lots of modules that take substantial time to compile). Is this practical to run when people locally execute

Re: Measuring performance of GHC

> | - One of the core issues I see in day to day programming (even though > |not necessarily with haskell right now) is that the spare time I > | have > |to file bug reports, boil down performance regressions etc. and file > |them with open source projects is not paid for and hence

Re: Measuring performance of GHC

Hi, I’ve started the GHC Performance Regression Collection Proposal[1] (Rendered [2]) a while ago with the idea of having a trivially community curated set of small[3] real-world examples with performance regressions. I might be at fault here for not describing this to the best of my abilities.

Re: I have Aphronted Phab

While we are at it, can we please permanently redirect http to https for phabricator? Logging in via http also doesn't Seenot work properly the last time I tried. Pretty please? Cheers, moritz Sent from my iPhone > On 24 Dec 2016, at 11:30 AM, Edward Z. Yang wrote: > > Hi

Re: ghc-stage2 —interactive segfaults on Mac OS X 10.11.6 (build flavour = prof)

Hi, that looks pretty much like I broke that :-( Do you have a backtrace? The info structs should be filled properly by ocInit_MachO when loading object code. The nlist would point to the symbol names list. However I believe that either oc is already NULL, in which case you should have never

GHC Build System & Cabal

Dear friends, I’m currently exploring the possibility to build two versions of base similar to how we build various ways of the rts. The reasons for doing this won’t add much to the discussion. Reading https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Cabal I find the following:

GHC cross compilation survey

Dear friends, as some of you might have noticed, together with obsidian.systems, I’m trying to make cross compiling GHC a bit easier. To that extend, I’d like to invite you to fill out a short survey[1], so we understand the needs of the community better. Please follow the attached link and

Re: Compilation time

For those of us who are on macOS, you usually do not have any gcc, it’s all clang behind the curtains. E.g. see $ /usr/bin/gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.1.0

GHC cross compilation survey results

017, at 6:15 PM, Moritz Angermann <moritz.angerm...@gmail.com> > wrote: > > Dear friends, > > as some of you might have noticed, together with > obsidian.systems, I’m trying to make cross compiling > GHC a bit easier. To that extend, I’d like to invite > you to

Re: Cross-compiling Template Haskell via -fexternal-interpreter and IPC

Hi Alberto, let me know if I can be of help. As you likely saw I’ve been writing this all up on https://medium.com/@zw3rk. With the outstanding diffs[1], this should hopefully just work. As I haven’t used windows or know the linker on windows, I’m not perfectly sure about the implications. It

ANN: preview of alternative llvm code gen

Hi, as presented during the HIW at ICFP 2016, and ICFP 2017, I’ve been spending a some time on an alternative llvm backend. GHC used LLVM as an external tool, and communicates with LLVM via LLVMs Intermediate Representation. For this the LLVM backend in GHC (via `-fllvm`) writes out text

The Curious Case of T6084 -or- Register Confusion with LLVM

Hi *, TLDR: The LLVM backend might confuse floating registers in GHC. # Demo (Ticket #14251) Let Demo.hs be the following short program (a minor modification from T6084): ``` {-# LANGUAGE MagicHash, BangPatterns #-} module Main where import GHC.Exts {-# NOINLINE f #-} f :: (Int# -> Float# ->

Re: The Curious Case of T6084 -or- Register Confusion with LLVM

assume that `q` accepts its first two floating-point >> arguments in F3 and D4, because I'm pretty sure the standard Cmm calling >> convention assigns them to F1 and D2, respectively. Are we actually >> outputting `q` such that F3 and D4 are used? >> >> >>> (Thi

-0 rational?

Hi *, I just ran into the following case: > fromRat (-0 :: Rational) :: Double 0.0 > -0 :: Rational 0 % 1 How do I encode negative zero as a rational? The question come up as `CmmFloat` is defined as `CmmFloat Rational Width` in compiler/cmm/CmmExpr.hs. And my code generator thus turned

In C--: should CmmCall and CmmProc agree on their live registers?

Hi, apologies for writing so many emails recently. This is a minor spinoff from the "The Curious Case of T6084" email. While digging into it, I keep asking myself if CmmProc’s live registers should match those of the CmmCall that is calling it? Is there any invariant we try to enforce or would

Re: Proposal: Allow passing in linkable files from TH

Hi Alec, I think this would be great to have. Here are few other discussions that have similar needs but do not necessarily have TH as a direct dependency: - https://mail.haskell.org/pipermail/haskell-cafe/2017-September/127877.html in which aditya siram (deech) asks about linking non-c build

Re: GHC HEAD now needs extra tools to build libffi?

I’ll try to dig into this in three days when I’m back in SG. Joachim, thanks for providing the full build log. Sent from my iPhone > On 15 Oct 2017, at 5:41 AM, Ben Gamari wrote: > > Joachim Breitner writes: > >> Hi, >> >> >> Am Dienstag,

Re: In C--: should CmmCall and CmmProc agree on their live registers?

CmmProcs should have no live registers apart > from those used to pass args, and the standard ones. > > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Moritz > | Angermann > | Sent: 22 September 2017 07:33

Ignoring ANN Module "HLint: ..."

Hi *, can we detect annotations like `{-# ANN module "HLint: ignore Reduce duplication" #-}` easily? Right now this will result (without -fexternal-interpreter or a stage2 compiler) in Ignoring ANN annotation, because this is a stage-1 compiler without -fexternal-interpreter or doesn't

Re: Underscore in binary literals

t; > Regards, > Takenobu > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > Rahul Muttineni > > _

Re: GHC HEAD now needs extra tools to build libffi?

I hope this will be fixed with: https://phabricator.haskell.org/D4053 and https://phabricator.haskell.org/D4054 Sent from my iPhone > On 2 Oct 2017, at 6:33 AM, Ryan Scott wrote: > > Trying to build a fresh copy of GHC HEAD (at commit [1]) today failed > for me with

Re: Ignoring ANN Module "HLint: ..."

> On Sep 24, 2017, at 1:48 PM, Brandon Allbery <allber...@gmail.com> wrote: > > On Sun, Sep 24, 2017 at 1:44 AM, Moritz Angermann > <moritz.angerm...@gmail.com> wrote: > can we detect annotations like `{-# ANN module "HLint: ignore Reduce > du

Re: Including libffi as a submodule

Yes. that’s the one. > On Sep 28, 2017, at 3:56 PM, Boespflug, Mathieu wrote: > > Aren't we talking about the C project here? https://sourceware.org/libffi/ > -- > Mathieu Boespflug > Founder at http://tweag.io. > > > On 28 September 2017 at 06:27, David Feuer

[broken HEAD] In which the strict state monad fails at basic arithmetic

Hi *, while working on some related code. I came across a rather peculiar behavior with GHC built from the current master branch at b2c2e3e8. After condensing the application quite a bit[1], the test case now produces 8 with ghc 8.2.1 and -6 with ghc 8.3 @ b2c2e3e8 The sample application

Re: GHC staus

d make sure to meet and talk about cross-compilation and GHC >> for iOS :) >> >> Manuel >> >>> Moritz Angermann <moritz.angerm...@gmail.com>: >>> >>> Hi, >>> >>> not sure if this is noteworthy: >>> >>>

Re: GHC staus

Hi, not sure if this is noteworthy: The following is or will hopefully make(*) it into 8.4 as well - (1) iserv-remote (run iserv on a remote device over the network) - (2) arm / aarch64 linker for elf and mach-o - (3*) `-staticlib` support for Linux and BSD derivatives (was darwin only): -

Re: GHC HEAD now needs extra tools to build libffi?

> I ran git bisect: > > -- > > e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit > commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 > Author: Moritz Angermann <moritz.angerm...@gmail.com> > Date: Sat Sep 30 09:31:12 2017 -0400 > > Allow libffi snapshots > > This is rather ann

Re: Call for features for GHC 8.4

I’ll try to update the page when I’m back from VN. 8.4 - aarch64/arm linker for mach-o/elf - staticlib - iserv over the network - extended Q monad? (I really think we should try to iron this out for 8.4) - various iOS/Android/Raspberry Pi/... cross compilation fixes - llvm5 8.6 - llvmng? I’m

Re: GHC HEAD now needs extra tools to build libffi?

> it’s an Arch linux (generously sponsored by Richard’s university). I > have not idea how to give more precise information about the distro > release version or such :-) > > Greetings, > Joachim > > Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann: >>

Re: Compiling natively GHC for ARMv7l softabi

> > "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist > -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header > -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP > -dcmm-lint -i -irts -irts/dist/build

Re: GHC HEAD now needs extra tools to build libffi?

not idea how to give more precise information about the distro > release version or such :-) > > Greetings, > Joachim > > Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann: >> Hi, >> >> so this somehow looks like for a not yet absolutely clear

Re: Compiling natively GHC for ARMv7l softabi

Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even make it to the assembly stage... > On Oct 19, 2017, at 3:32 PM, shif...@nanotek.info wrote: > > October 19, 2017 10:34 AM, "Moritz Angermann" <moritz.angerm...@gmail.com> > wrote: > >&

Re: GHC HEAD now needs extra tools to build libffi?

i (v3.2.1) and using it in > configure with --with-ffi-includes and --with-ffi-libraries but got the same > error. > > > On 10/09/2017 02:40 AM, Moritz Angermann wrote: >> Yes, this commit indeed introduced the need for makeinfo, however after some >> debugging and improved packagi

Re: perf.haskell.org functional again

Hooray! Thanks for doing this! Sent from my iPhone > On 24 Oct 2017, at 8:02 AM, Joachim Breitner wrote: > > Hi, > > after a system upgrade to avoid weird linker errors, and after some fixes in > the nofib submodule, http://perf.haskell.org/ghc is running again. >

Re: Relocatable dist

uild for all the code > signing, sandboxing, etc. > > Cheers, > Manuel > >> Am 23.10.2017 um 17:04 schrieb Moritz Angermann <moritz.angerm...@gmail.com>: >> >> Hi, >> >> while trying to make the binary-distribution logic work for >> cross c

Re: GHC HEAD now needs extra tools to build libffi?

sue for perf.haskell.org. > > Greetings, > Joachim > > Am Donnerstag, den 19.10.2017, 16:28 +0800 schrieb Moritz Angermann: >> Hi, >> >> As it turns out this might be linker madness. I do not yet understand why >> this did work with >> the &q

Re: Relocatable dist

of the stage1 or stage2 compiler. However, I am now again at the point where I start hacking on the build system, while Hadrian is imminent. And this is quite depressing. Cheers, Moritz -- [1]: https://phabricator.haskell.org/D4121 > On Oct 24, 2017, at 9:54 AM, Moritz Angermann <moritz.

Re: [ANNOUNCE] Hadrian update

Congrats Andrey, > 2) A major refactoring by Moritz Angermann is on the way. Moritz is primarily > interested in cross compilation, but to make it work he had to get rid of the > ghc-cabal utility, reorganise the build tree, and make numerous other > improvements to Hadria

Word64 from int64_t on 32bit arm seems off.

tes for when reconstructing the Word64. If anyone got any idea, I'd be happy to know. Otherwise I guess I'd have to start adding debug information into the rts? Cheers, Moritz > On Nov 28, 2017, at 12:52 PM, Moritz Angermann <moritz.angerm...@gmail.com> > wrote: > > Hi! > >

`binary` serializing datatypes deriving Generic wrong on arm (32bit) with GHC HEAD

Hi! while trying to make sure cross compilation with Template Haskell works properly with 8.4, I ran into the following situation: When serializing data types, e.g. `Name OccName NameFlavour` in the transmission of Template Haskell Splice results from a 32bit arm device to the x86_64 host ghc.

Re: [GHC DevOps Group] Release policies

Hi, this might only be tangentially relevant. However, you might consider this a working example of GHC and Cabal bleeding edge symbiosis. Some might have seen that I built some *relocatable* GHC releases for cross compilation (however those include the full base compiler for macOS and linux

Re: GHC-API unloading from external interpreter

Hi, I believe you are looking for the `Message` GADT in `GHCi.Message` ``` -- - -- The RPC protocol between GHC and the interactive server -- | A @Message a@ is a message that returns a value of type @a@. -- These are

Re: GHC on Ubuntu

Hi Simon, Herbert provides quite a few GHC builds at https://launchpad.net/~hvr/+archive/ubuntu/ghc Looking at https://wiki.ubuntu.com/Releases, makes me believe LTS might be Xenial or Trusty. For both seem to be packages up to 8.2.2 and even HEAD available. Hope that helps. Cheers, Moritz >

Re: Relocatable dist

n Tue, Oct 24, 2017 at 8:02 PM, Manuel M T Chakravarty >> <c...@justtesting.org> wrote: >> Why are you saying that? >> >> I think, Moritz is right. Hadrian is supposed to be the build system for >> 8.4. Adding new functionality for cross-compilation to the old build

Re: Bringing back #ghc IRC logging

Just the other day, someone said logging *did* work again... and indeed, it seems like it does: http://ircbrowse.net/browse/ghc?id=202340=1508883548#t1508883548 Cheers, Moritz > On Oct 25, 2017, at 9:55 AM, Ben Gamari wrote: > > Niklas Hambüchen writes: >

Re: Compiling natively GHC for ARMv7l softabi

Can you rerun that command with -keep-llvm-files and attach the generated .ll file? Cheers, Moritz Sent from my iPhone > On 22 Oct 2017, at 3:06 PM, shif...@nanotek.info wrote: > > October 22, 2017 10:37 AM, "Moritz Angermann" <moritz.angerm...@gmail.com> >

Re: Compiling natively GHC for ARMv7l softabi

Could you try running this with `-v`? Hopefully, this time will will not stop somewhere in the middle, but rather give us the full output, and also reproduce the errors. > On Oct 22, 2017, at 2:33 PM, shif...@nanotek.info wrote: > > "inplace/bin/ghc-stage1" -static -O -H64m -Wall -Iincludes

Re: Compiling natively GHC for ARMv7l softabi

g. quick-cross, perf-cross). Cheers, Moritz > On Oct 22, 2017, at 4:05 PM, shif...@nanotek.info wrote: > > October 22, 2017 11:51 AM, "Moritz Angermann" <moritz.angerm...@gmail.com> > wrote: > >> Can you rerun that command with -keep-llvm-files and att

Re: Use of -dead_strip_dylibs by default makes the -framework flag appear broken.

Hi, I haven't found a quick fix, which is a bit annoying. A few observations: As we never reference anything from Foundation, we strip it away, and a runtime test of Foundation classes returns false. That does make sense in the dead_strip setting. But as Travis pointed out is contrary to what

Re: Why do we prevent static archives from being loaded when DYNAMIC_GHC_PROGRAMS=YES?

n that we wouldn't be able to dlopen() a shared >> library that depends on the statically linked code, because the system >> linker can't see the symbols that the RTS linker has loaded. GHC doesn't >> currently know about this restriction, so it would probably go ahead and >&

Why do we prevent static archives from being loaded when DYNAMIC_GHC_PROGRAMS=YES?

Dear friends, when we build GHC with DYNAMIC_GHC_PROGRAMS=YES, we essentially prevent ghc/ghci from using archives (.a). Is there a technical reason behind this? The only only reasoning so far I've came across was: insist on using dynamic/shared objects, because the user said so when building

Re: Compiling natively GHC for ARMv7l softabi

Shiftag, any chance you could try this with 8.2 again then? Cheers, Moritz > On Oct 19, 2017, at 9:56 PM, Ben Gamari <b...@smart-cactus.org> wrote: > > Moritz Angermann <moritz.angerm...@gmail.com> writes: > >> Ugh! This looks even worse. I'm a bit at a l

Re: Hadrian

Hi, two things. a) why a git subtree if we keep working on github with hadrian, wouldn't that imply using a submodule? We use submodules for all the other ghc boot libs that are not part of the tree and are developed on github as well, no? As far as I understand a subtree, it's

Re: Hadrian

> On Oct 20, 2017, at 6:24 PM, Herbert Valerio Riedel <hvrie...@gmail.com> > wrote: > > Hi Moritz (et al.), > > On 2017-10-20 at 09:32:29 +0800, Moritz Angermann wrote: > >> a) why a git subtree if we keep working on github with hadrian, wouldn't >&g

Relocatable dist

Hi, while trying to make the binary-distribution logic work for cross compilers. I've come wonder, how hard it could be to make GHC relocatable. (e.g. just unpack the distribution, and use the compiler from the `bin` folder within). Right now this does not work due to the need for the path to

Re: DoAndIfThenElse

Hi, not sure if this helps. testsuite/tests/parser/should_compile/DoAndIfThenElse.hs gives us ``` {-# LANGUAGE DoAndIfThenElse #-} module DoAndIfThenElse where foo :: IO () foo = do if True then return () else return () ``` and there is some other mention in

Re: Non-Reinstallable packages

Dear friends, we have a set of non-reinstallable packages with GHC, these include iirc template-haskell, and some other. I've got a few questions concerning those: - do we have a complete up-to-date list of those? - why can't we reinstall them (let's assume we use the identical version for

Re: Custom ghcPrimIface for cross-compilation?

Hi, not sure I understand your question. If you build a cross compiler targetting a 32bit device (say Raspbian/Raspberry Pi) for say x86_64 linux, you end up with a 64bit compiler emitting code for a 32bit device. If you question revolves around dynamically changing GHCs target at runtime.

Re: Error submitting a code review

Choose “Abandon Revision” in the comment field at the end of the review. Sent from my iPhone > On 13 Apr 2018, at 6:14 PM, ARJANEN Loïc Jean David > wrote: > > Thanks for the answer. Is there any way to remove an existing draft code > review? I'm not seeing any in the

Re: Building GHC using cabal repl

Hi Joachim, I believe this might be due to the recent changes that try to keep the source tree pristine instead of generating data in-place. This is partially the result of making ghc relocatable: hadrian#445[1]. It included changes to cabal and ghc and the final bits have been merged in the

Re: Treatment of unknown pragmas

Does this need to be *this* hardcoded? Or could we just parse the pragma and compare it to a list of known pragmas to be parsed from a file (or settings value?). The change in question does: -pragmas = options_pragmas ++ ["cfiles", "contract"] +pragmas

Re: Does it sound a good idea to implement "backend plugins"?

A long time ago, I’ve tried to inject plugin logic to allows some control over the driver pipeline (phase ordering) and hooking various code gen related functions. See https://phabricator.haskell.org/D535 At that time I ran into issues that might simply not exist with plugins anymore today,

Re: MR does not merge

I wonder if gitlab could have a feature like what bors offers. Validate and merge or [rebase and validate and merge]+. Thus eventually merging it or rejecting it due to conflict or validation failure. Sent from my iPhone > On 16 Jan 2019, at 10:55 PM, Matthew Pickering > wrote: > > There is

Hackage and ghc shipped package contents mismatch

Dear friends, the other day I've run into an issue where I could not build a package. It turned out that the underlying reason was that the packages ghc ships with are not necessarily the same as they are on hackage. Ryan was kind enough to open Ticket 16199[1]. My use case is that I reduce

Re: GitLab forks and submodules

free to push branches to ghc/ghc. > > > > This is sometimes not ideal as it wastes GHC's CI resources. For example I > > make > > a lot of WIP commits to my work branches, and I don't want to keep CI > > machines > > busy for those. > > > > Ömer >

Re: GitLab forks and submodules

Can’t we have absolute submodule paths? Wouldn’t that elevate the issue? When we all had branches on ghc/ghc this was not an issue. Sent from my iPhone > On 8 Jan 2019, at 5:24 AM, Ben Gamari wrote: > > Simon Peyton Jones via ghc-devs writes: > >> Would it be worth describing this workflow

GitLab forks and submodules

Hi *, so what do we do with submodules? If you point someone to a fork of ghc, say: gitlab.haskell.org/foo/ghc and they try to check it out, they will run into issues because foo didn't clone all the submodules. So how is one supposed to clone a forked ghc repository? Cheers, Moritz

Why can't we re-install the template-haskell package?

Dear friends, as I'm working on making lib:ghc re-installable [1][2]. Ideally I'd prefer we only had to freeze rts + ghc-prim and maybe base (which would implicate the integer library). However, we apparently can't re-install Template Haskell I'm told. Not just not upgrade it, but not even

  1   2   >