summaryrefslogtreecommitdiff
path: root/aclocal.m4
Commit message (Collapse)AuthorAgeFilesLines
* Clean up some shell code and M4 quotingDemi Obenour2017-01-201-7/+6
| | | | | | | | | | | | Test Plan: GHC CI Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2993
* fix OpenBSD linkage (wxneeded)Sergei Trofimovich2016-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | There is two types of options passed directly to 'ld' (and not to 'gcc' driver): - CONF_LD_LINKER_OPTS_STAGE$4 - EXTRA_LD_OPTS This changedoes two things: - split 'EXTRA_LD_OPTS' into two variables: - EXTRA_LD_OPTS (accepts 'gcc' wrapper options) - EXTRA_LD_LINKER_OPTS (accepts raw 'ld' options) - wraps all LD_LINKER options as '-Wl,' when passed to 'gcc' driver. Fixes https://phabricator.haskell.org/D2776 Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* configure: Verify that GCC recognizes -no-pie flagBen Gamari2016-11-141-1/+2
| | | | | | | | | | | | | | | | | It seems like GCC versions prior to 4.8 exit with code 0 when faced with an unrecognized flag. Silly compilers. Test Plan: Validate Reviewers: hvr, austin, ggreif Reviewed By: ggreif Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2707 GHC Trac Issues: #12759
* Pass -no-pie to GCCBen Gamari2016-11-111-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Pass -no-pie to GCC"Ben Gamari2016-11-101-18/+0
| | | | | | This reverts commit bae4a55b1fb403f610b4b55a1b6fb3f03e9c2026. This will be superceded by D2693.
* Pass -no-pie to GCCBen Gamari2016-11-101-0/+18
| | | | | | | | | | | | | | | | | | 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
* pass -z wxneeded or -Wl,-zwxneeded for linking on OpenBSDKarel Gardas2016-08-221-0/+7
| | | | | | | | | | | | | | | | | 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
* Adds x86_64-apple-darwin14 target.Moritz Angermann2016-07-051-2/+2
| | | | | | | | | | | | | | | | | | 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
* Remove special casing of Windows in generic filesTamar Christina2016-06-091-18/+31
| | | | | | | | | | | | | | | | | | 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
* Suppress the warning about __sync_fetch_and_nand (#9678)Thomas Miedema2016-05-241-0/+3
|
* Use stdint types to define SIZEOF and ALIGNMENT of INTx/WORDxTomas Carnecky2016-04-181-0/+10
| | | | | | | | | | | | | Saves us a CPP #if in MachDeps.h since we now can always rely on a 64-bit type being available. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2099
* Rework CC/CC_STAGE0 handling in `configure.ac`Herbert Valerio Riedel2016-04-161-35/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 to find libraries and programs with nonstandard names/locations. ``` Test Plan: I've tested that cross-compiling with `--target=powerpc-linux-gnu` still works, and tried a few variants of settting `CC=` and `CC_STAGE0=`; `./validate` passed as well Reviewers: erikd, austin, bgamari, simonmar Reviewed By: simonmar Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2078
* Autoconf: detect and set CFLAGS/CPPFLAGS needed for C99 modeHerbert Valerio Riedel2016-03-281-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Drop Xcode 4.1 hack and fix ignored CC var issueHerbert Valerio Riedel2016-03-281-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Scrap DEC OSF/1 supportHerbert Valerio Riedel2016-03-281-6/+2
| | | | | | | | | | | | | 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
* Scrap IRIX supportHerbert Valerio Riedel2016-03-281-2/+2
| | | | | | | | | | | | | | | | 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
* Add NCG support for AIX/ppc32Herbert Valerio Riedel2016-03-241-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 label-differences, and therefore the label-differences placed into tables-next-to-code can't be relocated, but the linker may rearrange different sections, so we need to place all read-only sections into the same `.text[PR]` section to workaround this. Finally, the PowerOpen ABI distinguishes between function-descriptors and actualy entry-point addresses. For AIX we need to be specific when emitting assembler code whether we want the address of the function descriptor `printf`) or for the entry-point (`.printf`). So we let the asm pretty-printer prefix a dot to all emitted subroutine calls (i.e. `BL`) on AIX only. For now, STG routines' entry-point labels are not prefixed by a label and don't have any associated function-descriptor. Reviewers: austin, trommler, erikd, bgamari Reviewed By: trommler, erikd, bgamari Differential Revision: https://phabricator.haskell.org/D2019
* Ensure that we don't produce code for pre-ARMv7 without barriersBen Gamari2016-01-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* Build system: fix `pwd` issues on WindowsThomas Miedema2016-01-081-1/+9
| | | | | | | | | | | | | 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 4c56ad3 changed $(TOP) from mixed style to unix style, resulting in a broken Windows build for some. Differential Revision: https://phabricator.haskell.org/D1752
* Build system: delete ghc-pwdThomas Miedema2016-01-041-25/+1
| | | | | | | | | | | | | | | | 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
* Make git-committer inferred version-date TZ-invariantHerbert Valerio Riedel2015-12-281-2/+3
| | | | | | | | | | | | | | | | | | 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
* Synchronise ghci-package version with ghc-packageHerbert Valerio Riedel2015-12-281-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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. 7b45c46cbabe1288ea87bd9b94c57e010ed17e60). 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
* aclocal.m4: Fix llc/opt detection codeHerbert Valerio Riedel2015-12-201-7/+9
| | | | | | | | | | | | | | | | | | | | | | | 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
* Add sparc64 a known architecture (Ticket #11211)John Paul Adrian Glaubitz2015-12-191-1/+4
| | | | | | | | | | | | Explicitly pass "--no-relax" on ArchSPARC64 (as ArchSPARC does) where gcc's default specs set "-mrelax" which conflicts with "-Wl,-r". Known architecture will also help extending sparc NCG support 64-bit ABI. Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* configure: add support for 'sh4' (Trac #11209)Sergei Trofimovich2015-12-131-1/+4
| | | | | | | | | | | Debian has Renesas SH4 (SuperH) port with a triplet: sh4-linux-gnu Patch by glaubitz adds 'sh4' CPU to recognize target as ArchUnknown. Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* Suppress conflicting types for builtins warningsHerbert Valerio Riedel2015-11-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Follow-up fixup to c5d8162d230c373Herbert Valerio Riedel2015-11-201-1/+1
| | | | | | This was missing from c5d8162d230c373b2b49ec94d3f9a027ff6e2dd6 / D1501 for some reason causing the AIX detection to result in `OSUnknown` rather than `OSAIX`.
* Set AIX specific CFLAGS flagsHerbert Valerio Riedel2015-11-191-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make GHC aware of OSAIX and AixLDHerbert Valerio Riedel2015-11-191-1/+7
| | | | | | | | | | | | | | 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
* Make `timer_create(CLOCK_REALTIME)` autoconf test more reliableHerbert Valerio Riedel2015-11-171-4/+5
| | | | | | | | | | | | | | | | | | | 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
* Quote GHC path in configure so we can deal with multiple spaces.Edward Z. Yang2015-10-221-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Fix GHCi on Arm (#10375).Erik de Castro Lopo2015-10-151-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move user's guide to ReStructuredTextBen Gamari2015-10-031-118/+0
|
* Build system: delete half-baked Cygwin supportThomas Miedema2015-08-201-38/+10
| | | | | | | | | | | | | | | | | | | We only support building GHC on mys2 nowadays, see https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. This (partially) reverts various commits from a few years ago, among which: * 5775d5142da227d65fb86994d363eb16841ee642 "Add OSTYPE build-system variable, and use it" * 3fb8c431824aa2f3bd979e35d1a283546fcfbe74 "Fix building libgmp on cygwin" * cdbb4720c424500adb57cbbef69721d0b039fa46 "Fix cmd invocation by libffi cuild system on Windows 7 cygwin" * e8121501ee3549a35e954726ccfd871ac9d51f83 "Fix dblatex and xml* tool detection on Windows" Reviewed by: austin, Phyx Differential Revision: https://phabricator.haskell.org/D1155
* Replace usages of `-w` by `-fno-warn`sThomas Miedema2015-07-041-4/+7
| | | | | | | | | | | And remove unused imports and language pragmas. I checked that the minimum Happy and Alex version requirements, as listed in aclocal.m4, don't have to change. Before building ghc, I ran: - cabal install happy==1.19.4 --with-ghc=ghc-7.8.4 - cabal install alex==3.1.0 --with-ghc=ghc-7.6.3 Differential Revision: https://phabricator.haskell.org/D1032
* Implement PowerPC 64-bit native code backend for LinuxPeter Trommler2015-07-031-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the PowerPC 32-bit native code generator for "64-bit PowerPC ELF Application Binary Interface Supplement 1.9" by Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification -- OpenPOWER ABI for Linux Supplement" by IBM. The latter ABI is mainly used on POWER7/7+ and POWER8 Linux systems running in little-endian mode. The code generator supports both static and dynamic linking. PowerPC 64-bit code for ELF ABI 1.9 and 2 is mostly position independent anyway, and thus so is all the code emitted by the code generator. In other words, -fPIC does not make a difference. rts/stg/SMP.h support is implemented. Following the spirit of the introductory comment in PPC/CodeGen.hs, the rest of the code is a straightforward extension of the 32-bit implementation. Limitations: * Code is generated only in the medium code model, which is also gcc's default * Local symbols are not accessed directly, which seems to also be the case for 32-bit * LLVM does not work, but this does not work on 32-bit either * Must use the system runtime linker in GHCi, because the GHC linker for "static" object files (rts/Linker.c) for PPC 64-bit is not implemented. The system runtime (dynamic) linker works. * The handling of the system stack (register 1) is not ELF- compliant so stack traces break. Instead of allocating a new stack frame, spill code should use the "official" spill area in the current stack frame and deallocation code should restore the back chain * DWARF support is missing Fixes #9863 Test Plan: validate (on powerpc, too) Reviewers: simonmar, trofi, erikd, austin Reviewed By: trofi Subscribers: bgamari, arnons1, kgardas, thomie Differential Revision: https://phabricator.haskell.org/D629 GHC Trac Issues: #9863
* Recognise 'hardhloat' as a valid vendor in a host tupleSergei Trofimovich2015-06-201-0/+3
| | | | | | | | Observed on a tuple armv7a-hardfloat-linux-gnueabi: > Unknown vendor hardfloat Reported-by: Sergey Alirzaev Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* arm: Force non-executable stack (part 2)Erik de Castro Lopo2015-05-051-1/+1
| | | | | | | This was supposed to be part of commit 63a10bbc42 but I pushed from the wrong machine. This fixes cross compiling to arm. Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
* arm: Force non-executable stack (#10369)Erik de Castro Lopo2015-05-051-1/+2
| | | | | | | | | | | | | | | | | | Test `T703` was found to be failing on arm/linux. The solution was to add a linker flag to explicitly set the stack to non-executable. Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com> Test Plan: validate on x86_64 and arm linux Reviewers: ezyang, rwbarton, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D875 GHC Trac Issues: #10369
* Use the gold linker for aarch64/linux (#9673)Erik de Castro Lopo2015-04-221-7/+11
| | | | | | | | | | | | | | | | Like 32 bit Arm, Aarch64 requires use of the gold linker. Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com> Test Plan: 'make install' on aarch64, validate elsewhere Reviewers: rwbarton, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D858 GHC Trac Issues: #9673
* Fix autoconf's check for create_timer()Austin Seipp2015-04-141-32/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | GHC build system have custom autoconf check for `create_timer()` function from librt. Check description says that it checks for `CLOCK_REALTIME` timer, but checking code also checks for `CLOCK_PROCESS_CPUTIME_ID` timer, which is not commonly present (for example, FreeBSD doesn't have it). This makes whole check fail despite the fact that FreeBSD have `create_timer()` call and supports `CLOCK_REALTIME`. As a consequence, GHC RTS falls back to using SIGALRM for its timing machinery. Not only it's very ancient codepath, it also break some FFI bindings to C code that isn't prepared for syscall interruption caused by SIGALRM delivery. Grepping through ghc source code reveals that `USE_TIMER_CREATE` defininition in the config.h doesn't imply having `CLOCK_PROCESS_CPUTIME_ID`. The only place where `CLOCK_PROCESS_CPUTIME_ID` is used is rts/posix/GetTime.c and this code handles the absence of `CLOCK_PROCESS_CPUTIME_ID` gracefully. This patch makes autoconf checking code to check only for `timer_create(CLOCK_REALTIME, ...)` and fixes check description. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D831
* configure : LLVM and LD detections improvements (#10234).Erik de Castro Lopo2015-04-111-0/+22
| | | | | | | | | | | | | | | | | | | | * distrib/configure.ac.in : Detect correct version of LLVM tools as was done for the top level configure.ac in 42448e3757. * aclocal.m4 : Add a FIND_LD macro that can be used in both configure scripts. * Use new FIND_LD macro in both configure scripts. Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com> Test Plan: validate on amd64-linux and armhf-linux. Reviewers: rwbarton, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D828 GHC Trac Issues: #10234
* Whitespace onlyReid Barton2015-04-051-17/+17
|
* Fix Git-commit-id detection for RELEASE=YESHerbert Valerio Riedel2015-03-261-1/+1
| | | | | | | | | By mistake, the Git-commit-id detection was only enabled for `RELEASE=NO` (since the date-based GHC version computation is only active in that case). With this commit the commit-id detection is active regardless of the `RELEASE`-setting. This is a follow-up to 73e5e2f8bade2d8b2b1ecae958fe12d0b24591ef
* Do version specific detection of LLVM tools (#10170).Erik de Castro Lopo2015-03-241-25/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | The LLVM developers seem to make breaking changes in the LLVM IR language between major releases. As a consumer of the LLVM tools GHC now needs to be locked more tightly to a single version of the LLVM tools. GHC HEAD currently only supports LLVM version 3.6. This commit changes the configure script to look for `llc-3.6` and `opt-3.6` before looking for `llc` and `opt`. If the former are not found, but the later are, check that they actually are version 3.6. At the same time, when detecting known problems with the LLVM tools (ie #9439) test for it using the versions of the LLVM tools retrieved from the bootstrap compiler's settings file. Test Plan: Manual testing. Reviewers: thomie, rwbarton, nomeata, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D745 GHC Trac Issues: #10170
* Use the gold linker for linux/ARM and android/ARM targets.Erik de Castro Lopo2015-03-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #8976 and #9873 by making use of the Binutils ld.gold linker explicit whenever the target is linux/ARM or android/ARM. This does not affect iOS where Apple provides its own linker. In order to achieve this, we need to add `-fuse-ld=gold` to the SettingsCCompilerLinkFlags setting and set SettingsLdCommand to `ld.gold` (or `${target}-ld.gold` when cross-compiling). In addition, simplifying the use of `$(CONF_GCC_LINKER_OPTS_STAGEn)`. This patch was tested by ensuring that the following worked as expected: * Native builds on linux/x86_64 (nothing changed). * Native builds on linux/arm (and uses the gold linker). * Linux to linux/arm cross compiles (and uses the cross gold linker). Contributions by Ben Gamari, Joachim Breitner and Reid Barton. Reviewers: nomeata, bgamari, austin, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D715 GHC Trac Issues: #8976 #9873
* Fix detection of llvm-x.xThomas Miedema2015-03-021-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Four bug fixes and a little refactoring. * `find -perm \mode` should be `find -perm /mode` (#9697) * `find -regex '$3' should be `find -regex "$3"` (#7661) From `man sh` on my system (Ubuntu 14.04): "Enclosing characters in single quotes preserves the literal meaning of all the characters ..." * LlcCmd and OptCmd should be passed to ghc, using `-pgmlo` and `-pgmlc`, for detection of #9439. * -pgmlo and -pgmlc were undocumented because of an xml tag misplacement. Test Plan: The aclocal.m4 macro has seen about 10 iterations since its inception. Without a testsuite, I can't guarantee this version is bug free either. It's all pretty frustrating. Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D683 GHC Trac Issues: #9697, #7661, #9439
* Make top-level "configure" accept and propagate ↵PHO2015-02-231-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | --with-curses-{includes,libraries} to libraries Summary: If curses is installed into some non-standard path, we currently have to say something like the following in mk/build.mk: libraries/terminfo_CONFIGURE_OPTS += \ --configure-option=--with-curses-includes=/somewhere/include \ --configure-option=--with-curses-libraries=/somewhere/lib This is because the top-level configure does not accept nor propagate --with-curses-{includes,libraries} to libraries while it does so for iconv, gmp and libffi. It would be nice if curses were handled in the same manner. Test Plan: Install curses into some non-standard path. Then run the top-level "configure" script with options "--with-curses-includes=/path/to/curses/include" and "--with-curses-libraries=/path/to/curses/lib". Reviewers: austin Reviewed By: austin Subscribers: thomie, PHO Differential Revision: https://phabricator.haskell.org/D665 GHC Trac Issues: #10096
* Remove RAWCPP_FLAGS (Task #9094)Thomas Miedema2015-02-171-4/+6
| | | | | | | | | | | | Reviewers: carter, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D648 GHC Trac Issues: #9094
View Lorry Controller Status