Summary:
A skeleton of AIX toolchain and system linker support has been introduced in D68340, and this is a follow on patch to it.
This patch adds support to system assembler invocation to the AIX toolchain.
Reviewers: daltenty, hubert.reinterpretcast, jasonliu, Xiangling_L, dlj
Reviewed By: daltenty, hubert.reinterpretcast
Subscribers: wuzish, nemanjai, kbarton, jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69620
Skip distro detection when we're not running on Linux, or when the target triple is not Linux. This saves a few OS calls for each invocation of clang.exe.
Differential Revision: https://reviews.llvm.org/D70467
Summary:
Removed the ```-fforce-experimental-new-constant-interpreter flag```, leaving
only the ```-fexperimental-new-constant-interpreter``` one. The interpreter
now always emits an error on an unsupported feature.
Allowing the interpreter to bail out would require a mapping from APValue to
interpreter memory, which will not be necessary in the final version. It is
more sensible to always emit an error if the interpreter fails.
Reviewers: jfb, Bigcheese, rsmith, dexonsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70071
When selecting the set of default sanitizers, don't fail for unknown
architectures. This may be the case e.g. with x86_64-unknown-fuchsia
-m32 target that's used to build the bootloader.
Differential Revision: https://reviews.llvm.org/D70747
GCC 8 implements -fmacro-prefix-map. Like -fdebug-prefix-map, it replaces a string prefix for the __FILE__ macro.
-ffile-prefix-map is the union of -fdebug-prefix-map and -fmacro-prefix-map
Reviewed By: rnk, Lekensteyn, maskray
Differential Revision: https://reviews.llvm.org/D49466
Using the version instead of the VCS revision, which isn't available
when LLVM_APPEND_VC_REV is set. The bitcode format should be
backwards-compatible at least within a minor version, so the version
string should be sufficient.
Differential Revision: https://reviews.llvm.org/D70677
Summary:
On SUSE distributions for 32-bit PowerPC, gcc is configured
as a 64-bit compiler using the GNU triplet "powerpc64-suse-linux",
but invoked with "-m32" by default. Thus, the correct GNU triplet
for 32-bit PowerPC SUSE distributions is "powerpc64-suse-linux"
and not "powerpc-suse-linux".
Reviewers: jrtc27, nemanjai, glaubitz
Reviewed By: nemanjai
Differential Revision: https://reviews.llvm.org/D55326
When there's a wasm-opt in the PATH, run the it to optimize LLVM's
output. This fixes PR43796.
And, add an "llvm-lto" directory to the sysroot library search paths,
so that sysroots can provide LTO-enabled system libraries.
Differential Revision: https://reviews.llvm.org/D70500
In the GNU toolchain, `-static-libgcc` implies that the unwindlib will
be linked statically. However, when `--unwindlib=libunwind`, this flag is
ignored, and a bare `-lunwind` is added to the linker args. Unfortunately,
this means that if both `libunwind.so`, and `libunwind.a` are present
in the library path, `libunwind.so` will be chosen in all cases where
`-static` is not set.
This change makes `-static-libgcc` affect the `-l` flag produced by
`--unwindlib=libunwind`. After this patch, providing
`-static-libgcc --unwindlib=libunwind` will cause the driver to explicitly
emit `-l:libunwind.a` to statically link libunwind. For all other cases
it will emit `-l:libunwind.so` matching current behavior with a more
explicit link line.
https://reviews.llvm.org/D70416
If a GCC installation is not detected, then this attempts to
use compiler-rt and the compiler-rt crtbegin/crtend
implementations as a fallback.
Differential Revision: https://reviews.llvm.org/D68407
1. Currently only support the set of multilibs same to riscv-gnu-toolchain.
2. Fix testcase typo causes fail on Windows.
3. Fix testcases to set empty sysroot.
Reviewers: espindola, asb, kito-cheng, lenary
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D67508
We don't have a full sysroot yet, so for now we only include compiler
support and compiler-rt builtins, the rest of the runtimes will get
enabled later.
Differential Revision: https://reviews.llvm.org/D70477
This patch will add -mcpu=future into clang for PowerPC.
A CPU type is required for work that may possibly be enabled for some future
Power CPU. The CPU type future will serve that purpose. This patch introduces
no new functionality. It is an incremental patch on top of which Power PC work
for some future CPU can be done.
Differential Revision: https://reviews.llvm.org/D70262
With updates to various LLVM tools that use SpecialCastList.
It was tempting to use RealFileSystem as the default, but that makes it
too easy to accidentally forget passing VFS in clang code.
Summary:
This is a follow-up to 590f279c45, which
moved some of the callers to use VFS.
It turned out more code in Driver calls into real filesystem APIs and
also needs an update.
Reviewers: gribozavr2, kadircet
Reviewed By: kadircet
Subscribers: ormris, mgorny, hiraditya, llvm-commits, jkorous, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D70440
1. Currently only support the set of multilibs same to riscv-gnu-toolchain.
2. Fix testcase typo causes fail on Windows
Reviewers: espindola, asb, kito-cheng, lenary
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D67508
On Darwin the clang driver does not invoke Driver::BuildActions directly
due to the need to handle Universal apps. Because of this there is a
difference in code path where Driver::BuildUniversalActions is called
instead of Driver::BuildActions. BuildUniversalActions ends up calling
Driver::BuildAction but what it does differently is it takes the driver
actions returned and wraps them each into a BindArchAction.
In Driver::BuildJobs there is a check for '-o' to determine that
multiple files are not specified when passing -o, except for Clang
Interface Stub this need to be an exception as we actually want to write
out multiple files: for every libfoo.so we have a libfoo.ifso sidecar
ifso file, etc. To allow this to happen there is a check for
IfsMergeAction, which is permitted to write out a secondary file. Except
on Darwin, the IfsMergeAction gets wrapped in the BindArchAction by
Driver::BuildUniversalActions so the check fails.
This patch is to look inside a BindArchAction in Driver::BuildJobs to
determine if there is in fact an IfsMergeAction, and if-so (pun intended)
allow the secondary sidecard ifs/ifso file to be written out.
Third Landing Attempt (dropping any linker invocation from clang driver):
Up until now, clang interface stubs has replaced the standard
PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
conjunction with it. So what when you build your code you will get an
a.out or lib.so as well as an interface stub file.
Example:
clang -shared -o libfoo.so -emit-interface-stubs ...
will generate both a libfoo.so and a libfoo.ifso. The .so file will
contain the code from the standard compilation pipeline and the .ifso
file will contain the ELF stub library.
Note: For driver-test.c I've added -S in order to prevent any bot failures on
bots that don't have the proper linker for their native triple. You could always
specify a triple like x86_64-unknown-linux-gnu and on bots like x86_64-scei-ps4
the clang driver would invoke regular ld instead of getting the error
'Executable "orbis-ld" doesn't exist!' but on bots like ppc64be and s390x you'd
get an error "/usr/bin/ld: unrecognised emulation mode: elf_x86_64"
Differential Revision: https://reviews.llvm.org/D70274
Second Landing Attempt:
Up until now, clang interface stubs has replaced the standard
PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
conjunction with it. So what when you build your code you will get an
a.out or lib.so as well as an interface stub file.
Example:
clang -shared -o libfoo.so -emit-interface-stubs ...
will generate both a libfoo.so and a libfoo.ifso. The .so file will
contain the code from the standard compilation pipeline and the .ifso
file will contain the ELF stub library.
Differential Revision: https://reviews.llvm.org/D70274
Currently only support the set of multilibs same to riscv-gnu-toolchain.
Reviewers: espindola, asb, kito-cheng, lenary
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D67508
Up until now, clang interface stubs has replaced the standard
PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
conjunction with it. So what when you build your code you will get an
a.out or lib.so as well as an interface stub file.
Example:
clang -shared -o libfoo.so -emit-interface-stubs ...
will generate both a libfoo.so and a libfoo.ifso. The .so file will
contain the code from the standard compilation pipeline and the .ifso
file will contain the ELF stub library.
Differential Revision: https://reviews.llvm.org/D70274
Summary:
This allows `clang` to be used to compile CUDA programs. Compiled
simple helloworld.cu with this.
Reviewers: dim, emaste, tra, yaxunl, ABataev
Reviewed By: tra
Subscribers: dim, emaste, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69990
When the driver is targeting multiple architectures at once, for things
like Universal Mach-Os, we need to emit different remark files for each
cc1 invocation to avoid overwriting the files from a different
invocation.
For example:
$ clang -c -o foo.o -fsave-optimization-record -arch x86_64 -arch x86_64h
will create two remark files:
* foo-x86_64.opt.yaml
* foo-x86_64h.opt.yaml
and a follow-up NFC rearrangement as it's causing a crash on valid. Testcase is on the original review thread.
This reverts commits af57dbf12e and e6584b2b7b
When the driver is targeting multiple architectures at once, for things
like Universal Mach-Os, we need to emit different remark files for each
cc1 invocation to avoid overwriting the files from a different
invocation.
For example:
$ clang -c -o foo.o -fsave-optimization-record -arch x86_64 -arch x86_64h
will create two remark files:
* foo-x86_64.opt.yaml
* foo-x86_64h.opt.yaml
For RISC-V the value provided to -march should determine whether to
compile for 32- or 64-bit RISC-V irrespective of the target provided to
the Clang driver. This adds a test for this flag for RISC-V and sets the
Target architecture correctly in these cases.
Differential Revision: https://reviews.llvm.org/D54214
Provides support for using r6-r11 as globally scoped
register variables. This requires a -ffixed-rN flag
in order to reserve rN against general allocation.
If for a given GRV declaration the corresponding flag
is not found, or the the register in question is the
target's FP, we fail with a diagnostic.
Differential Revision: https://reviews.llvm.org/D68862
There doesn't seem to be much sense in defaulting "on" unwind tables on
amd64 and not on other arches. It causes surprising differences between
platforms, such as the PR below[1].
Prior to this change, FreeBSD inherited the default implementation of the
method from the Gnu.h Generic_Elf => Generic_GCC parent class, which
returned true only for amd64 targets. Override that and opt on always,
similar to, e.g., NetBSD's driver.
[1] https://bugs.freebsd.org/241562
Patch by cem (Conrad Meyer).
Reviewed By: dim
Differential Revision: https://reviews.llvm.org/D70110
Summary:
Clang/LLVM is a cross-compiler, and so we don't have to make a choice
about `-march`/`-mabi` at build-time, but we may have to compute a
default `-march`/`-mabi` when compiling a program. Until now, each
place that has needed a default `-march` has calculated one itself.
This patch adds a single place where a default `-march` is calculated,
in order to avoid calculating different defaults in different places.
This patch adds a new function `riscv::getRISCVArch` which encapsulates
this logic based on GCC's for computing a default `-march` value
when none is provided. This patch also updates the logic in
`riscv::getRISCVABI` to match the logic in GCC's build system for
computing a default `-mabi`.
This patch also updates anywhere that `-march` is used to now use the
new function which can compute a default. In particular, we now
explicitly pass a `-march` value down to the gnu assembler.
GCC has convoluted logic in its build system to choose a default
`-march`/`-mabi` based on build options, which would be good to match.
This patch is based on the logic in GCC 9.2.0. This commit's logic is
different to GCC's only for baremetal targets, where we default
to rv32imac/ilp32 or rv64imac/lp64 depending on the target triple.
Tests have been updated to match the new logic.
Reviewers: asb, luismarques, rogfer01, kito-cheng, khchen
Reviewed By: asb, luismarques
Subscribers: sameer.abuasal, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69383
Before this patch if we pass "-mcpu=hexagonv65 -march=hexagon" in this order,
the driver fails to figure out the correct cpu version. This patch fixed this
issue.
Summary:
Tooling around DWARF 5 is still not mature enough for this to be a sane
default, and the AMDGPU and HIP toolchains should agree on a single
default.
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, aprantl, dstuttard, tpr, t-tye, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70191
Summary:
This adds `-mreference-types` and `-mno-reference-types` flags to clang
and make `-fwasm-exceptions` enables reference types feature in clang
and the backend.
Reviewers: tlively
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69832
If a GCC installation is not detected, then this attempts to
use compiler-rt and the compiler-rt crtbegin/crtend
implementations as a fallback.
Differential Revision: https://reviews.llvm.org/D68407
8548 CPU is GCC's name for the e500v2, so accept this in clang. The
e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as well,
as GCC does.
Differential Revision: https://reviews.llvm.org/D67787
This started passing target-features on the linker line, not just for RISCV but
for all targets, leading to error messages in Chromium Android build:
'+soft-float-abi' is not a recognized feature for this target (ignoring feature)
'+soft-float-abi' is not a recognized feature for this target (ignoring feature)
See Phabricator review for details.
Reverting until this can be fixed properly.
> Summary:
> 1. enable LTO need to pass target feature and abi to LTO code generation
> RISCV backend need the target feature to decide which extension used in
> code generation.
> 2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag
> 3. add general tools::getTargetABI in CommonArgs.h because different target uses different
> way to get the target ABI.
>
> Patch by Kuan Hsu Chen (khchen)
>
> Reviewers: lenary, lewis-revill, asb, MaskRay
>
> Reviewed By: lenary
>
> Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini, inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D67409
stevewan