aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Driver/Driver.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-07-28[Driver] -###: exit with code 1 if hasErrorOccurredFangrui Song1-1/+1
The exit code for -### is inconsistent. Unrecognized options lead to exit code 1, as expected. However, most others errors (including invalid option value) lead to exit code 0, differing from GCC and most utilities. This is a longstanding quirk of -###, and we didn't fix it because many driver tests need adjustment. Change -### to be similar to -fdriver-only -v and exit with code 1. This requires fixing many driver tests, but the end result gives us stronger tests. * Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`. If a change introduces an error, such a change usually cannot be detected. * Many folks contributing new tests don't know `-fdriver-only -v`. To test no driver error/warning for new tests, they can use the familiar `-### -Werror` instead of `-fdriver-only -v -Werror`. Reviewed By: jhuber6, yaxunl, dblaikie Differential Revision: https://reviews.llvm.org/D156363
2023-07-20[Driver] -fopenmp-targets=: stabilize OrderedOffloadingToolchains value orderFangrui Song1-4/+5
to make actions deterministic. StringSet iteration order is not guaranteed to be deterministic (https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).
2023-07-19Revert "[OptTable] Make explicitly included options override excluded ones"Justin Bogner1-0/+4
Looks like a couple of flang bots are broken by this change. Reverting to investigate. This reverts commit b2eda85f047f27788ccd7b9af9bd59c5d44b2051.
2023-07-19[OptTable] Make explicitly included options override excluded onesJustin Bogner1-4/+0
When we have both explicitly included and excluded option sets, we were excluding anything from the latter set regardless of what was in the former. This doesn't compose well and led to an overly complicated design around DXC options where a third flag was introduced to handle options that overlapped between DXC and CL. With this change we check the included options before excluding anything from the exclude list, which allows for options that are in multiple categories to be handled in a sensible way. This allows us to remove CLDXCOption but should otherwise be NFC. Differential Revision: https://reviews.llvm.org/D155729
2023-07-19[ThinLTO][AIX] Enable thinlto on AIXWael Yehia1-2/+0
Starting from AIX 7.2 TL5 SP6 and AIX 7.3 TL2 the system linker supports thinLTO. Reviewed By: ZarkoCA, MaskRay Differential Revision: https://reviews.llvm.org/D155700
2023-07-18[Clang] Only emit CUDA version warnings when creating the CUDA toolchainJoseph Huber1-0/+6
This warning primarily applies to users of the CUDA langues as there may be new features we rely on. The other two users of the toolchain are OpenMP via `-fopenmp --offload-arch=sm_70` and a cross-compiled build via `--target=nvptx64-nvida-cuda -march=sm_70`. Both of these do not rely directly on things that would change significantly between CUDA versions, and the way they are built can sometims make this warning print many times. This patch changees the behaiour to only check for the version when building for CUDA offloading specifically, the other two will not have this check. Reviewed By: tra Differential Revision: https://reviews.llvm.org/D155606
2023-07-17[HIP] Ignore host linker flags for device-onlySiu Chi Chan1-2/+4
When compiling in device only mode (e.g. --offload-device-only), the host linker phase would not happen and therefore, the driver should ignore all the host linker flags. Differential Revision: https://reviews.llvm.org/D154881 Change-Id: I8244acef5c33108cf15b1dbb188f974f30099718
2023-07-17[clang] Preliminary fat-lto-object supportPaul Kirth1-2/+7
Fat LTO objects contain both LTO compatible IR, as well as generated object code. This allows users to defer the choice of whether to use LTO or not to link-time. This is a feature available in GCC for some time, and makes the existing -ffat-lto-objects flag functional in the same way as GCC's. This patch adds support for that flag in the driver, as well as setting the necessary codegen options for the backend. Largely, this means we select the newly added pass pipeline for generating fat objects. Users are expected to pass -ffat-lto-objects to clang in addition to one of the -flto variants. Without the -flto flag, -ffat-lto-objects has no effect. // Compile and link. Use the object code from the fat object w/o LTO. clang -fno-lto -ffat-lto-objects -fuse-ld=lld foo.c // Compile and link. Select full LTO at link time. clang -flto -ffat-lto-objects -fuse-ld=lld foo.c // Compile and link. Select ThinLTO at link time. clang -flto=thin -ffat-lto-objects -fuse-ld=lld foo.c // Compile and link. Use ThinLTO with the UnifiedLTO pipeline. clang -flto=thin -ffat-lto-objects -funified-lto -fuse-ld=lld foo.c // Compile and link. Use full LTO with the UnifiedLTO pipeline. clang -flto -ffat-lto-objects -funified-lto -fuse-ld=lld foo.c // Link separately, using ThinLTO. clang -c -flto=thin -ffat-lto-objects foo.c clang -flto=thin -fuse-ld=lld foo.o -ffat-lto-objects # pass --lto=thin --fat-lto-objects to ld.lld // Link separately, using full LTO. clang -c -flto -ffat-lto-objects foo.c clang -flto -fuse-ld=lld foo.o # pass --lto=full --fat-lto-objects to ld.lld Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977 Depends on D146776 Reviewed By: tejohnson, MaskRay Differential Revision: https://reviews.llvm.org/D146777
2023-07-14[LLD][COFF] Add LLVM toolchain library paths by default.Tobias Hieta1-0/+2
We want lld-link to automatically find compiler-rt's and libc++ when it's in the same directory as the rest of the toolchain. This is because on Windows linking isn't done via the clang driver - but instead invoked directly. This prepends: <llvm>/lib <llvm>/lib/clang/XX/lib and <llvm>/lib/clang/XX/lib/windows automatically to the library search paths. Related to #63827 Differential Revision: https://reviews.llvm.org/D151188
2023-07-13[Driver] Warn about -mios-version-min instead of erroring out whenAkira Hatanaka1-2/+3
targeting MachO embedded architectures Sometimes users pass this option when targeting embedded architectures like armv7m on non-darwin platforms. Emit a warning instead of erroring out, which restores the behavior prior to 34d7acd444b88342fc93fca202608c1e16fa5946.
2023-06-29[HIP]: Add -fhip-emit-relocatable to override link job creation for -fno-gpu-rdcJeffrey Byrnes1-10/+41
Differential Revision: https://reviews.llvm.org/D153667 Change-Id: Idcc5c7c25dc350b8dc9a1865fd67982904d06ecd
2023-06-26Reland [COFF] Support -gsplit-dwarf for COFF on WindowsHaohai Wen1-4/+5
This relands 3eee5aa528abd67bb6d057e25ce1980d0d38c445 with fixes.
2023-06-25Revert "[COFF] Support -gsplit-dwarf for COFF on Windows"Nico Weber1-5/+4
This reverts commit 3eee5aa528abd67bb6d057e25ce1980d0d38c445. Breaks tests on mac, see https://reviews.llvm.org/D152785#4447118
2023-06-25[COFF] Support -gsplit-dwarf for COFF on WindowsHaohai Wen1-4/+5
D152340 has split WinCOFFObjectWriter to WinCOFFWriter. This patch adds another WinCOFFWriter as DwoWriter to write Dwo sections to dwo file. Driver options are also updated accordingly to support -gsplit-dwarf in CL mode. e.g. $ clang-cl -c -gdwarf -gsplit-dwarf foo.c Like what -gsplit-dwarf did in ELF, using this option will create DWARF object (.dwo) file. DWARF debug info is split between COFF object and DWARF object file. It can reduce the executable file size especially for large project. Reviewed By: skan, MaskRay Differential Revision: https://reviews.llvm.org/D152785
2023-06-23[Clang][Driver] Warn on invalid Arm or AArch64 baremetal target tripleMichael Platings1-0/+30
A common user mistake is specifying a target of aarch64-none-eabi or arm-none-elf whereas the correct names are aarch64-none-elf & arm-none-eabi. Currently if a target of aarch64-none-eabi is specified then the Generic_ELF toolchain is used, unlike aarch64-none-elf which will use the BareMetal toolchain. This is unlikely to be intended by the user so issue a warning that the target is invalid. The target parser is liberal in what input it accepts so invalid triples may yield behaviour that's sufficiently close to what the user intended. Therefore invalid triples were used in many tests. This change updates those tests to use valid triples. One test (gnu-mcount.c) relies on the Generic_ELF toolchain behaviour so change it to explicitly specify aarch64-unknown-none-gnu as the target. Reviewed By: peter.smith, DavidSpickett Differential Revision: https://reviews.llvm.org/D153430
2023-06-16[Driver] Allow warning for unclaimed TargetSpecific optionsFangrui Song1-1/+2
For unclaimed target-agnostic options, we can apply clang_ignored_gcc_optimization_f_Group to accept but warn about them. ``` % clang -c -fexpensive-optimizations a.c clang: warning: optimization flag '-fexpensive-optimizations' is not supported [-Wignored-optimization-argument] ``` For an unclaimed target-specific option, one target may want to accept but warn about it. Add `llvm::opt::Arg::IgnoredTargetSpecific` to support this warning need. Close https://github.com/llvm/llvm-project/issues/63282 Reviewed By: mstorsjo Differential Revision: https://reviews.llvm.org/D152856
2023-06-15[OpenMP] Correctly diagnose conflicting target identifierers for AMDGPUJoseph Huber1-3/+4
There are static checks on the target identifiers allowed in a single TU. Previously theses checks were only applied to HIP even though they should be the same for OpenMP targeting AMDGPU. Simply enable these checks for OpenMP. Reviewed By: JonChesterfield, yaxunl Differential Revision: https://reviews.llvm.org/D152965
2023-06-14[Driver] Enable selecting multiple multilibsMichael Platings1-7/+8
This will enable layering multilibs on top of each other. For example a multilib containing only a no-exceptions libc++ could be layered on top of a multilib containing C libs. This avoids the need to duplicate the C library for every libc++ variant. This change doesn't expose the functionality externally, it only opens the functionality up to be potentially used by ToolChain classes. Differential Revision: https://reviews.llvm.org/D143059
2023-06-14[Driver] Add -print-multi-flags-experimental optionMichael Platings1-0/+11
This option causes the flags used for selecting multilibs to be printed. This is an experimental feature that is documented in detail in D143587. Differential Revision: https://reviews.llvm.org/D142933
2023-06-08[Driver] Make -G TargetSpecificFangrui Song1-7/+2
so that we report `unsupported option '-G' for target ...` on unsupported targets (most targets). This error is tested by one target in aix-err-options.c. Follow-up to D89897 and D90063.
2023-05-30[Driver] Report error for unsupported -mlarge-endian/-mlittle-endianFangrui Song1-10/+8
2023-05-30[Driver] Add ClangFlags::TargetSpecific to simplify ↵Fangrui Song1-3/+9
err_drv_unsupported_opt_for_target processing clang/lib/Driver/ToolChains/Clang.cpp has a lot of fragments like the following: ``` if (const Arg *A = Args.getLastArg(...)) { if (Triple is xxx) A->render(Args, CmdArgs); else D.Diag(diag::err_drv_unsupported_opt_for_target) << ...; } ``` The problem is more apparent with a recent surge of AIX-specific options. Introduce the TargetSpecific flag so that we can move the target-specific options to ToolChains/*.cpp and ToolChains/Arch/*.cpp and overload the warn_drv_unused_argument mechanism to give an err_drv_unsupported_opt_for_target error. Migrate -march=/-mcpu= and some AIX-specific options to use this simplified pattern. Reviewed By: jansvoboda11 Differential Revision: https://reviews.llvm.org/D151590
2023-05-16Migrate {starts,ends}with_insensitive to {starts,ends}_with_insensitive (NFC)Kazu Hirata1-3/+3
This patch migrates uses of StringRef::{starts,ends}with_insensitive to StringRef::{starts,ends}_with_insensitive so that we can use names similar to those used in std::string_view. Note that the llvm/ directory has migrated in commit 6c3ea866e93003e16fc55d3b5cedd3bc371d1fde. I'll post a separate patch to deprecate StringRef::{starts,ends}with_insensitive. Differential Revision: https://reviews.llvm.org/D150506
2023-05-15Add C++26 compile flags.Erich Keane1-0/+1
Now that we've updated to C++23, we need to add C++26/C++2c command line flags, as discussed in https://discourse.llvm.org/t/rfc-lets-just-call-it-c-26-and-forget-about-the-c-2c-business-at-least-internally/70383 Differential Revision: https://reviews.llvm.org/D150450
2023-05-12[Driver] -ftime-trace: derive trace file names from -o and -dumpdirFangrui Song1-0/+33
Inspired by D133662. Close https://github.com/llvm/llvm-project/issues/57285 When -ftime-trace is specified and the driver performs both compilation and linking phases, the trace files are currently placed in the temporary directory (/tmp by default on *NIX). A more sensible behavior would be to derive the trace file names from the -o option, similar to how GCC derives auxiliary and dump file names. Use -dumpdir (D149193) to implement the -gsplit-dwarf like behavior. The following script demonstrates the time trace filenames. ``` #!/bin/sh -e PATH=/tmp/Rel/bin:$PATH # adapt according to your build directory mkdir -p d e f echo 'int main() {}' > d/a.c echo > d/b.c a() { rm $1 || exit 1; } clang -ftime-trace d/a.c d/b.c # previously /tmp/[ab]-*.json a a-a.json; a a-b.json clang -ftime-trace d/a.c d/b.c -o e/x # previously /tmp/[ab]-*.json a e/x-a.json; a e/x-b.json clang -ftime-trace d/a.c d/b.c -o e/x -dumpdir f/ a f/a.json; a f/b.json clang -ftime-trace=f d/a.c d/b.c -o e/x a f/a-*.json; a f/b-*.json clang -c -ftime-trace d/a.c d/b.c a a.json b.json clang -c -ftime-trace=f d/a.c d/b.c a f/a.json f/b.json clang -c -ftime-trace d/a.c -o e/xa.o a e/xa.json clang -c -ftime-trace d/a.c -o e/xa.o -dumpdir f/g a f/ga.json ``` The driver checks `-ftime-trace` and `-ftime-trace=`, infers the trace file name, and passes `-ftime-trace=` to cc1. The `-ftime-trace` cc1 option is removed. With offloading, previously `-ftime-trace` is passed to all offloading actions, causing the same trace file to be overwritten by host and offloading actions. This patch doesn't attempt to support offloading (D133662), but makes a sensible change (`OffloadingPrefix.empty()`) to ensure we don't overwrite the trace file. Minor behavior differences: the trace file is now a result file, which will be removed upon an error. -ftime-trace-granularity=0, like -ftime-trace, can now cause a -Wunused-command-line-argument warning. Reviewed By: Maetveis Differential Revision: https://reviews.llvm.org/D150282
2023-05-09[Driver] Add -dumpdir and change -gsplit-dwarf .dwo names for linkingFangrui Song1-0/+15
When the final phase is linking, Clang currently places `.dwo` files in the current directory (like the `-c` behavior for multiple inputs). Strangely, -fdebug-compilation-dir=/-ffile-compilation-dir= is considered, which is untested. GCC has a more useful behavior that derives auxiliary filenames from the final output (-o). ``` gcc -c -g -gsplit-dwarf d/a.c d/b.c # a.dwo b.dwo gcc -g -gsplit-dwarf d/a.c d/b.c -o e/x # e/x-a.dwo e/x-b.dwo gcc -g -gsplit-dwarf d/a.c d/b.c # a-a.dwo a-b.dwo ``` Port a useful subset of GCC behaviors that are easy to describe to Clang. * Add a driver and cc1 option -dumpdir * When the final phase is link, add a default -dumpdir if not specified by the user * Forward -dumpdir to -cc1 command lines * tools::SplitDebugName prefers -dumpdir when constructing the .dwo filename GCC provides -dumpbase. If we use just one of -dumpdir and -dumpbase, -dumpbase isn't very useful as it appends a dash. ``` gcc -g -gsplit-dwarf -dumpdir e d/a.c # ea.dwo gcc -g -gsplit-dwarf -dumpdir e/ d/a.c # e/a.dwo gcc -g -gsplit-dwarf -dumpbase e d/a.c # e-a.dwo gcc -g -gsplit-dwarf -dumpbase e/ d/a.c # e/-a.dwo ``` If we specify both `-dumpdir` and `-dumpbase`, we can avoid the influence of the source filename when there is one input file. ``` gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c # f/x.dwo gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c d/b.c # f/x-a.dwo f/x-b.dwo ``` Given the above examples, I think -dumpbase is not useful. GCC -save-temps has interesting interaction with -dumpdir as -save-temps generated files are considered auxiliary files like .dwo files. For Clang, with this patch, -save-temps and -dumpdir are orthogonal, which is easier to explain. ``` gcc -g -gsplit-dwarf d/a.c -o e/x -dumpdir f/ -save-temps=obj # e/a.{i,s,o,dwo} gcc -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # f/a.{i,s,o,dwo} clang -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # e/a.{i,s,o} f/a.dwo ``` Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D149193
2023-05-04[clang] Use -std=c++23 instead of -std=c++2bMark de Wever1-2/+3
During the ISO C++ Committee meeting plenary session the C++23 Standard has been voted as technical complete. This updates the reference to c++2b to c++23 and updates the __cplusplus macro. Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D149553
2023-04-27[RISCV][Driver] Allow the use of CPUs with a different XLEN than the triple.Kito Cheng1-2/+4
Our downstream toolchain release got some issue is we set the default triple by creating symbolic link of clang like `riscv64-unknown-elf-clang`, and has lots of multi-lib config including rv32's config. However when we trying to set arch by a 32 bit CPU like generic-rv32 but got error message below: error: unsupported argument 'generic-rv32' to option '-mcpu=' `generic-rv32` is listed in the output of `-mcpu=help`, that might be confusing for user since help message say supported. So let clang driver also consider -mcpu option during computing the target triple to archvie that. Reviewed By: asb, craig.topper Differential Revision: https://reviews.llvm.org/D148124
2023-04-24[Driver] Remove no-op -frewrite-map-file=Fangrui Song1-3/+0
This option has been a no-op since D99707.
2023-04-23[Driver][NFC] Simplify code.Jianjian GUAN1-6/+5
Reviewed By: benshi001, jhuber6 Differential Revision: https://reviews.llvm.org/D148908
2023-03-20[LLVM][OHOS] Clang toolchain and targetsPavel Kosov1-1/+6
Add a clang part of OpenHarmony target Related LLVM part: D138202 ~~~ Huawei RRI, OS Lab Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D145227
2023-03-16[Driver] Allow to collect `-save-stats` data to a file specified in the ↵Volodymyr Sapsai1-2/+3
environment variable. Using two environment variables `CC_PRINT_INTERNAL_STAT` and `CC_PRINT_INTERNAL_STAT_FILE` to work like `CC_PRINT_PROC_STAT`. The purpose of the change is to allow collecting the internal stats without modifying the build scripts. Write all stats to a single file to simplify aggregating the data. Differential Revision: https://reviews.llvm.org/D144981
2023-03-14[clang] Use *{Set,Map}::contains (NFC)Kazu Hirata1-2/+2
2023-03-14Revert "[LLVM][OHOS] Clang toolchain and targets"Daniel Thornburgh1-6/+1
This change had tests that break whenever LLVM_ENABLE_LINKER_BUILD_ID is set, as is the case in the Fuchsia target. This reverts commits: f81317a54586dbcef0c14cf512a0770e8ecaab3d 72474afa27570a0a1307f3260f0187b703aa6d84
2023-03-14[LLVM][OHOS] Clang toolchain and targetsPavel Kosov1-1/+6
Add a clang part of OpenHarmony target Related LLVM part: D138202 ~~~ Huawei RRI, OS Lab Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D145227
2023-03-13[clang][deps] Handle response files in dep scannerBen Langmuir1-0/+55
Extract the code the driver uses to expand response files and reuse it in the dependency scanner. rdar://106155880 Differential Revision: https://reviews.llvm.org/D145838
2023-03-13[clang][driver] accept maix32/maix64 gcc compat optionsDavid Tenty1-3/+12
GCC on AIX primarily uses the -maix32 and -maix64 to select the bitmode to target. In order to be compatible with existing build configurations, clang should accept these options as well. In this patch we implement these options for AIX targets. Differential Revision: https://reviews.llvm.org/D145610
2023-03-09[HIP] Fix temporary filesYaxun (Sam) Liu1-5/+21
Currently HIP toolchain uses Driver::GetTemporaryDirectory to create a temporary directory for some temporary files during compilation. The temporary directories are not automatically deleted after compilation. This slows down compilation on Windows. Switch to use GetTemporaryPath which only creates temporay files which will be deleted automatically. Keep the original input file name convention for Darwin host toolchain since it is needed for deterministic binary (https://reviews.llvm.org/D111269) Fixes: SWDEV-386058 Reviewed by: Artem Belevich Differential Revision: https://reviews.llvm.org/D145509
2023-02-10[llvm-driver] Reinvoke clang as described by llvm driver extra argsAlex Brachet1-1/+1
Differential Revision: https://reviews.llvm.org/D137800
2023-02-10[NFC][TargetParser] Replace uses of llvm/Support/Host.hArchibald Elliott1-1/+1
The forwarding header is left in place because of its use in `polly/lib/External/isl/interface/extract_interface.cc`, but I have added a GCC warning about the fact it is deprecated, because it is used in `isl` from where it is included by Polly.
2023-02-09[Support] Emulate SIGPIPE handling in raw_fd_ostream write for WindowsAndrew Ng1-3/+1
Prevent errors and crash dumps for broken pipes on Windows. Fixes: https://github.com/llvm/llvm-project/issues/48672 Differential Revision: https://reviews.llvm.org/D142224
2023-02-02[clang][driver] Emit an error for `/clang:-x`Mariya Podchishchaeva1-5/+9
`/clang:-x` emits an error instead of a warning. And if the error is suppressed, `/clang:-x` takes no effect. Considering that `/clang:` is a recent addition in 2018-11 and there are MSVC style alternatives, therefore `/clang:-x` doesn't seem useful and we just reject it since properly supporting it would add lots of complexity. Fixes #59307 Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D142757
2023-02-01[HLSL] [Dirver] add dxv as a VerifyDebug JobXiang Li1-0/+13
New option --dxv-path is added for dxc mode to set the installation path for dxv. If cannot find dxv, a warning will be report. dxv will be executed with command line dxv file_name -o file_name. It will validate and sign the file and overwrite it. Differential Revision: https://reviews.llvm.org/D141705
2023-01-24[Clang] Only emit textual LLVM-IR in device only modeJoseph Huber1-1/+8
Currently, we embed device code into the host to perform multi-architecture linking and handling of device code. If the user specified `-S -emit-llvm` then the embedded output will be textual LLVM-IR. This is a problem because it can't be used by the LTO backend and it makes reading the file confusing. This patch changes the behaviour to only emit textual device IR if we are in device only mode, that is, if the device code is presented directly to the user instead of being embedded. Otherwise we should always embed device bitcode instead. Reviewed By: tra Differential Revision: https://reviews.llvm.org/D141717
2023-01-22[HIP] Change default offload arch to gfx906Yaxun (Sam) Liu1-1/+1
Reviewed by: Artem Belevich Differential Revision: https://reviews.llvm.org/D142246
2023-01-19Optimize OptTable::findNearest implementation and usageserge-sans-paille1-4/+4
When used to find an exact match, some extra context can be used to totally cut some computations. This saves 1% of the instruction count when pre processing sqlite3.c through valgrind --tool=callgrind ./bin/clang -E sqlite3.c -o/dev/null Differential Revision: https://reviews.llvm.org/D142026
2023-01-18[CUDA] Allow targeting NVPTX directly without a host toolchainJoseph Huber1-5/+3
Currently, the NVPTX compilation toolchain can only be invoked either through CUDA or OpenMP via `--offload-device-only`. This is because we cannot build a CUDA toolchain without an accompanying host toolchain for the offloading. When using `--target=nvptx64-nvidia-cuda` this results in generating calls to the GNU assembler and linker, leading to errors. This patch abstracts the portions of the CUDA toolchain that are independent of the host toolchain or offloading kind into a new base class called `NVPTXToolChain`. We still need to read the host's triple to build the CUDA installation, so if not present we just assume it will match the host's system for now, or the user can provide the path explicitly. This should allow the compiler driver to create NVPTX device images directly from C/C++ code. Reviewed By: tra Differential Revision: https://reviews.llvm.org/D140158
2023-01-16[Driver] [C++20] [Modules] Support -fmodule-output= (2/2)Chuanqi Xu1-6/+17
The patch implements `-fmodule-output=`. This is helpful if the build systems want to generate these output files in other places which is not the same with -o specified or the input file lived. Reviewed By: dblaikie, iains Differential Revision: https://reviews.llvm.org/D137059
2023-01-16[Driver] [Modules] Support -fmodule-output (1/2)Chuanqi Xu1-2/+36
Patches to support the one-phase compilation model for modules. The behavior: (1) If -o and -c is specified , the module file is in the same path within the same directory as the output the -o specified and with a new suffix .pcm. (2) Otherwise, the module file is in the same path within the working directory directory with the name of the input file with a new suffix .pcm For example, ``` Hello.cppm Use.cpp ``` A trivial one and the contents are ignored. When we run: ``` clang++ -std=c++20 -fmodule-output Hello.cppm -c ``` The directory would look like: ``` Hello.cppm Hello.o Hello.pcm Use.cpp ``` And if we run: ``` clang++ -std=c++20 -fmodule-output Hello.cppm -c -o output/Hello.o ``` Then the `output` directory may look like: ``` Hello.o Hello.pcm ``` Reviewed By: dblaikie, iains, tahonermann Differential Revision: https://reviews.llvm.org/D137058
2023-01-11[OpenMP] Fix unused capature and nameJoseph Huber1-3/+3
Summary: This capture isn't used, get rid of it and change the name since it's more generic now.
generated by cgit v1.1 at 2025-10-13 02:15:24 +0000