[GHC] #7940: Building GHC 7.7.20130526 (perf) for Windows x86_64 fails with Cmm lint error

[GHC]

#7940: Building GHC 7.7.20130526 (perf) for Windows x86_64 fails with Cmm lint
error
-------------------------------+--------------------------------------------
    Reporter:  awson           |       Owner:                     
        Type:  bug             |      Status:  new                
    Priority:  normal          |   Milestone:                     
   Component:  Compiler        |     Version:  7.7                
    Keywords:                  |          Os:  Windows            
Architecture:  x86_64 (amd64)  |     Failure:  Building GHC failed
  Difficulty:  Unknown         |    Testcase:                     
   Blockedby:                  |    Blocking:                     
     Related:                  |  
-------------------------------+--------------------------------------------

Comment(by thoughtpolice):

 So, just so others can take note before I mislead myself, I believe the
 'root' of the problem is here in StgCmmTicky:

 {{{

 bumpTickyLitBy :: CmmLit -> Int -> FCode ()
 bumpTickyLitBy lhs n = do
   dflags <- getDynFlags
   -- All the ticky-ticky counters are declared "unsigned long" in C
   emit (addToMem (cLong dflags) (CmmLit lhs) n)

 bumpTickyLitByE :: CmmLit -> CmmExpr -> FCode ()
 bumpTickyLitByE lhs e = do
   dflags <- getDynFlags
   -- All the ticky-ticky counters are declared "unsigned long" in C
   emit (addToMemE (cLong dflags) (CmmLit lhs) e)

 }}}

 Essentially when the Cmm parser sees 'TICKY_ALLOC_PRIM` in PrimOps.cmm, it
 will bump several counters defined in the RTS. The type of those counters
 (in Cmm terms) is specified as 'cLong dflags' in the above code. But this
 is only coincidentally correct on the platforms we supported until now.

 Most unix machines follow the LP64 data model. So on 64 bit machines,
 'long' is 64 bit, and so are pointers. 'int' 32 bit. But Windows 64
 follows the LLP64 model: both 'long' AND 'int' are 32bit, while 'long
 long' and ptrs are 64 bit. That means on Win64, 'cLong dflags' will be 32,
 while on Unix it would be 64. So it is only coincidental that 'long' has
 aligned with the native word size, until now.

 The invocation that triggers this in PrimOps.cmm is:

 {{{
 stg_newByteArrayzh ( W_ n )
 {
     W_ words, payload_words;
     gcptr p;

     MAYBE_GC_N(stg_newByteArrayzh, n);

     payload_words = ROUNDUP_BYTES_TO_WDS(n);
     words = BYTES_TO_WDS(SIZEOF_StgArrWords) + payload_words;
     ("ptr" p) = ccall allocate(MyCapability() "ptr",words);
     TICK_ALLOC_PRIM(SIZEOF_StgArrWords,WDS(payload_words),0); // <-----
 problematic
     SET_HDR(p, stg_ARR_WORDS_info, CCCS);
     StgArrWords_bytes(p) = n;
     return (p);
 }

 }}}

 where SIZEOF_StgArrWords comes down to the literal '8 + 8' via CPP, which
 I imagine is inferred as a word-sized (64bit) quantity. Thus the type
 error occurs when addToMemE elaborates the LHS as 32bit thanks to cLong.

 Also, digging into includes/stg/Types.h, we see:

 {{{

 #if SIZEOF_VOID_P == 8
 typedef StgInt64           StgInt;
 typedef StgWord64          StgWord;
 typedef StgInt32           StgHalfInt;
 typedef StgWord32          StgHalfWord;
 #define FMT_Word     FMT_Word64
 #define FMT_HexWord  FMT_HexWord64
 #define FMT_Int      FMT_Int64
 #else
 ...
 }}}

 and in includes/stg/Ticky.h:

 {{{

 EXTERN StgInt ALLOC_PRIM_ctr INIT(0);
 EXTERN StgInt ALLOC_PRIM_adm INIT(0);
 EXTERN StgInt ALLOC_PRIM_gds INIT(0);
 EXTERN StgInt ALLOC_PRIM_slp INIT(0);

 }}}

 So in any case, the Ticky code comments are certainly wrong now: the
 counters are not of 'unsigned long.' So I think the correct thing is that
 ticky counters are all word sized. But looking at the code some more, this
 cLong business seems to be baked into the ticky stuff a bit.

 I'm copying a CD (slowly) to make a build machine, but perhaps someone can
 build on my suspicions? Thoughts? I believe Nicholas Frisby was around
 this area recently, so perhaps he has input.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7940#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler