1. 25 Apr, 2017 2 commits
  2. 23 Apr, 2017 1 commit
  3. 17 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      aclocal.m4: respect user's --with-ar= choice · 79848f18
      Sergei Trofimovich authored
      
      
      'FP_PROG_AR' macro has a minor bug: it ignores
      already existing value stored in '$fp_prog_ar'.
      
      I've noticed it when tried to built UNREG ghc using thin LTO:
      
        $ ./configure --enable-unregisterised \
                      --with-nm=gcc-nm \
                      --with-ar=gcc-ar \
                      --with-ranlib=gcc-ranlib \
      
      ./configure refused to use 'gcc-ar' (LTO-aware variant of 'ar')
      and kept using 'ar'.
      
      '$fp_prog_ar' is initialized (in a complex manner) in 'configure.ac' as:
      
          FP_ARG_WITH_PATH_GNU_PROG([AR], [ar], [ar])
          ArCmd="$AR"
          fp_prog_ar="$AR"
          AC_SUBST([ArCmd])
      
      The change keeps that value.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      79848f18
  4. 29 Mar, 2017 2 commits
  5. 23 Jan, 2017 1 commit
  6. 20 Jan, 2017 1 commit
  7. 17 Dec, 2016 1 commit
  8. 14 Nov, 2016 1 commit
  9. 11 Nov, 2016 2 commits
    • Ben Gamari's avatar
      Pass -no-pie to GCC · d421a7e2
      Ben Gamari authored
      Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be
      default in their GCC packaging. This breaks our abuse of GCC as a linker
      which requires that we pass -Wl,-r, which is incompatible with
      PIE (since the former implies that we are generating a relocatable
      object file and the latter an executable).
      
      This is a second attempt at D2691. This attempt constrasts with D2691 in that
      it preserves the "does gcc support -no-pie" flag in settings, allowing this to
      be reconfigured by `configure` during installation of a binary distribution.
      Thanks for @rwbarton for drawing attention to this issue.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, erikd
      
      Reviewed By: erikd
      
      Subscribers: thomie, rwbarton, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2693
      
      GHC Trac Issues: #12759
      d421a7e2
    • Ben Gamari's avatar
      Revert "Pass -no-pie to GCC" · 60bb9d1c
      Ben Gamari authored
      This reverts commit bae4a55b.
      
      This will be superceded by D2693.
      60bb9d1c
  10. 10 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Pass -no-pie to GCC · bae4a55b
      Ben Gamari authored
      Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be
      default in their GCC packaging. This breaks our abuse of GCC as a linker
      which requires that we pass -Wl,-r, which is incompatible with
      PIE (since the former implies that we are generating a relocatable
      object file and the latter an executable).
      
      Test Plan: Validate
      
      Reviewers: hvr, austin
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2691
      
      GHC Trac Issues: #12759
      bae4a55b
  11. 22 Aug, 2016 1 commit
    • kgardas's avatar
      pass -z wxneeded or -Wl,-zwxneeded for linking on OpenBSD · f9aa996f
      kgardas authored
      Summary:
      This patch fixes issue with abort in GHCi on OpenBSD current
      as of Aug 12 2016. The OpenBSD is more and more strict about usage
      of writable and executable memory. Programs/applications which
      requires such functionality need to be linked with -z wxneeded linker
      flag and need to be run from the file-system mounted with wxallowed
      mount option. If either of those options in not met, then problematic
      program/application usually fail on some mmap/mprotect call which fail.
      
      Reviewers: bgamari, austin, hvr
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2454
      f9aa996f
  12. 05 Jul, 2016 1 commit
    • Moritz Angermann's avatar
      Adds x86_64-apple-darwin14 target. · f560a03c
      Moritz Angermann authored
      x86_64-apple-darwin14, is the target for the 64bit simulator.
      Ideally, we'd have (i386|armv7|arm64|x64_86)-apple-ios, yet,
      many #ifdefs depend on `darwin`, notably libffi. Hence, this only adds
      x86_64-apple-darwin14 as a target. This also updates the comment to
      add the `-S` flag, and dump the output to stdout; and adjusts the
      `datalayout` and `triple` values, as obtained through the method
      mentioned in the comment.
      
      Reviewers: hvr, erikd, austin, bgamari, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2378
      f560a03c
  13. 09 Jun, 2016 1 commit
    • Tamar Christina's avatar
      Remove special casing of Windows in generic files · 48385cb2
      Tamar Christina authored
      Summary:
      Remove some Windows specific code from the .m4 files
      and have configure figure it out.
      
      Unfortunately touchy can't be removed since there
      is no mingw build of coreutils. Only msys builds
      which would give us a dependency on the msys runtime.
      
      Reviewers: hvr, austin, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: thomie, erikd, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2248
      48385cb2
  14. 24 May, 2016 1 commit
  15. 18 Apr, 2016 1 commit
  16. 16 Apr, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Rework CC/CC_STAGE0 handling in `configure.ac` · 865602e0
      Herbert Valerio Riedel authored
      Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
      scheme use the `CC=...` style scheme.
      
      The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
      stage{1,2,3}, while having a separate _STAGE0 set of env-vars
      denote the bootstrap-toolchain flags/programs.
      
      This should be simpler, less confusing, and somewhat more in line with
      Autoconf's idioms (allowing us to reuse more of Autoconf rather than
      (re)inventing our own confusing non-standard m4 macros to do stuff that
      Autoconf could almost do already for us)
      
      Morever, expose CC_STAGE0 as a so-called "precious" variable.
      
      So now we can better control which bootstrapping gcc is used
      (by default the one used by the stage0 ghc, unless CC_STAGE0 is
      overriden)
      
      ```
      Some influential environment variables:
        CC_STAGE0   C compiler command (bootstrap)
        CC          C compiler command
        CFLAGS      C compiler flags
        ...
      
      Use these variables to override the choices made by `configure' or to
      help it...
      865602e0
  17. 28 Mar, 2016 4 commits
    • Herbert Valerio Riedel's avatar
      Autoconf: detect and set CFLAGS/CPPFLAGS needed for C99 mode · afc48f89
      Herbert Valerio Riedel authored
      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
      afc48f89
    • Herbert Valerio Riedel's avatar
      Drop Xcode 4.1 hack and fix ignored CC var issue · ffc802e8
      Herbert Valerio Riedel authored
      Xcode 4.1 was released back in 2011 for Mac OSX 10.6/10.7.
      However, OSX 10.7 reached EOL sometime around the end of 2014.
      So this `--with-gcc-4.2` hack shouldn't be needed anymore.
      
      Moreover, this patch changes ./configure to honor the CC env-var
      again (and thus fix #11231) while giving `--with-gcc=...` a higher
      priority over `CC=...`.
      
      So the following 3 invocations are equivalent now:
      
        CC=... ./configure
        ./configure CC=...
        ./configure --with-gcc=...
      
      Since `--with-{gcc,clang}=...` is a misnomer (as is made apparent by
      `--with-gcc=clang` or `--with-clang=gcc`), this would give us a neutral
      and idiomatic way to tell ./configure which C compiler to use.
      
      Moreover, `./configure --help` says at the end of its output:
      
        Some influential environment variables:
          CC		C compiler command
          CFLAGS	C compiler flags
          LDFLAGS	linker flags, e.g. -L<lib dir> if you have libraries in a
      		nonstandard directory <lib dir>
          LIBS	libraries to pass to the linker, e.g. -l<library>
          CPPFLAGS	(Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
      		you have headers in a nonstandard directory <include dir>
          CPP		C preprocessor
      
        Use these variables to override the choices made by `configure' or to help
        it to find libraries and programs with nonstandard names/locations.
      
      Consequently, by honoring CC=... (rather than ignoring it) we increase
      consistency and reduce user confusion. Ideally, CC=... would become the
      recommended way to set the C compiler, and `--with-{clang,gcc}=...`
      would be demoted to legacy aliases.
      
      Reviewed By: erikd, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D2046
      ffc802e8
    • Herbert Valerio Riedel's avatar
      Scrap DEC OSF/1 support · f911358b
      Herbert Valerio Riedel authored
      DEC OSF/1 (aka Tru64 UNIX) has been discontinued a few years ago already[1].
      
      This removes the undoubtedly bitrotten support for `OSOsf3 :: OS` from GHC's
      code-base.
      
      Support for `ArchAlpha :: Arch` may be removed at some later point, as there
      may still be users out there running a more or less recent Linux/alpha
      distribution on their more-than-a-decade old Alpha hardware...
      
       [1]: https://en.wikipedia.org/wiki/Tru64_UNIX
      f911358b
    • Herbert Valerio Riedel's avatar
      Scrap IRIX support · 0bca3f3a
      Herbert Valerio Riedel authored
      Long time ago, IRIX was way ahead of its time in the last century with
      its SMP capabilities of scaling up to 1024 processors and other features
      such as XFS or OpenGL that originated in IRIX and live on to this day in
      other operating systems.
      
      However, IRIX's last software update was in 2006 and support ended
      around 2013 according to [1], so it's considered an extinct platform by
      now. So this commit message is effectively an obituary for GHC's IRIX
      support.
      
      R.I.P. IRIX
      
       [1]: https://en.wikipedia.org/wiki/IRIX
      0bca3f3a
  18. 24 Mar, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Add NCG support for AIX/ppc32 · df26b955
      Herbert Valerio Riedel authored
      This extends the previous work to revive the unregisterised GHC build
      for AIX/ppc32. Strictly speaking, AIX runs on POWER4 (and later)
      hardware, but the PPC32 instructions implemented in the PPC NCG
      represent a compatible subset of the POWER4 ISA.
      
      IBM AIX follows the PowerOpen ABI (and shares many similiarites with the
      Linux PPC64 ELF V1 NCG backend) but uses the rather limited XCOFF
      format (compared to ELF).
      
      This doesn't support dynamic libraries yet.
      
      A major limiting factor is that the AIX assembler does not support the
      `@ha`/`@l` relocation types nor the ha16()/lo16() functions Darwin's
      assembler supports. Therefore we need to avoid emitting those. In case
      of numeric literals we simply compute the functions ourselves, while for
      labels we have to use local TOCs and hope everything fits into a 16bit
      offset (for ppc32 this gives us at most 16384 entries per TOC section,
      which is enough to compile GHC).
      
      Another issue is that XCOFF doesn't seem to have a relocation type for...
      df26b955
  19. 25 Jan, 2016 1 commit
    • Ben Gamari's avatar
      Ensure that we don't produce code for pre-ARMv7 without barriers · 9fe7d20e
      Ben Gamari authored
      We are unable to produce load/store barriers for pre-ARMv7 targets.
      Phab:D894 added dummy cases to SMP.h for these barriers to prevent the
      build from failing under the assumption that there are no SMP-capable
      devices of this vintage. However, #10433 points out that it is more
      correct to simply set NOSMP for such targets.
      
      Tested By: rwbarton
      
      Test Plan: Validate
      
      Reviewers: erikd, rwbarton, austin
      
      Reviewed By: rwbarton
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1704
      
      GHC Trac Issues: #10433
      9fe7d20e
  20. 08 Jan, 2016 1 commit
    • thomie's avatar
      Build system: fix `pwd` issues on Windows · f7b45c31
      thomie authored
      Some parts of the build system require that paths are what msys2 calls
      "mixed style":
        * forwards slashes
        * absolute paths starting with a drive letter followed by a colon
          (e.g. "C:")
      
      The removal of ghc-pwd in 4c56ad36 changed $(TOP) from mixed style to
      unix style, resulting in a broken Windows build for some.
      
      Differential Revision: https://phabricator.haskell.org/D1752
      f7b45c31
  21. 04 Jan, 2016 1 commit
    • thomie's avatar
      Build system: delete ghc-pwd · 4c56ad36
      thomie authored
      On Windows, with msys2, `pwd` works (as can be seen by the use of `pwd`
      that slipped into the validate script), so there is really no need for
      `ghc-pwd` anymore.
      
      Test Plan: try it
      
      Reviewers: austin, bgamari, Phyx
      
      Reviewed By: Phyx
      
      Subscribers: Phyx, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1731
      4c56ad36
  22. 28 Dec, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Make git-committer inferred version-date TZ-invariant · bab51097
      Herbert Valerio Riedel authored
      The existing code suffers from the issue of converting the
      committer date to localtime, thereby resulting in varying
      inferred dates for the same commit-hash depending on the currently
      set local timezone.
      
      In order to have a universally unique mapping between commit-hashes and
      their snapshot-version-date it's better to convert to the date expressed
      in a fixed timezone like e.g. UTC.
      
      Sadly, `git` doesn't seem to provide a way to directly format dates the
      way we need it, so we shell out to `perl` for this.
      
      Reviewers: austin, thomie, erikd, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1711
      bab51097
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  23. 20 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      aclocal.m4: Fix llc/opt detection code · f7bd37ed
      Herbert Valerio Riedel authored
      Currently if llc/opt is missing, we get
      
        checking for llc-3.7... no
        checking for llc... no
        checking  is version 3.7... ./configure[7417]: --version:  not found
        no
        checking for opt-3.7... no
        checking for opt... no
        checking  is version 3.7... ./configure[7664]: --version:  not found
        no
        checking for llc... no
        checking for opt... no
      
      With this fix, the version is queried iff `llc`/`opt` has been detected
      at all, thereby avoiding the disturbing `--version: not found` error
      output.
      
      Reviewed By: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1674
      f7bd37ed
  24. 19 Dec, 2015 1 commit
  25. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  26. 13 Dec, 2015 1 commit
  27. 21 Nov, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Suppress conflicting types for builtins warnings · 192dd068
      Herbert Valerio Riedel authored
      GCC 4.0 and later warn about type-conflicting prototypes for built-in
      functions such as `strlen`. This is a problem for the via-c backend as
      it generates code such as
      
        typedef void *(*(*StgFunPtr)(void))(void);
        extern StgFunPtr strlen();
      
      However, by using the `-fno-builtin` flag, GCC is told not to try to
      auto-detect such built-in functions and instead treat them as ordinary
      external functions.  This also suppresses this warning.
      
      This address #7660
      
      Test Plan: IIAM
      
      Reviewers: bgamari, austin
      
      Reviewed By: austin
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1506
      
      GHC Trac Issues: #7660
      192dd068
  28. 20 Nov, 2015 1 commit
  29. 19 Nov, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Set AIX specific CFLAGS flags · 75036aac
      Herbert Valerio Riedel authored
      First of all, we need to use -mminimal-toc on IBM AIX
      
      AIX's XCOFF is limited to 16k entries in its TOC for 32bit compilation,
      which quickly overflows with GHC's code generation.
      
      Otoh, the Parser.hs module contains more entries than fit into a
      minimal-toc, so we need to switch back to `-mfull-toc` for that single
      module again.
      
      Then, we also need to set the `THREAD_SAFE` CPP #define in order to
      unlock the thread-safe `errno` which is essential for the threaded
      runtime.
      
      Depends on D1501
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1502
      75036aac
    • Herbert Valerio Riedel's avatar
      Make GHC aware of OSAIX and AixLD · c5d8162d
      Herbert Valerio Riedel authored
      GHC needs to be aware of targetting AIX because
      AIX requires some special handling for the toolchain
      (similiar to Solaris)
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1501
      c5d8162d
  30. 17 Nov, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make `timer_create(CLOCK_REALTIME)` autoconf test more reliable · 8ad9e74f
      Herbert Valerio Riedel authored
      I've noticed that on a platform with a coarse timer/scheduling
      granularity of 10ms this autoconf tests fails to detect a working
      `timer_create(CLOCK_REALTIME)`.
      
      On AIX, this effectively means that intervals/timers are rounded up to
      multiples of 10ms, so a 13ms delay is effectively a 20ms delay.
      
      By using a 100ms timeout we are on the safe side.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1483
      8ad9e74f
  31. 22 Oct, 2015 1 commit
  32. 14 Oct, 2015 1 commit
    • Erik de Castro Lopo's avatar
      Fix GHCi on Arm (#10375). · 933adc0f
      Erik de Castro Lopo authored
      Arm has two instruction sets, Arm and Thumb, and an execution mode for each.
      Executing Arm code in Thumb mode or vice-versa will likely result in an
      Illegal instruction exception.
      
      Furthermore, Haskell code compiled via LLVM was generating Arm instructions
      while C code compiled via GCC was generating Thumb code by default. When
      these two object code types were being linked by the system linker, all was
      fine, because the system linker knows how to jump and call from one
      instruction set to the other.
      
      The first problem was with GHCi's object code loader which did not know
      about Thumb vs Arm. When loading an object file `StgCRun` would jump
      into the loaded object which could change the mode causing a crash after
      it returned. This was fixed by forcing all C code to generate Arm
      instructions by passing `-marm` to GCC.
      
      The second problem was the `mkJumpToAddr` function which was generating
      Thumb instructions. Changing that to generate Arm instructions instead
      results in a working GHCi on Arm.
      
      Test Plan: validate on x86_64 and arm
      
      Reviewers: bgamari, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1323
      
      GHC Trac Issues: #10375
      933adc0f