This is the first phase of addressing #11757 which aims to make C99
support a base-line requirement for GHC and clean up the code-base to
use C99 facilities when sensible.

This patch exploits the logic/heuristic used by `AC_PROG_CC_C99` to
determine the flags needed in case the C compiler isn't able to compile
C99 code in its current mode. We can't use `AC_PROG_CC_C99` directly
though because GHC's build-system expects CC to contain a filename
without any flags, while `AC_PROG_CC_C99` would e.g. result in
`CC="gcc -std=gnu99"`. Morever, we support different `CC`s for
stage0/1/2, so we need a version of `AC_PROG_CC_C99` for which we can
specify the `CC`/`CFLAGS` variables to operate on. This is what
`FP_SET_CFLAGS_C99` does.

Note that Clang has been defaulting to C99+ for a long time, while GCC 5
defaults to C99+ as well. So this has mostly an affect on older GCCs
versions prior to 5.0 and possibly compilers other than GCC/Clang (which
are not officially supported for building GHC anyway).

Reviewers: kgardas, erikd, bgamari, austin

Reviewed By: erikd

Differential Revision: https://phabricator.haskell.org/D2045

At some point there may have been a reason for the
`INLINE_ME` macro, but not anymore...

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D2041

Turns out the current macros for gnu90-style inline
semantics stopped working with GCC 5
(and possibly also with Apple's GCC) which switched on
`__GNUC_STDC_INLINE__` by default falling back to using the
suboptimal `static inline` mode.

However, C99 supports an equivalent (as far as our
use-case is concerned) `extern inline` mode.

See also
http://www.greenend.org.uk/rjk/tech/inline.html
for a write-up of gnu90 vs C99 semantics.

This patch also removes the MSVC case as VS2015 is supposed
to finally catch up to C99 (and C11), so we don't need any
special care for MSVC anymore.

Reviewed By: erikd, austin

Differential Revision: https://phabricator.haskell.org/D2039

Before the patch both Cmm and C symbols were declared
with 'EF_' macro:

    #define EF_(f)    extern StgFunPtr f()

but for Cmm symbols we know exact prototypes.

The patch splits there prototypes in to:

    #define EFF_(f)   void f() /* See Note [External function prototypes] */
    #define EF_(f)    StgFunPtr f(void)

Cmm functions are 'EF_' (External Functions),
C functions are 'EFF_' (External Foreign Functions).

While at it changed external C function prototype
to return 'void' to workaround ghc bug on m68k.
Described in detail in Trac #11395.

This makes simple tests work on m68k-linux target!

Thanks to Michael Karcher for awesome analysis
happening in Trac #11395.

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Test Plan: ran "hello world" on m68k successfully

Reviewers: simonmar, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1975

GHC Trac Issues: #11395

As otherwise <math.h> includes <stdlib.h> which breaks compilation
of .hc files

_BSD_SOURCE we are using for 'gamma()' and friends
was deprecated in glibc-2.20 in favour of '_DEFAULT_SOURCE'.

gcc says:

    In file included from /usr/include/math.h:26:0:
        0,
                         from includes/Stg.h:69,
                         from /tmp/ghc19488_0/ghc19488_2.hc:3:

    /usr/include/features.h:148:3:
         warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
         # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
           ^

Patch fixes testsuite failures on UNREG
(stderr are not cluttered by warnings anymore).

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Summary:
Commit reverts never used addition in cbd29e0a

I think it might make sense to take advantage of TSO/RMO/PSO models
tome day. But it's highly architecture/model-dependent thus it better
be implemented in per-arch Native CodeGen.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: build-tested on UNREG-amd64

Reviewers: simonmar, austin

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D186

No need to emit (now empty) those special markers.
Markers were needed only in registerised -fvia-C mode.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Signed-off-by: Austin Seipp <austin@well-typed.com>

GHC's generated C code uses dummy prototypes for foreign imports.  At the
moment these all claim to be (void), i.e. functions of zero arguments.  On
most platforms this doesn't matter very much: calls to these functions put
the parameters in the usual places anyway, and (with the exception of
varargs) things just work.

However, the ELFv2 ABI on ppc64 optimises stack allocation
(http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html

): a call to a
function that has a prototype, is not varargs, and receives all parameters
in registers rather than on the stack does not require the caller to
allocate an argument save area.  The incorrect prototypes cause GCC to
believe that all functions declared this way can be called without an
argument save area, but if the callee has sufficiently many arguments then
it will expect that area to be present, and will thus corrupt the caller's
stack.  This happens in particular with calls to runInteractiveProcess in
libraries/process/cbits/runProcess.c.

The simplest fix appears to be to declare these external functions with an
unspecified argument list rather than a void argument list.  This is no
worse for platforms that don't care either way, and allows a successful
bootstrap of GHC 7.8 on little-endian Linux ppc64 (which uses the ELFv2
ABI).

Fixes #8965

Signed-off-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Austin Seipp <austin@well-typed.com>

This fixes most of implicit function declarations emitted
C codegen in UNREG mode. Found by adding the following to
mk/build.mk:

    SRC_CC_OPTS += -Werror=implicit-function-declaration
    SRC_HC_OPTS += -optc-Werror=implicit-function-declaration

Issue #8748

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Austin Seipp <austin@well-typed.com>

it was only needed for registerised compilation.

No functional differences yet

We were comparing ALIGNMENT_DOUBLE to ALIGNMENT_LONG, but really
we cared about W_ values, and sizeof(long) /= sizeof(void *) on Win64

LLVM does not support the __thread attribute for thread
local storage and may generate incorrect code for global
register variables. We want to allow building the runtime with
LLVM-based compilers such as llvm-gcc and clang,
particularly for MacOS.

This patch changes the gct variable used by the garbage
collector to use pthread_getspecific() for thread local
storage when an llvm based compiler is used to build the
runtime.

Stephen Blackheath authored 13 years ago and chak@cse.unsw.edu.au. committed 13 years ago

When the bootstrap compiler does not include this patch, you must add this line
to mk/build.mk, otherwise the ARM architecture cannot be detected due to a
-undef option given to the C pre-processor.
SRC_HC_OPTS = -pgmP 'gcc -E -traditional'

I've updated the wiki page about the RTS headers
  http://hackage.haskell.org/trac/ghc/wiki/Commentary/SourceTree/Includes
to reflect the new layout and explain some of the rationale.  All the
header files now point to this page.

The first phase of this tidyup is focussed on the header files, and in
particular making sure we are exposinng publicly exactly what we need
to, and no more.

 - Rts.h now includes everything that the RTS exposes publicly,
   rather than a random subset of it.

 - Most of the public header files have moved into subdirectories, and
   many of them have been renamed.  But clients should not need to
   include any of the other headers directly, just #include the main
   public headers: Rts.h, HsFFI.h, RtsAPI.h.

 - All the headers needed for via-C compilation have moved into the
   stg subdirectory, which is self-contained.  Most of the headers for
   the rest of the RTS APIs have moved into the rts subdirectory.

 - I left MachDeps.h where it is, because it is so widely used in
   Haskell code.
 
 - I left a deprecated stub for RtsFlags.h in place.  The flag
   structures are now exposed by Rts.h.

 - Various internal APIs are no longer exposed by public header files.

 - Various bits of dead code and declarations have been removed

 - More gcc warnings are turned on, and the RTS code is more
   warning-clean.

 - More source files #include "PosixSource.h", and hence only use
   standard POSIX (1003.1c-1995) interfaces.

There is a lot more tidying up still to do, this is just the first
pass.  I also intend to standardise the names for external RTS APIs
(e.g use the rts_ prefix consistently), and declare the internal APIs
as hidden for shared libraries.

This means that, on Linux, we get functions like gamma defined when we
#include math.h

Fixes crashes on Windows and Sparc

It's no longer needed, as base no longer #includes it

gcc has changed the meaning of "extern inline" when certain flags are
on (e.g. --std=gnu99), and this broke our use of it in the header
files.

This means S_ISSOCK gets defined on Linux

gcc 4.3 emits warnings for static inline functions that its heuristics
decided not to inline.  The workaround is to either mark appropriate
functions as "hot" (a new attribute in gcc 4.3), or sometimes to use
"extern inline" instead.

With this fix I can validate with gcc 4.3 on Fedora 9.

Include TickyCounters.h in Stg.h if we are doing Ticky Ticky.

This has several advantages:

 - -fvia-C is consistent with -fasm with respect to FFI declarations:
   both bind to the ABI, not the API.

 - foreign calls can now be inlined freely across module boundaries, since
   a header file is not required when compiling the call.

 - bootstrapping via C will be more reliable, because this difference
   in behavour between the two backends has been removed.

There is one disadvantage:

 - we get no checking by the C compiler that the FFI declaration
   is correct.

So now, the c-includes field in a .cabal file is always ignored by
GHC, as are header files specified in an FFI declaration.  This was
previously the case only for -fasm compilations, now it is also the
case for -fvia-C too.

In preparation for parallel GC, split up the monolithic GC.c file into
smaller parts.  Also in this patch (and difficult to separate,
unfortunatley):
  
  - Don't include Stable.h in Rts.h, instead just include it where
    necessary.
  
  - consistently use STATIC_INLINE in source files, and INLINE_HEADER
    in header files.  STATIC_INLINE is now turned off when DEBUG is on,
    to make debugging easier.
  
  - The GC no longer takes the get_roots function as an argument.
    We weren't making use of this generalisation.

We were assuming we could multiply 2 32-bit numbers without overflowing
a 64-bit number, but we can't as the top bit is the sign bit.