Sven writes:
> Compiling the latest and greatest GHC-4.01 from source fails on HPs
> (and probably on all other architectures with ALIGNMENT_DOUBLE >
> ALIGNMENT_LONG):
>
> ...
>
> --------------------------------------------------------------
> ----------
> ==fptools== make all --no-print-directory -r;
> in
> /mnt/tetiaroa2/sven/fptools-011298-hppa1.1-hp-hpux10/ghc/includes
>
> --------------------------------------------------------------
> ----------
> gcc -c mkNativeHdr.c -o mkNativeHdr.o
> In file included from Stg.h:89,
> from mkNativeHdr.c:10:
> StgMacros.h:502: redefinition of `struct __ud'
Thanks for the report. The only architecture we tested on with
ALIGNMENT_DOUBLE > ALIGMENT_LONG is Sparc, which has its own inline assembly
code for shifting doubles around.
Just out of interest, do you know whether doubles *must* be aligned on an
8-byte boundary on HP, or is it just a performance thing?
Patch follows:
diff -c -r1.1.2.17 StgMacros.h
*** StgMacros.h 1998/11/25 15:00:57 1.1.2.17
--- StgMacros.h 1998/12/02 09:22:09
***************
*** 458,469 ****
static inline void ASSIGN_DBL (W_ [], StgDouble);
static inline StgDouble PK_DBL (W_ []);
! typedef struct __ud
{ StgWord dhi;
StgWord dlo;
} unpacked_double;
! typedef union __dt
{ StgDouble d;
unpacked_double du;
} double_thing;
--- 458,469 ----
static inline void ASSIGN_DBL (W_ [], StgDouble);
static inline StgDouble PK_DBL (W_ []);
! typedef struct
{ StgWord dhi;
StgWord dlo;
} unpacked_double;
! typedef union
{ StgDouble d;
unpacked_double du;
} double_thing;
***************
*** 498,514 ****
#ifdef SUPPORT_LONG_LONGS
! typedef struct __ud
{ StgWord dhi;
StgWord dlo;
} unpacked_double_word;
! typedef union __it
{ StgInt64 i;
unpacked_double_word iu;
} int64_thing;
! typedef union __wt
{ StgNat64 w;
unpacked_double_word wu;
} word64_thing;
--- 498,514 ----
#ifdef SUPPORT_LONG_LONGS
! typedef struct
{ StgWord dhi;
StgWord dlo;
} unpacked_double_word;
! typedef union
{ StgInt64 i;
unpacked_double_word iu;
} int64_thing;
! typedef union
{ StgNat64 w;
unpacked_double_word wu;
} word64_thing;
> Another thing: What's the route to go if one wants to stay on the
> bleeding edge? Diff-ing the ghc-4.01 sources, ghc-current, and the
> new-rts branch from CVS yields quite some difference, so I'm getting
> a little bit confused...
I'm just about to spam the main trunk with 4.01. The story at the moment
is:
- GHC 3.03 is tagged as ghc-3-03
- The GHC 3 line has been branched (ghc-3-branch)
- The main trunk will be ghc-4 in a day or two,
- GHC 4.01 will be tagged as ghc-4-01
GHC current at the moment is 4.01, because we use the nightly builds to
generate the tar files. It will continue along the 4.xx line in the future.
I really must describe this stuff in the CVS web page.
Cheers,
Simon
--
Simon Marlow
Microsoft Research Ltd., Cambridge, U.K.
