Newer SDKs don't even provide libstdc++ headers, so it's effectively
never valid to build for libstdc++ unless the user explicitly asks
for it (in which case they will need to provide include paths and more).
This is a re-application of c5ccb78ade which had been reverted in
33171df9cc because it broke the Fuchsia CI bots. The issue was that
the test was XPASSing because it didn't fail anymore when the
CLANG_DEFAULT_CXX_LIB was set to libc++, which seems to be done for
Fuchsia. Instead, the test only fails if CLANG_DEFAULT_CXX_LIB is
set to libstdc++.
As a fly-by fix, also adjust the triple used by various tests to
something that is supported. Those tests were shown to fail on
internal bots.
Differential Revision: https://reviews.llvm.org/D131274
Refactor baremetal driver code to reduce the bespoke
additions and base class overrides.
This lets us use the per target runtimes like other clang
targets. E.g. clang -target armv7m-cros-none-eabi will now
be able to use the runtimes installed at
<resource_dir>/lib/armv7m-cros-none-eabi instead of the hardcoded
path <resource_dir>/lib/baremetal.
The older code paths should still continue to work as before if
<resource_dir>/lib/<tuple> does not exist.
Reviewed By: MaskRay, barannikov88
Differential Revision: https://reviews.llvm.org/D131225
When not set output, set default output to stdout.
When set output with -Fo and no -fcgl, set -emit-obj to generate dx container.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D130858
When performing device only compilation, there was an issue where
`cubin` outputs were being renamed to `cubin` despite the user's name.
This is required in a normal compilation flow as the Nvidia tools only
understand specific filenames instead of checking magic bytes for some
unknown reason. We do not want to perform this transformation when the
user is performing device only compilation.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D131278
-E option will set entry function for hlsl.
The format is -E entry_name.
To avoid conflict with existing option with name 'E', add an extra prefix '--'.
A new field HLSLEntry is added to TargetOption.
To share code with HLSLShaderAttr, entry function will be add HLSLShaderAttr attribute too.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D124751
Newer SDKs don't even provide libstdc++ headers, so it's effectively
never valid to build for libstdc++ unless the user explicitly asks
for it (in which case they will need to provide include paths and more).
I went over the output of the following mess of a command:
(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z |
parallel --xargs -0 cat | aspell list --mode=none --ignore-case |
grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n |
grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Differential Revision: https://reviews.llvm.org/D130827
Closing https://github.com/llvm/llvm-project/issues/56803. The root
cause for this bug is that we lack a good method to detect the language
mdoe when parsing the command line. There is a FIXME too. Dut to we lack
a good solution now, keep the workaround.
To make use of SPARC support in `getHostCPUName` as implemented by D130272
<https://reviews.llvm.org/D130272>, this patch uses it to handle
`-mcpu=native` and `-mtune=native`. To match GCC, this patch rejects
`-march` instead of silently treating it as a no-op.
Tested on `sparcv9-sun-solaris2.11` and checking that those options are
passed on as `-target-cpu` resp. `-tune-cpu` as expected.
Differential Revision: https://reviews.llvm.org/D130273
This is the Linux/sparc64 equivalent to D118021
<https://reviews.llvm.org/D118021>, necessary to provide an external
implementation of atomics on 32-bit SPARC which LLVM cannot inline even
with `-mcpu=v9` or an equivalent default.
Tested on `sparc64-unknown-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D130569
Summary:
Linkers use `--verbose` to let users investigate search libraries among
other things. The linker wrapper was incorrectly not forwarding this to
the linker job. This patch simply renames this so users can still see
verbose messages from the linker if it was passed.
Lifting the core functionalities of the clang-offload-bundler into a
user-facing library/API. This will allow online and JIT compilers to
bundle and unbundle files without spawning a new process.
This patch lifts the classes and functions used to implement
the clang-offload-bundler into a separate OffloadBundler.cpp,
and defines three top-level API functions in OfflaodBundler.h.
BundleFiles()
UnbundleFiles()
UnbundleArchives()
This patch also introduces a Config class that locally stores the
previously global cl::opt options and arrays to allow users to call
the APIs in a multi-threaded context, and introduces an
OffloadBundler class to encapsulate the top-level API functions.
We also lift the BundlerExecutable variable, which is specific
to the clang-offload-bundler tool, from the API, and replace
its use with an ObjcopyPath variable. This variable must be set
in order to internally call llvm-objcopy.
Finally, we move the API files from
clang/tools/clang-offload-bundler into clang/lib/Driver and
clang/include/clang/Driver.
Differential Revision: https://reviews.llvm.org/D129873
This patch changes legacy LTO to set data-sections by default. The user can
explicitly unset data-sections. The reason for this patch is to match the
behaviour of lld and gold plugin. Both lld and gold plugin have data-sections on
by default.
This patch also fixes the forwarding of the clang options -fno-data-sections and
-fno-function-sections to libLTO. Now, when -fno-data/function-sections are
specified in clang, -data/function-sections=0 will be passed to libLTO to
explicitly unset data/function-sections.
Reviewed By: w2yehia, MaskRay
Differential Revision: https://reviews.llvm.org/D129401
This patch changes legacy LTO to set data-sections by default. The user can
explicitly unset data-sections. The reason for this patch is to match the
behaviour of lld and gold plugin. Both lld and gold plugin have data-sections on
by default.
This patch also fixes the forwarding of the clang options -fno-data-sections and
-fno-function-sections to libLTO. Now, when -fno-data/function-sections are
specified in clang, -data/function-sections=0 will be passed to libLTO to
explicitly unset data/function-sections.
Reviewed By: w2yehia, MaskRay
Differential Revision: https://reviews.llvm.org/D129401
We are supporting quadword lock free atomics on AIX. For the situation that users on AIX are using a libatomic that is lock-based for quadword types, we can't enable quadword lock free atomics by default on AIX in case user's new code and existing code accessing the same shared atomic quadword variable, we can't guarentee atomicity. So we need an option to enable quadword lock free atomics on AIX, thus we can build a quadword lock-free libatomic(also for advanced users considering atomic performance critical) for users to make the transition smooth.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D127189
Lifting the core functionalities of the clang-offload-bundler into a
user-facing library/API. This will allow online and JIT compilers to
bundle and unbundle files without spawning a new process.
This patch lifts the classes and functions used to implement
the clang-offload-bundler into a separate OffloadBundler.cpp,
and defines three top-level API functions in OfflaodBundler.h.
BundleFiles()
UnbundleFiles()
UnbundleArchives()
This patch also introduces a Config class that locally stores the
previously global cl::opt options and arrays to allow users to call
the APIs in a multi-threaded context, and introduces an
OffloadBundler class to encapsulate the top-level API functions.
We also lift the BundlerExecutable variable, which is specific
to the clang-offload-bundler tool, from the API, and replace
its use with an ObjcopyPath variable. This variable must be set
in order to internally call llvm-objcopy.
Finally, we move the API files from
clang/tools/clang-offload-bundler into clang/lib/Driver and
clang/include/clang/Driver.
Differential Revision: https://reviews.llvm.org/D129873
This compensates for 8f0c901c1a which enabled
-Wunused-command-line-argument for unimplemented -mtune= in the generic code.
Ignoring -mtune= appears to be longstanding and the error-free behavior in the
presence of -Werror is unfortunately relied on by the Linux kernel's arm and
powerpc ports. Ignore the warnings for the upcoming 15.0.0 branch and will
implement functionality to fill the test gap soon.
Link: https://github.com/ClangBuiltLinux/linux/issues/1674
They have been ported and tested to work on AArch64
(see D125883, D125758, and D125873).
Reviewed By: dim, MaskRay
Differential Revision: https://reviews.llvm.org/D130063
-gsplit-dwarf produces a .dwo file which will not be processed by the linker. If
.dwo files contain relocations, they will not be resolved. Therefore the
practice is that .dwo files do not contain relocations.
Address ranges and location description need to use forms/entry kinds indexing
into .debug_addr (DW_FORM_addrx/DW_RLE_startx_endx/etc), which is currently not
implemented.
There is a difficult-to-read MC error with -gsplit-dwarf with RISC-V for both -mrelax and -mno-relax.
```
% clang --target=riscv64-linux-gnu -g -gsplit-dwarf -c a.c
error: A dwo section may not contain relocations
```
We expect to fix -mno-relax soon, so report a driver error for -mrelax for now.
Link: https://github.com/llvm/llvm-project/issues/56642
Reviewed By: compnerd, kito-cheng
Differential Revision: https://reviews.llvm.org/D130190
Adds `sarif` option to the existing `-fdiagnostics-format` flag
for intended future work with SARIF diagnostics. Currently issues a warning
against the use of diagnostics in SARIF mode, then defaults to clang style for
diagnostics.
Reviewed By: cjdb, denik, aaron.ballman
Differential Revision: https://reviews.llvm.org/D129886
These headers used to be guarded only on PowerPC64 Linux or FreeBSD, but
they can also be enabled for AIX OS target since it's big-endian ready.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D129461
The heuristic used to determine where the arclite libraries are to be
found was based on the path of the `clang` executable. However, in some
scenarios the `clang` executable is within a toolchain that does not
have arclite. When this happens, derive the arclite paths from the
sysroot option.
This allows Clang to correctly derive the arclite directory in, e.g.,
Swift CI, using similar logic to what the Swift driver has been doing
for several years.
Patched by Doug Gregor.
Reviewed By: keith
Differential Revision: https://reviews.llvm.org/D130205
The new driver primarily allows us to support RDC-mode compilations with
proper linking. This is not needed for non-RDC mode compilation, but we
still would like the new driver to be able to handle this mode so we can
transition away from the old driver in the future. This patch adds the
necessary code to support creating a fatbinary for HIP code generation.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D129784
A new option -I is added for dxc mode.
It is just alias of existing cc1 -I option.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D128462
Move -lc++experimental before -lc++abi (that was forgotten in the
original patch), and mark a test as UNSUPPORTED on AIX. I contacted
the owners of the AIX bot that failed because I was unable to reproduce
the issue locally.
Based on the discussion at [1], this patch adds a Clang flag called
-fexperimental-library that controls whether experimental library
features are provided in libc++. In essence, it links against the
experimental static archive provided by libc++ and defines a feature
that can be picked up by libc++ to enable experimental features.
This ensures that users don't start depending on experimental
(and hence unstable) features unknowingly.
[1]: https://discourse.llvm.org/t/rfc-a-compiler-flag-to-enable-experimental-unstable-language-and-library-features
Differential Revision: https://reviews.llvm.org/D121141
Some code [0] consider that trailing arrays are flexible, whatever their size.
Support for these legacy code has been introduced in
f8f6324983 but it prevents evaluation of
__builtin_object_size and __builtin_dynamic_object_size in some legit cases.
Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is
desirable.
n = 0: current behavior, any trailing array member is a flexible array. The default.
n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member
n = 2: any trailing array member of undefined or 0 size is a flexible array member
This takes into account two specificities of clang: array bounds as macro id
disqualify FAM, as well as non standard layout.
Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
[0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions
Louis Dionne