This patch removes redundant autoconf check for the context diff
program given it isn't actually been used anywhere, especially since
make removal.

(cherry picked from commit b7bcf729)
(cherry picked from commit 0e9d2a0f)
(cherry picked from commit 00d58ab2)

This commit removes obsolete deletection logic of the patch command
from autoconf scripts, given we no longer need to patch anything in
the GHC build process.

(cherry picked from commit 71f28958)
(cherry picked from commit 1e77ded1)
(cherry picked from commit e5506d09)

Ever since the removal of the make build system, the in tree lndir
hasn't been actually built, so this patch removes it.

(cherry picked from commit d3a050d2)
(cherry picked from commit 04860c24)

This patch does a few things:

- Always build 64-bit atomic ops in rts/ghc-prim, even on 32-bit
  platforms
- Remove legacy "64bit" cabal flag of rts package
- Fix hs_xchg64 function prototype for 32-bit platforms
- Fix AtomicFetch test for wasm32

(cherry picked from commit 87095f6a)

Metric Increase:
    MultiLayerModulesTH_Make

Metric Decrease:
    MultiLayerModulesTH_Make

Rodrigo Mesquita authored 1 year ago and Zubin committed 1 year ago

In autoconf >=2.70, C11 is set by default for $CC and $CXX via the
-std=...11 flag. In this patch, we split the "-std" flag out of the $CC
and $CXX variables, which we traditionally assume to be just the
executable name/path, and move it to $CFLAGS/$CXXFLAGS instead.

Fixes #24324

(cherry picked from commit cdddeb0f)

Metric Decrease:
    T13701

Rodrigo Mesquita authored 1 year ago and Zubin committed 1 year ago

In XCode 15's linker, -single_module is the default and otherwise
passing it as a flag results in a warning being raised:

    ld: warning: -single_module is obsolete

This patch fixes this warning by, at configure time, determining whether
the linker supports -single_module (which is likely false for all
non-darwin linkers, and true for darwin linkers in previous versions of
macOS), and using that information at runtime to decide to pass or not
the flag in the invocation.

Fixes #24168

(cherry picked from commit e6c803f7)

Rodrigo Mesquita authored 1 year ago and Zubin committed 1 year ago

Fixes #24167

XCode 15 introduced a new linker which warns on duplicate libraries being
linked. To disable this warning, we pass -Wl,-no_warn_duplicate_libraries as
suggested by Brad King in CMake issue #25297.

This flag isn't necessarily available to other linkers on darwin, so we must
only configure it into the CC linker arguments if valid.

(cherry picked from commit e98051a5)

Moritz Angermann authored 1 year ago and Zubin committed 1 year ago

XCODE_VERSION calls out to `xcodebuild`, which is only available
when having `Xcode` installed. The CommandLineTools are not
sufficient. To install Xcode, you must have an apple id to download
the Xcode.xip from apple.

We do not use xcodebuild anywhere in our build explicilty. At best
it appears to be a proxy for checking the linker or the compiler.
These should rather be done with
```
xcrun ld -version
```
or similar, and not by proxy through Xcode. The CLR should be
sufficient for building software on macOS.

(cherry picked from commit a3ee3b99)

Metric Decrease:
    MultiComponentModules
    MultiComponentModulesRecomp
    MultiLayerModules
    MultiLayerModulesRecomp
    T10421
    T12150
    T12234
    T12425
    T13035
    T13701
    T13719
    T15164
    T16875
    T18140
    T18304
    T18698a
    T18698b
    T18923
    T20049
    T9198
    T9961
    hard_hole_fits
Metric Decrease 'compile_time/bytes allocated':
    T21839r
Metric Increase 'runtime/max_bytes_used':
    T21839r
Metric Increase 'runtime/peak_megabytes_allocated':
    T21839r

Ben Gamari authored 1 year ago and Zubin committed 1 year ago

Fixes #22012 by adding the symbols described in
https://github.com/llvm/llvm-project/blob/main/llvm/docs/Atomics.rst#libcalls-atomic.

Ultimately this would be better addressed by #22011, but this is a first
step in the right direction and fixes the immediate symptom.

Note that we dropped the `__arch64_cas16` operations as these provided
by all platforms's compilers. Also, we don't link directly against the
libgcc/compiler-rt definitions but rather provide our own wrappers to
work around broken toolchains (e.g. https://bugs.gentoo.org/868018).

Generated via ghc/ghc$5733.

(cherry picked from commit 1aa5733a)

Ryan Scott authored 1 year ago and Zubin committed 1 year ago

This partially reverts some of the changes in !9475 to make `base` and
`ghc-prim` depend on the `mingwex` library on Windows. It also restores the
RTS's stubs for `mingwex`-specific symbols such as `_lock_file`.

This is done because the C runtime provides `libmingwex` nowadays, and
moreoever, not linking against `mingwex` requires downstream users to link
against it explicitly in difficult-to-predict circumstances. Better to always
link against `mingwex` and prevent users from having to do the guesswork
themselves.

See !10360 (comment 495873) for
the discussion that led to this.

(cherry picked from commit 2b1a4abe)

Ben Gamari authored 1 year ago and Zubin committed 1 year ago

Fixes #22012 by adding the symbols described in
https://github.com/llvm/llvm-project/blob/main/llvm/docs/Atomics.rst#libcalls-atomic.

Ultimately this would be better addressed by #22011, but this is a first
step in the right direction and fixes the immediate symptom.

Note that we dropped the `__arch64_cas16` operations as these provided
by all platforms's compilers. Also, we don't link directly against the
libgcc/compiler-rt definitions but rather provide our own wrappers to
work around broken toolchains (e.g. https://bugs.gentoo.org/868018).

Generated via ghc/ghc$5733.

(cherry picked from commit 1aa5733a)

LLVM 15 turns on the new pass manager by default, which we have yet to
migrate to so for new we pass the `-enable-new-pm-0` flag in our
llvm-passes flag.

LLVM 11 was the first version to support the `-enable-new-pm` flag so we
bump the lowest supported version to 11.

Our CI jobs are using LLVM 12 so they should continue to work despite
this bump to the lower bound.

Fixes #21936

(cherry picked from commit 0cc16aaf)

Despite Cabal supporting any architecture name, `cabal --check` only
supports a few built-in ones. Sadly `cabal --check` is used by Hackage
hence using any non built-in name in a package (e.g. `arch(js)`) is
rejected and the package is prevented from being uploaded on Hackage.

Luckily built-in support for the `javascript` architecture was added for
GHCJS a while ago. In order to allow newer `base` to be uploaded on
Hackage we make the switch from `js` to `javascript` architecture.

Fixes #22740.

Co-authored-by: Ben Gamari <ben@smart-cactus.org>
(cherry picked from commit 6636b670)

The clang based toolchain uses ucrt as its math library
and so mingwex is no longer needed.  In fact using mingwex
will cause incompatibilities as the default routines in both
have differing ULPs and string formatting modifiers.

```
$ LIBRARY_PATH=/mingw64/lib ghc/_build/stage1/bin/ghc Bug.hs -fforce-recomp && ./Bug.exe
[1 of 2] Compiling Main             ( Bug.hs, Bug.o )
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `__imp___p__environ'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `__hscore_get_errno'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_ForeignziCziError_errnoToIOError_info'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziWindows_failIf2_closure'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncodingziCodePageziAPI_mkCodePageEncoding_info'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncodingziCodePage_currentCodePage_closure'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncoding_getForeignEncoding_closure'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_ForeignziCziString_withCStringLen1_info'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziHandleziInternals_zdwflushCharReadBuffer_info'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziHandleziText_hGetBuf1_info'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziFingerprint_fingerprintString_closure'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_DataziTypeableziInternal_mkTrCon_closure'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziException_errorCallWithCallStackException_closure'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziErr_error_info'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\template-haskell-2.19.0.0\libHStemplate-haskell-2.19.0.0.a: unknown symbol `base_DataziMaybe_fromJust1_info'
ghc.exe:  | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\template-haskell-2.19.0.0\libHStemplate-haskell-2.19.0.0.a: unknown symbol `templatezmhaskell_LanguageziHaskellziTHziSyntax_IntPrimL_con_info'
ghc.exe: ^^ Could not load 'templatezmhaskell_LanguageziHaskellziTHziLibziInternal_stringL_closure', dependency unresolved. See top entry above.

<no location info>: error:

GHC.ByteCode.Linker.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
  templatezmhaskell_LanguageziHaskellziTHziLibziInternal_stringL_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session.  Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
  https://www.haskell.org/ghc/reportabug
```

(cherry picked from commit de1d1512)

Ben Gamari authored 2 years ago and Matthew Pickering committed 2 years ago

Teach the `configure` script to create the `VERSION` file.
This will serve as the stable interface to allow the user to determine
the version number of a working tree.

Fixes #22322.

(cherry picked from commit a2d814dc)

This mirrors some existing logic for the bootstrap_target which
influences how TargetPlatform is set.

As described on #21970 not storing this led to `LlvmTarget` being set incorrectly
and hence the wrong `--target` flag being passed to the C compiler.

Towards #21970

(cherry picked from commit 64286132)

Recent versions of MacOS use a version of ld where `-fixup_chains` is on by default.
This is incompatible with our usage of `-undefined dynamic_lookup`. Therefore we
explicitly disable `fixup-chains` by passing `-no_fixup_chains` to the linker on
darwin. This results in a warning of the form:

ld: warning: -undefined dynamic_lookup may not work with chained fixups

The manual explains the incompatible nature of these two flags:

     -undefined treatment
             Specifies how undefined symbols are to be treated. Options are: error, warning,
             suppress, or dynamic_lookup.  The default is error. Note: dynamic_lookup that
             depends on lazy binding will not work with chained fixups.

A relevant ticket is #22429

Here are also a few other links which are relevant to the issue:

Official comment: https://developer.apple.com/forums/thread/719961

More relevant links:

https://openradar.appspot.com/radar?id=5536824084660224

https://github.com/python/cpython/issues/97524

Note in release notes: https://developer.apple.com/documentation/xcode-release-notes/xcode-13-releas    e-notes

(cherry picked from commit 8c0ea25f)

This reverts commit 7c6de18d.

Centos7 using a very old version of the toolchain (autotools-2.69) where
the behaviour of these macros has not yet changed. I am reverting this
without haste as it is blocking the 9.6 branch.

Fixes #22704

(cherry picked from commit b2a2db04)

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

The latter has been deprecated.

See #22566.

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

As noted in #22566, this macro is deprecated as of autoconf-2.70
`AC_PROG_CC` now sets `ac_cv_prog_cc_c99` itself.

Closes #22566.

Matthew Pickering authored 2 years ago and Marge Bot committed 2 years ago

I am not sure this job is good because it requires booting HEAD with
HEAD, but it should be fine.

Add JS backend adapted from the GHCJS project by Luite Stegeman.

Some features haven't been ported or implemented yet. Tests for these
features have been disabled with an associated gitlab ticket.

Bump array submodule

Work funded by IOG.

Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io>
Co-authored-by: Luite Stegeman <stegeman@gmail.com>
Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>

Sylvain Henry authored 3 years ago and Marge Bot committed 2 years ago

Hadrian now performs substitutions, especially to generate .cabal files
from .cabal.in files. Two benefits:

1. We won't have to re-configure when we modify thing.cabal.in. Hadrian
   will take care of this for us.

2. It paves the way to allow the same package to be configured
   differently by Hadrian in the same session. This will be useful to
   fix #19174: we want to build a stage2 cross-compiler for the host
   platform and a stage1 compiler for the cross target platform in the
   same Hadrian session.

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

Instead of assuming support on all Linuxes.

Cheng Shao authored 2 years ago and Marge Bot committed 2 years ago

This patch adds the wasm32-wasi tuple support to various places in the
tree: autoconf, hadrian, ghc-boot and also the compiler. The codegen
logic will come in subsequent commits.