On Fri, 26 Sep 2003, Rafael Martinez Torres wrote:
I enabled the flags -g
Sorry , the previous mail was incomplete. send button fired.
GhcRtsHcOpts= -g -optc-DDEBUG
GhcRtsCcOpts= -g
This is my session with gdb , ghc-6.0.1 and mips-sgi-irix65.
I thinks this has nothing to do with the
1.- OK. The distrib/hc-build migth not handle the
dependencies soundly.
What do you mean here? Could you elaborate?
Now I build on the target T as in the host H:
cd hslibs/ gmake boot gmake
cd ghc gmake boot gmake
The touch config.h patch seems to solve the
Numerous additions to configure/configure.in. I can add these
in CVS, but I'm not sure if I should add
+s390-ibm-linux*)
+ HostPlatform=s390-ibm-linux
+ TargetPlatform=s390-ibm-linux #hack
+ BuildPlatform=s390-ibm-linux #hack
+HostPlatform_CPP='s390_ibm_linux'
On Fri, 12 Sep 2003, Simon Marlow wrote:
--
../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package
package.conf.inplace
/usr/users/eden/scratch/ghc-6.0.1/ghc/driver/package.conf.inpl
ace: parse error in package config file
gmake[1]: ***
On Mon, Sep 15, 2003 at 03:18:43PM +0100, Simon Marlow wrote:
Am I right in thinking that by just putting
GhcUnregisterised=YES
SplitObjs=NO
in mk/build.mk every time you build GHC it ought to not only work on
arches with bit-rotted mangler support but also those with none
On Wed, Sep 17, 2003 at 05:14:36PM +0100, Ian Lynagh wrote:
alpha:
--- ghc6-6.0.1.orig/ghc/includes/Stg.h
+++ ghc6-6.0.1/ghc/includes/Stg.h
@@ -33,6 +33,8 @@
# endif
#endif
+#include TailCalls.h
+
/* Configuration */
#include config.h
Ooops, TailCalls.h wants to be below
Am I right in thinking that by just putting
GhcUnregisterised=YES
SplitObjs=NO
in mk/build.mk every time you build GHC it ought to not only work on
arches with bit-rotted mangler support but also those with none
attempted? Where work means compiles the same set of programs, but the
# I ^C it after a little while:
Program received signal SIGINT, Interrupt.
0x1212c62b0 in StgRun () at StgCRun.c:6
6* STG-to-C glue.
So it stalls or loops (it sits at 98% of cpu) on entry to stg_init().
More info will have to wait until I try a debug build.
Try
On Mon, Sep 15, 2003 at 03:18:43PM +0100, Simon Marlow wrote:
Starting with a reg compiler producing reg code and iterating
a standard
configure/make/make install with 6.0.1 gives these numbers on x86:
70m5.850s
86m27.550s
86m26.350s
so it looks like this is about 25%
What are the binary sizes like?
magdcalc is
2730251 (reg)
7697141 (unreg)
before stripping and
1375696 (reg)
4771196 (unreg)
after.
A lot of that difference is due to the absence of SplitObjs on the
unregisterised build, so don't worry too much.
Cheers,
Simon
On Fri, Sep 12, 2003 at 10:59:05AM +0100, Simon Marlow wrote:
Looks like you need some mangler support now...
Am I right in thinking that by just putting
GhcUnregisterised=YES
SplitObjs=NO
in mk/build.mk every time you build GHC it ought to not only work on
arches with bit-rotted mangler
On Thu, Sep 11, 2003 at 07:53:02PM +1000, Donald Bruce Stewart wrote:
simonmar:
Things aren't so easy with alpha as gcc rejects the -mieee
flag when GHC
calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order.
Is this when running gcc on the Alpha, or on the
With the wrapper everything was fine here on the host side.
I then had to do the I_ - int stg_exit thing as committed to CVS for
IA64, and also change machine/{pal,fpu}.h to asm/{pal,fpu}.h in
ghc/rts/Adjuster.c and ghc/rts/Signals.c. (I'd already applied the
MBLOCK hack from x86-64). The
but
--
--
===fptools== Recursively making `boot' in base haskell98
network haskell-src unix ...
PWD = /scratch/users/eden/ghc-6.0.1/libraries
--
--
igloo:
With the wrapper everything was fine here on the host side.
I then had to do the I_ - int stg_exit thing as committed to CVS for
IA64, and also change machine/{pal,fpu}.h to asm/{pal,fpu}.h in
ghc/rts/Adjuster.c and ghc/rts/Signals.c. (I'd already applied the
MBLOCK hack from
On Fri, Sep 12, 2003 at 10:59:05AM +0100, Simon Marlow wrote:
Looks like you need some mangler support now...
Unfortunately neither the mangler nor alpha are exactly strong points of
mine.
I'm also somewhat confused by how
die Prologue junk?: $p\n if $p =~ /^\s+[^\s\.]/;
[...]
# On Alphas,
dons:
I got another (loopy) compile on alpha-dec-osf3 that went through
cleanly, with the following fixes:
[..]
And then everything went though, to the re-configure part of
hc-build, but the ghc-inplace seems to go into an infinite loop
on invocation. It won't produce output even with
Things aren't so easy with alpha as gcc rejects the -mieee
flag when GHC
calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order.
Is this when running gcc on the Alpha, or on the bootstrapping host?
Cheers,
Simon
___
simonmar:
Things aren't so easy with alpha as gcc rejects the -mieee
flag when GHC
calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order.
Is this when running gcc on the Alpha, or on the bootstrapping host?
alpha-dec-osf3 bootstrapped quite cleanly today. Using the
On Thu, Sep 11, 2003 at 02:21:29PM +1000, Matt Chapman wrote:
On Thu, Sep 11, 2003 at 02:06:57AM +0100, Ian Lynagh wrote:
Bootstrapping IA64 from x86 (with numerous patches from CVS) looks
like it is working fine, although I am getting
ghc-6.0.1(9371): unaligned access to
On Thu, Sep 11, 2003 at 09:52:07AM +0100, Simon Marlow wrote:
Things aren't so easy with alpha as gcc rejects the -mieee
flag when GHC
calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order.
Is this when running gcc on the Alpha, or on the bootstrapping host?
The
The bootstrapping host.
That is expected, then. I've mentioned before that trying to build the
HC files on the bootstrapping host might not work, because these files
are meant to be built on the target. The same goes for the invocation
of gcc itself: it is using flags designed for use on the
$ uname -msr
OpenBSD 3.3 sparc
$ cat test.hs
import System.Info
main = print System.Info.arch print System.Info.os
$
/usr/obj/ports/ghc-6.0.1/ghc-6.0.1/ghc/compiler/ghc-inplace test.hs
$ ./a.out
sparc
openbsd
Congrats :-) Would you like to add this port
On Wed, Sep 10, 2003 at 08:31:40AM +1000, Donald Bruce Stewart wrote:
Following the new guide, and the new distrib/hc-build, with the
fix to .hc file generation on the host that Simon sorted out yesterday.
This generated a working sparc binary. That compiler in turn is
recompiling the
igloo:
On Wed, Sep 10, 2003 at 08:31:40AM +1000, Donald Bruce Stewart wrote:
Following the new guide, and the new distrib/hc-build, with the
fix to .hc file generation on the host that Simon sorted out yesterday.
This generated a working sparc binary. That compiler in turn is
On Thu, Sep 11, 2003 at 02:06:57AM +0100, Ian Lynagh wrote:
Bootstrapping IA64 from x86 (with numerous patches from CVS) looks like
it is working fine, although I am getting
ghc-6.0.1(9371): unaligned access to 0x41e6177a, ip=0x40dd46c1
when compiling even hello world
simonmar:
On Sat, 6 Sep 2003, Donald Bruce Stewart wrote:
simonmar:
I was a bit too soon reporting the sparc-sun-solaris2, two
attempts have died with stg_ap_v_ret. Same result
sparc-*-openbsd.
Also with mips-sgi-irix65 . An attempt died with stg_ap_v_ret .
I'm
On Wed, Sep 10, 2003 at 07:57:33AM +1000, Donald Bruce Stewart wrote:
Looks like that was it!
I've just built a working unreg compiler on
sparc-unknown-openbsd, which I have not been able to do previously.
Is that using the instructions in the users guide and without having to
copy .hi
igloo:
On Wed, Sep 10, 2003 at 07:57:33AM +1000, Donald Bruce Stewart wrote:
Looks like that was it!
I've just built a working unreg compiler on
sparc-unknown-openbsd, which I have not been able to do previously.
Is that using the instructions in the users guide and without having
dons:
simonmar:
Aha! I *think* I've figured out what's going wrong.
The stg_ap_v_ret failure is caused by info tables being generated for
the wrong endianness. This isn't supposed to happen, because we should
be cross-compiling for the correct endianness, but I'm guessing that the
30 matches
Mail list logo
