Currently it seems that master's build system has a few sticky points,
* build.mk.sample adds dyn to GhcLibWays twice in the perf and
perf-llvm flavors (added once in the global DYNAMIC_BY_DEFAULT check
and again in the per-flavor PlatformSupportsSharedLibs). This leads
to a multitude of
On Mon, 13 Feb 2012 09:38:44 +0800, Ricardo Wurmus
wrote:
> Hi,
>
> I'm trying to compile my Haskell project on x86_64 with GHC 7.4.1 and
> the LLVM backend for ARM, but LLVM's llc either segfaults (version
> 3.0) or aborts (2011-07-12 revision with patch as described here[1]).
> I've filed a bu
On Wed, 01 Feb 2012 10:56:48 +, Simon Marlow wrote:
> I think it's a bit late to be putting this patch into 7.4.1 at this
> stage, sorry. Since it doesn't affect any APIs there's the possibility
> of putting it into 7.4.2, as long as we review it carefully for any
> possible collateral dam
On Sun, 29 Jan 2012 12:21:37 -0500, Ben Gamari wrote:
> Yesterday I finally had a large block of time to devote to the ARM
> linker. While I spent a large fraction of the day tracking down an
> unrelated bug (ticket #5824, David, your feedback would be greatly
> appreciated here), t
On Mon, 30 Jan 2012 09:20:32 +0100, Karel Gardas
wrote:
>
> Hello Simon,
>
> up to 7.4.1 RC2 this was solely HEAD issue, now with 7.4.1 RC2 it shows
> also on 7.4. The bug shows as:
>
> internal error: ASSERTION FAILED: file rts/Schedule.c, line 506
>
> (GHC version 7.4.0.20120126 for a
Yesterday I finally had a large block of time to devote to the ARM
linker. While I spent a large fraction of the day tracking down an
unrelated bug (ticket #5824, David, your feedback would be greatly
appreciated here), the linker is looking quite good,
$ inplace/lib/ghc-stage2 -B/opt/ghc/ghc/gh
On Mon, 14 Nov 2011 08:06:19 +, Simon Peyton-Jones
wrote:
> | It would be nice if the compiler could apply SPECIALIZE pragmas
> | recursively. For example, if I have a polymorphic function f which calls
> | polymorphic functions g and h, it would be nice if one could apply a
> | SPECIALIZE pr
It would be nice if the compiler could apply SPECIALIZE pragmas
recursively. For example, if I have a polymorphic function f which calls
polymorphic functions g and h, it would be nice if one could apply a
SPECIALIZE pragma to f and have g and h specialized automatically. Just
a thought.
Cheers,
On Sat, 22 Oct 2011 16:58:18 +0200, Karel Gardas
wrote:
> Hi Ben,
>
> first of all, thank you very much for your progress. No, I don't see
> crash, but in fact infinite loop. As far as I understand the linker
> message '..linking...done' is printed when all the relocations are
> processed --
After much debugging, I've put up a new version of my ARM linker support
patchset on Github[1]. While the relocation code seems to work insofar
as it gets past linking and begins running code without SIGILL or
SIGSEGV, clearly something is amiss,
$ inplace/bin/ghc-stage2 -Binplace/lib --interactiv
On Mon, 17 Oct 2011 10:24:29 -0500, Gabriel Dos Reis
wrote:
> On Mon, Oct 17, 2011 at 9:52 AM, Ben Gamari wrote:
> > On Mon, 17 Oct 2011 08:55:42 +0100, Simon Marlow wrote:
> >> I think if we just add those functions to the table unconditionally, it
> >> may bre
On Mon, 17 Oct 2011 08:55:42 +0100, Simon Marlow wrote:
> I think if we just add those functions to the table unconditionally, it
> may break the C backend on certain other platforms or perhaps other
> versions of gcc. I agree it should work out of the box, but we did not
> need this change in
On Sun, 16 Oct 2011 22:43:52 +0200, Karel Gardas
wrote:
> Now I got:
>
Fixed all of these. The problem was a misplaced #endif.
> >> also how do you do the changes push into Git? I always get conflicts
> >> while doing pull from your repo...
> >>
> > Yes, I'm very sorry about that. I've been reb
Mark,
Recently I stumbled upon your post to cvs-ghc last April announcing the
completion of your cross-compiling work. I see that the cross branch no
longer exists. Does this mean these changes have been merged? Is there
documentation regarding how these changes are used?
Thanks!
- Ben
On Sun, 16 Oct 2011 22:10:16 +0200, Karel Gardas
wrote:
> On 10/16/11 09:28 PM, Ben Gamari wrote:
(snip)
> Does not seems so. You still attempt to invoke makeArmSymbolExtra with
> just 3 args, while it's defined with 4 and I'm not able to fix that
> since I'm not su
On Sun, 16 Oct 2011 21:06:27 +0200, Karel Gardas
wrote:
> On 10/16/11 08:41 PM, Ben Gamari wrote:
> > On Sun, 16 Oct 2011 20:03:24 +0200, Karel Gardas
> > wrote:
> >>
> >> Also I'm quite out of idea what was your intention on line above so I'm
>
On Sun, 16 Oct 2011 20:03:24 +0200, Karel Gardas
wrote:
>
> Also I'm quite out of idea what was your intention on line above so I'm
> not able to fix this myself.
>
Doh, yes. You are right. Fixed. I also fixed a serious oversight in my
target address calculation.
> Also another simple fix is
On Fri, 14 Oct 2011 11:16:52 -0400, Ben Gamari wrote:
> Thanks for the fix.
>
> > applied to get it compiling, I got:
> >
> > Loading package ghc-prim ... linking ... ghc-stage2:
> > /export/home/karel/vcs/ghc-src/bgamari-ghc-arm-linker/libraries/ghc-prim/dist-in
On Sat, 15 Oct 2011 07:00:28 +0200, Karel Gardas
wrote:
> http://www.haskell.org/pipermail/cvs-ghc/2011-October/066578.html --
> that's the patch I've noted in some email to you, that you need it.
> Sorry for not stressing the fact more.
>
No worries. I'm just happy to have found the issue. I
On Fri, 14 Oct 2011 07:09:12 +0200, Karel Gardas
wrote:
>
> Hi Ben,
>
Hmm, looking at compiler/ghc.mk, it seems the checks for whether the
architecture supports registerised builds and NCG don't check for ARM. I
suspect this is my problem. Perhaps you have a patch that hasn't been
upstreamed to
On Fri, 14 Oct 2011 07:09:12 +0200, Karel Gardas
wrote:
>
> Hi Ben,
>
> what's wrong is your build.mk file. I'm using:
>
> GhcLibWays = v
>
> SplitObjs = NO
> HADDOCK_DOCS = NO
> BUILD_DOCBOOK_HTML = NO
> BUILD_DOCBOOK_PS = NO
> BUILD_DOCBOOK_PDF = NO
>
It seems the problem
On Fri, 14 Oct 2011 09:51:40 +0100, Simon Marlow wrote:
> On 13/10/2011 19:30, Ben Gamari wrote:
> > While compiling the master branch on my ARM machine, I ran into the
> > following error. It seems that the Alloc.hs defines functions named
> > free, malloc, and realloc, whic
On Fri, 14 Oct 2011 07:38:06 +0200, Karel Gardas
wrote:
> On 10/14/11 12:52 AM, Ben Gamari wrote:
> > On Thu, 13 Oct 2011 19:02:24 +0200, Karel Gardas
> > wrote:
> >> OK! Quick testing reveals:
> >>
> >> Loading package ghc-prim ... linking ... ghc-s
On Fri, 14 Oct 2011 07:09:12 +0200, Karel Gardas
wrote:
>
> Hi Ben,
>
> what's wrong is your build.mk file. I'm using:
>
> GhcLibWays = v
>
> SplitObjs = NO
> HADDOCK_DOCS = NO
> BUILD_DOCBOOK_HTML = NO
> BUILD_DOCBOOK_PS = NO
> BUILD_DOCBOOK_PDF = NO
>
> here and it's work
On Thu, 13 Oct 2011 20:38:31 +0200, Karel Gardas
wrote:
> -fvia-C means you are building unregisterised build. Perhaps, you might
> try registerised build or even that was your intention? For this you
> will need to apply my submitted patch or do this yourself...
>
I must say, I think I must b
On Thu, 13 Oct 2011 19:02:24 +0200, Karel Gardas
wrote:
> OK! Quick testing reveals:
>
> Loading package ghc-prim ... linking ... ghc-stage2:
> /export/home/karel/vcs/ghc-src/bgamari-ghc-arm-linker/libraries/ghc-prim/dist-install/build/HSghc-prim-0.2.0.0.o:
>
> ARM to Thumb transition unsuppo
On Thu, 13 Oct 2011 20:38:31 +0200, Karel Gardas
wrote:
>
> Hi Ben,
>
> -fvia-C means you are building unregisterised build. Perhaps, you might
> try registerised build or even that was your intention? For this you
> will need to apply my submitted patch or do this yourself...
>
I've been tr
While compiling the master branch on my ARM machine, I ran into the
following error. It seems that the Alloc.hs defines functions named
free, malloc, and realloc, which then clash with the built-in
functions of the same name. Any ideas what to do here? Thanks.
Cheers,
- Ben
[1] Error:
"inplace
On Thu, 13 Oct 2011 19:02:24 +0200, Karel Gardas
wrote:
> On 10/13/11 05:28 PM, Ben Gamari wrote:
> >> Also to get to this stage I needed to apply attached patch. However I'm
> >> not sure I got `A' definition right hence just commenting out #ifdefs
> >
On Thu, 13 Oct 2011 08:21:53 +0200, Karel Gardas
wrote:
> Great! It looks like few are still unhandled -- see my email with relocs
> listings, for example ghc-prim load now fails on R_ARM_REL32 it seems:
>
Excellent, this is progress. I've implemented R_ARM_REL32. If I am
correct, the only thin
On Thu, 13 Oct 2011 00:15:39 +0200, Karel Gardas
wrote:
> On 10/12/11 08:44 PM, Ben Gamari wrote:
> > On Wed, 12 Oct 2011 20:35:12 +0200, Karel Gardas
> > wrote:
> >>
> >> I'm also using this to make it compilable:
> >>
> > Yep, you
On Thu, 13 Oct 2011 00:15:39 +0200, Karel Gardas
wrote:
> On 10/12/11 08:44 PM, Ben Gamari wrote:
> > On Wed, 12 Oct 2011 20:35:12 +0200, Karel Gardas
> > wrote:
> >>
> >> I'm also using this to make it compilable:
> >>
> > Yep, you
On Thu, 13 Oct 2011 00:15:39 +0200, Karel Gardas
wrote:
> On 10/12/11 08:44 PM, Ben Gamari wrote:
> > On Wed, 12 Oct 2011 20:35:12 +0200, Karel Gardas
> > wrote:
> >>
> >> I'm also using this to make it compilable:
> >>
> > Yep, you
On Wed, 12 Oct 2011 20:35:12 +0200, Karel Gardas
wrote:
>
> I'm also using this to make it compilable:
>
Yep, you are right. Merged.
Cheers,
- Ben
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On Wed, 12 Oct 2011 20:25:30 +0200, Karel Gardas
wrote:
> On 10/12/11 07:57 PM, Ben Gamari wrote:
> >> the system is Ubuntu 11.04. Looking into /usr/include/elf.h reveals no
> >> R_ARM_THM_MOVW_ABS_NC nor R_ARM_THM_MOVT_ABS relocations defined.
> >>
> > Oh
On Wed, 12 Oct 2011 19:23:54 +0200, Karel Gardas
wrote:
> On 10/12/11 07:27 AM, Ben Gamari wrote:
> > I have finished a first cut of a patch doing the above and it is
> > available at [4]. Be aware that this is entirely untested (hopefully
> > this will change tomorrow af
On Wed, 12 Oct 2011 11:42:29 +0100, Simon Marlow wrote:
> I don't see anything obviously bogus. But you should test it before we
> pull it in - I'd be willing to bet a large sum of money that it doesn't
> just work.
>
On this note, what is the best way to test this code? Is this simply a
matte
While building stage 1 on my ARM I ran into the following error. It
appears that the code is in a BEWARE_LOAD_STORE_ALIGNMENT #ifdef, which
perhaps isn't exercised frequently on more common architectures. Seems
like someone just forgot to update a function reference. The fix
is trivial.
Cheers,
Fixes build error:
compiler/cmm/PprC.hs:961:33:
Couldn't match expected type `Platform'
against inferred type `CmmExpr'
In the first argument of `pprExpr1', namely `expr'
In the second argument of `(<+>)', namely `pprExpr1 expr'
In the first argument of `parens', namely
While building stage 1 on my ARM I ran into the following error. It
appears that the code is in a BEWARE_LOAD_STORE_ALIGNMENT #ifdef, which
perhaps isn't exercised frequently on more common architectures. Seems
like someone just forgot to update a function reference. The fix
is trivial.
Cheers,
On Wed, 12 Oct 2011 11:42:29 +0100, Simon Marlow wrote:
> > Concerning the relocations, it appears that the x86 code only implements
> > two relocation types. Looking at my installed GHC-compiled libraries, it
> > seems these are the only two relocation types which GHC produces. The
> > non-Haskel
Seeing as GHC has been building registerised binaries for ARM for some
time now[1], I thought it might be about time that the GHC port was
finished (especially considering bug #4268[2] makes the lack of GHCi
quite painful). The one remaining task that I have found is the lack of GHCi
support. The p
42 matches
Mail list logo
