JIT support for OpenMP offloading was introduced in D139287. This patch
adds a simple flag that enables this mode. It simply requires enabling
`-foffload-lto` mode and `--embed-bitcode` in the linker wrapper. This
option implies LTO if it is not enabled.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D141158
MC default was flipped in 2016.
CMake ENABLE_X86_RELAX_RELOCATIONS defaults to on in 2020 (c41a18cf61790fc898dcda1055c3efbf442c14c0).
It makes sense for the CodeGenOptions::RelaxELFRelocations to match, so
that most -cc1/-cc1as command lines won't have this option.
This also fixes a minor issue: -fno-plt -S will now use GOT for
__tls_get_addr calls, matching -fno-plt -c.
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.
The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e.
The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.
Differential Revision: https://reviews.llvm.org/D139881
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104
compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559bd38f337d7d35de35686775e8fb5175.
This reverts commit 06b90e2e9c991e211fecc97948e533320a825470.
This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
The option from D116070 does not work as intended and will not be needed when
hidden visibility is used. A function needs ENDBR if it may be reached
indirectly. If we make ThinLTO combine the address-taken property (close to
`!GV.use_empty() && !GV.hasAtLeastLocalUnnamedAddr()`), then the condition can
be expressed with:
`AddressTaken || (!F.hasLocalLinkage() && (VisibleToRegularObj || !F.hasHiddenVisibility()))`
The current `F.hasAddressTaken()` condition does not take into acount of
address-significance in another bitcode file or ELF relocatable file.
For the Linux kernel, it uses relocatable linking. lld/ELF uses a
conservative approach by setting all `VisibleToRegularObj` to true.
Using the non-relocatable semantics may under-estimate
`VisibleToRegularObj`. As @pcc mentioned on
https://github.com/ClangBuiltLinux/linux/issues/1737#issuecomment-1343414686
, we probably need a symbol list to supply additional
`VisibleToRegularObj` symbols (not part of the relocatable LTO link).
Reviewed By: samitolvanen
Differential Revision: https://reviews.llvm.org/D140363
This reverts commit 9739bb81aed490bfcbcbbac6970da8fb7232fd34.
It causes `.module is not permitted after generating code`
for Linux kernel's `ARCH=mips 32r1_defconfig` clang+GNU as build.
It's confirmed as a defect, but the proper fix needs time to sort out.
This reverts commit e43924a75145d2f9e722f74b673145c3e62bfd07.
Reason: Patch broke the MSan buildbots. More information is available on
the original phabricator review: https://reviews.llvm.org/D127812
Previously, we would be passing down -stdlib=libc++ from the Driver
to CC1 whenever the default standard library on the platform was libc++,
even if -stdlib= had not been passed to the Driver. This meant that we
would pass -stdlib=libc++ in nonsensical circumstances, such as when
compiling C code.
This logic had been added in b534ce46bd40 to make sure that header
search paths were set up properly. However, since libc++ is now the
default Standard Library on Darwin, passing this explicitly is not
required anymore. Indeed, if no -stdlib= is specified, CC1 will end
up using libc++ if it queries which standard library to use, without
having to be told.
Not passing -stdlib= at all to CC1 on Darwin should become possible
once CC1 stops relying on it to set up framework search paths.
Furthermore, this commit also removes a diagnostic checking whether the
deployment target is too old to support libc++. Nowadays, all supported
deployment targets use libc++ and compiling with libstdc++ is not
supported anymore. The Driver was the wrong place to issue this
diagnostic since it doesn't know whether libc++ will actually be linked
against (e.g. C vs C++), which would lead to spurious diagnostics.
Given that these targets are not supported anymore, we simply drop
the diagnostic instead of trying to refactor it into CC1.
This is a re-application of 6540f32db09c which had been reverted in
49dd02bd0819 because it broke a compiler-rt test. The test had broken
because we were compiling C code and passing -stdlib=libc++, which Clang
will now warn about.
rdar://103198514
Differential Revision: https://reviews.llvm.org/D139938
This broke the instrprof-darwin-exports.c test on mac, see e.g.
https://green.lab.llvm.org/green/job/clang-stage1-RA/32351/
> Previously, we would be passing down -stdlib=libc++ from the Driver
> to CC1 whenever the default standard library on the platform was libc++,
> even if -stdlib= had not been passed to the Driver. This meant that we
> would pass -stdlib=libc++ in nonsensical circumstances, such as when
> compiling C code.
>
> This logic had been added in b534ce46bd40 to make sure that header
> search paths were set up properly. However, since libc++ is now the
> default Standard Library on Darwin, passing this explicitly is not
> required anymore. Indeed, if no -stdlib= is specified, CC1 will end
> up using libc++ if it queries which standard library to use, without
> having to be told.
>
> Not passing -stdlib= at all to CC1 on Darwin should become possible
> once CC1 stops relying on it to set up framework search paths.
>
> Furthermore, this commit also removes a diagnostic checking whether the
> deployment target is too old to support libc++. Nowadays, all supported
> deployment targets use libc++ and compiling with libstdc++ is not
> supported anymore. The Driver was the wrong place to issue this
> diagnostic since it doesn't know whether libc++ will actually be linked
> against (e.g. C vs C++), which would lead to spurious diagnostics.
> Given that these targets are not supported anymore, we simply drop
> the diagnostic instead of trying to refactor it into CC1.
>
> rdar://103198514
>
> Differential Revision: https://reviews.llvm.org/D139938
This reverts commit 6540f32db09cf6b367812642fbd91d44cbb6638d.
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
Previously, we would be passing down -stdlib=libc++ from the Driver
to CC1 whenever the default standard library on the platform was libc++,
even if -stdlib= had not been passed to the Driver. This meant that we
would pass -stdlib=libc++ in nonsensical circumstances, such as when
compiling C code.
This logic had been added in b534ce46bd40 to make sure that header
search paths were set up properly. However, since libc++ is now the
default Standard Library on Darwin, passing this explicitly is not
required anymore. Indeed, if no -stdlib= is specified, CC1 will end
up using libc++ if it queries which standard library to use, without
having to be told.
Not passing -stdlib= at all to CC1 on Darwin should become possible
once CC1 stops relying on it to set up framework search paths.
Furthermore, this commit also removes a diagnostic checking whether the
deployment target is too old to support libc++. Nowadays, all supported
deployment targets use libc++ and compiling with libstdc++ is not
supported anymore. The Driver was the wrong place to issue this
diagnostic since it doesn't know whether libc++ will actually be linked
against (e.g. C vs C++), which would lead to spurious diagnostics.
Given that these targets are not supported anymore, we simply drop
the diagnostic instead of trying to refactor it into CC1.
rdar://103198514
Differential Revision: https://reviews.llvm.org/D139938
value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
This fixes clang.
The ClangBuiltLinux project relies on `-mcpu=405`. Before https://reviews.llvm.org/D139720, `clang` treated `-mcpu=405` implicitly in the same way as `-mcpu=generic`, because `405` was an unknown value and `clang` did not validate unknown input values. https://reviews.llvm.org/D139720 added the validation of `-mcpu` input value, and `clang` now generates an error with `-mcpu=405`. For further details of the problem, see https://github.com/ClangBuiltLinux/linux/issues/1771.
This patch adds support of `-mcpu=405` explicitly, and treats it as an equivalent of `-mcpu=generic`.
Reviewed By: nemanjai
Differential Revision: https://reviews.llvm.org/D140080
When we use llc or lld to compiler IR files, the features +nan2008 and +fpxx/+fp64 are not used.
Thus wrong format files are produced.
In IR files, the attributes are only set for function while not the whole compile units.
So we output `.nan 2008` and `.module fp=xx/64` before every function.
`isFPXXDefault`: for o32, the FPXX should always be the default, no matter about the vendors.
Of course some distributions with FP64 default enabled should be listed explicit.
Let's add them in future if we know about one.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D138179
This adds some SPARC feature flags to clang, for those that we have in common with GCC:
-m[no-]fpu
-m[no-]fsmuld
-m[no-]popc
-m[no-]vis
-m[no-]vis2
-m[no-]vis3
-m[hard/soft]-quad-float
All have the same meanings as GCC's options (https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html).
This fixes, among other things, the -mno-fpu part of bug #40792
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D139768
Reviewed by: vitalybuka, kito-cheng
These changes will allow to use HWASAN with RISCV64 architecture.
The majority of existing tests are passing with a few exceptions(see below).
The tests were running on QEMU, since currently there're no hardware with support
for J-extension.
For this feature to work the system must support PR_{SET,GET}_TAGGED_ADDR_CTRL
syscall. For now this is only available for a patched Linux kernel and QEMU with
enabled experimental J-extension.
Results of running HWASAN lit tests for RISC-V:
```
Unsupported : 6
Passed : 79
Expectedly Failed: 2
```
Tests are marked as expected to fail or unsupported either because of:
- android platform not being supported
- no support for legacy hwasan v1 mode
- test config explicitly uses aarch64 option
```
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/abort-message-android.cpp
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/cfi.cpp
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/lto.c
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/print-memory-usage-android.c
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/register-dump-read.c
UNSUPPORTED: HWAddressSanitizer-riscv64 :: TestCases/try-catch.cpp
XFAIL: HWAddressSanitizer-riscv64 :: TestCases/stack-oob.c
XFAIL: HWAddressSanitizer-riscv64 :: TestCases/exported-tagged-global.c
```
Differential Revision: https://reviews.llvm.org/D131345
When -mabi=ieeelongdouble is enabled by default, libc++ does not support
-mabi=ibmlongdouble.
Reviewed By: qiucf
Differential Revision: https://reviews.llvm.org/D139450
Currently `ppc::getPPCTargetCPU` returns an empty string when it encounters an unknown value passed to `-mcpu`. This causes `clang` to ignore unknown `-mcpu` values silently.
This patch changes the behaviour of `ppc::getPPCTargetCPU` so that it passes the unknown option to the target info, so the target info can actually check if the CPU string is supported, and report an error when encountering unknown/unsupported CPU string.
Reviewed By: jamieschmeiser
Differential Revision: https://reviews.llvm.org/D139720
This patch detects system GPU and use them
in --offload-arch if 'native' is specified. If system GPU
cannot be detected clang will fall back to the default GPU arch.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D139045
If you build compiler-rt with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR then
the library filename will be "libclang_rt.builtins.a" instead of
"libclang_rt.builtins-<ARCH>.a"
The ToolChain::getCompilerRT method uses the "libclang_rt.builtins.a"
name if it can find the file in the library directories. If it can't
then it falls back to using "libclang_rt.builtins-<ARCH>.a". This
change adds the library directory such that "libclang_rt.builtins.a"
can be found.
Differential Revision: https://reviews.llvm.org/D139822
The option does not change IR but affect object file generation. Without a
backend option the option is a no-op for in-process ThinLTO.
The problem is known and there are many options similar to -fstack-size-section.
That said, -fstack-size-section has relatively wider adoption, so it probably
makes sense to have custom code for it.
Close https://github.com/llvm/llvm-project/issues/59424
clang -cc1 accepts -Ofast. I did not add it to flang -fc1 because this
seems redundant because the compiler driver will always resolve -Ofast
into -O3 -ffast-math (I added a test for this).
-menable-infs is removed from the frontend-forwarding test because if
all of the fast-math component flags are present, these will be resolved
into the fast-math flag. Instead -menable-infs is tested in the
fast-math test.
Specifying -ffast-math to the compiler driver causes linker invocations
to include crtfastmath.o.
RFC: https://discourse.llvm.org/t/rfc-the-meaning-of-ofast/66554
Differential Revision: https://reviews.llvm.org/D138675
Allow TSan in clang driver for X86_64 WatchOS simulator.
It was already functional, and Apple's downstream fork of clang allows it, but that change had not made it upstream yet.
Reviewed By: jyknight, yln
Differential Revision: https://reviews.llvm.org/D139652
This patch enabled tsan for loongarch64 with 47-bit VMA layout. All
tests are passing.
Also adds assembly routines to enable setjmp/longjmp for loongarch64
on linux.
Reviewed By: dvyukov, SixWeining, #sanitizers
Differential Revision: https://reviews.llvm.org/D138489
usage information in JSON to a file
Each line in the file is a JSON object that has the name of the main
source file followed by the list of system header files included
directly or indirectly from that file.
For example:
{"source":"/tmp/foo.c",
"includes":["/usr/include/stdio.h", "/usr/include/stdlib.h"]}
To reduce the amount of data written to the file, only the system
headers that are directly included from a non-system header file are
recorded.
In order to emit the header information in JSON, it is necessary to set
the following environment variables:
CC_PRINT_HEADERS_FORMAT=json CC_PRINT_HEADERS_FILTERING=only-direct-system
The following combination is equivalent to setting CC_PRINT_HEADERS=1:
CC_PRINT_HEADERS_FORMAT=textual CC_PRINT_HEADERS_FILTERING=none
Differential Revision: https://reviews.llvm.org/D137996
