[GHC] #8965: bootstrapping failure on Linux/ppc64el

[GHC]

#8965: bootstrapping failure on Linux/ppc64el
--------------------------------------------+-----------------------------
        Reporter:  cjwatson                 |            Owner:
            Type:  bug                      |           Status:  patch
        Priority:  normal                   |        Milestone:  7.8.3
       Component:  Compiler                 |          Version:  7.8.1-rc2
      Resolution:                           |         Keywords:
Operating System:  Linux                    |     Architecture:  powerpc64
 Type of failure:  GHC doesn't work at all  |       Difficulty:  Unknown
       Test Case:                           |       Blocked By:
        Blocking:                           |  Related Tickets:
--------------------------------------------+-----------------------------

Comment (by cjwatson):

 Replying to [comment:2 ezyang]:
 > Wow, nice catch! Are there any other places where we are improperly
 declaring null argument lists?

 I wouldn't like to categorically say no, because I don't know GHC anywhere
 near well enough for that. :-)  The best I can do is to say that nothing
 else impeded the bootstrap on this architecture ...

 I did find a couple of related problems:

 * While using an empty parameter list is better than a wrong parameter
 list, it's technically an obsolescent feature in C11, and the proper fix
 is to generate a correct prototype.  The compiler hacking for this is
 beyond me.

 * There are a couple of uses of (at least) `debugBelch` in `rts/*.cmm`,
 which have a similar problem: if you try to run the compiler on ppc64el
 with `-Da`, for instance, it crashes because the call to `debugBelch` in
 `stg_ap_0_fast` corrupts the caller's stack, as it didn't realise it was
 calling a varargs function and so didn't allocate enough stack space.
 There's a `debugBelch2` workaround in `libraries/base` for the same kind
 of problem; the RTS probably needs to do something similar.  Generating
 correct prototypes in the compiler would fix this problem too.

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