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
Previously we returned i32 on RV32 and i64 on RV64. The instructions
only consume 32 bits and only produce 32 bits. For RV64, the result
is sign extended to 64 bits like *W instructions.
This patch removes this detail from the interface to improve
portability and consistency. This matches the proposal for scalar
intrinsics here https://github.com/riscv-non-isa/riscv-c-api-doc/pull/44
I've included IR autoupgrade support as well.
I'll be doing this for other builtins/intrinsics that currently use
'long' in other patches.
Reviewed By: VincentWu
Differential Revision: https://reviews.llvm.org/D154647
The ObjC-block detection code only supports a single token as the return type. Add support to detect pointers, too (ObjC has lots of object-pointers).
For example, using `BasedOnStyle: WebKit`, the following is stable output:
```
int* p = ^int*(void)
{ //
return nullptr;
}
();
```
After the patch, this is stable:
```
int* p = ^int*(void) { //
return nullptr;
}();
```
Differential Review: https://reviews.llvm.org/D146434
We don't have any code to point at here, so the diagnostics would just
point to the record declaration. Make them point to the call site
intead.
Differential Revision: https://reviews.llvm.org/D154761
Commit 98390ccb80569e8fbb20e6c996b4b8cff87fbec6 fixed late template
instantiation by clearing FP pragma stack before instantiation. This
solution was based on the assumptions:
- FP pragma stack is not used anymore and it is safe to clear it,
- Default FP options are determined by command line options.
Both the assumptions are wrong. When compilation produces precompiled
header file, state of the stack is serialized and then restored when the
precompiled header is used. Delayed template parsing occurs at the end
of translation unit but before serialization, so clearing FP pragma
stack effects serialized representation. When the precompiled file is
loaded, some conditions can be broken and clang crashed, it was
described in https://github.com/llvm/llvm-project/issues/63704. The
crash was observed only in few cases, on most buildbots it was absent.
The violation of expected conditions was caused by violation of the
second assumption. FPEvalMethod can be modified by target, so it is not
possible to deduce it from LangOptions only. So default FP state read
from precompiled header was different from the state in the initialized
Sema, and this was the crash reason.
Only two targets do such modification of default FP options, these are
i386 and AIX. so the problem was hard to reproduce.
Delayed template parsing should occur with empty pragma stack, so it
must be cleared before the instantiation, but the stack now is saved
and restored after the instantiation is done.
This change should fix https://github.com/llvm/llvm-project/issues/63704.
Differential Revision: https://reviews.llvm.org/D155380
Besides being a useful abstraction, this function will help insulate existing clients of the framework from upcoming changes to the API of `StructValue` and `AggregateStorageLocation`.
Depends On D155202
Reviewed By: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D155204
The argument and return value of `std::forward` is always a reference, so we can simply forward the storage location.
Depends On D155075
Reviewed By: ymandel, gribozavr2, xazax.hun
Differential Revision: https://reviews.llvm.org/D155202
This consolidates the code used in various places to initialize objects (usually for variables) into one central location.
It will also help reduce the number of changes needed when we make the upcoming API changes to `AggregateStorageLocation` and `StructValue`.
Depends On D155074
Reviewed By: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D155075
Follow-up to D155123, uniformly handle cases where there are duplicate
-mios-verion-min arguments.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D155407
In https://reviews.llvm.org/D126664, a warning is introduced
warning against the deprecated out of line definition of a
static constexpr member in C++17 and later. Prior to this patch,
the only diagnostic group controlling this diagnostic was -Wdeprecated,
which controls many many diagnostics. This patch creates
a diagnostic group specifically for this warning so it can
be controlled in isolation, while also being included with -Wdeprecated.
Differential Revision: https://reviews.llvm.org/D153881
This patch adds a new option -fkeep-persistent-storage-variables to emit
all variables that have a persistent storage duration, including global,
static and thread-local variables. This could be useful in cases where
the presence of all these variables as symbols in the object file are
required, so that they can be directly addressed.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D150221
Unsigned is a better representation for bitmanipulation and cryptography.w
The only exception being the return values for clz and ctz intrinsics is
a signed int. That matches the target independent clz and ctz builtins.
This is consistent with the current scalar crypto proposal
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/44
Reviewed By: VincentWu
Differential Revision: https://reviews.llvm.org/D154616
The operator keyword preceded by a template closer should be annotated as
TT_FunctionDeclarationName.
Fixes#63879.
Differential Revision: https://reviews.llvm.org/D155358
This removes another use of 'long' to mean xlen from builtins.
I've also converted the types to unsigned as proposed in D154616.
clmul_32 is available to RV64 as its emulation is clmul+sext.w
clmulh_32 and clmulr_32 are not available on RV64 as their emulation
is currently 6 instructions in the worst case.
This showed up when we started to deduce readnone for the argument of
__kmpc_global_thread_num. The known attributes for "getters" did not
allow to read arguments, but that is sometimes the case.
In C++ we are not allowed to use designated initializers to initialize fields
out of order. In some cases when diagnosing this we are crashing because we are
not indexing correctly and therefore going out of bounds.
This fixes: https://github.com/llvm/llvm-project/issues/63605
Differential Revision: https://reviews.llvm.org/D154675
OpenCL and HIP have -cl-fp32-correctly-rounded-divide-sqrt and
-fno-hip-correctly-rounded-divide-sqrt. The corresponding fpmath metadata
was only set on fdiv, and not sqrt. The backend is currently underutilizing
sqrt lowering options, and the responsibility is split between the libraries
and backend and this metadata is needed.
CUDA/NVCC has -prec-div and -prev-sqrt but clang doesn't appear to be
aiming for compatibility with those. Don't know if OpenMP has a similar
control.
For a fix-it that inserts the `[[clang::unsafe_buffer_usage]]`
attribute, it will lookup existing macros defined for the attribute
and use the (last defined such) macro directly. Fix-its will use raw
`[[clang::unsafe_buffer_usage]]` if no such macro is defined.
The implementation mimics how a similar machine for the
`[[fallthrough]]` attribute was implemented.
Reviewed by: NoQ (Artem Dergachev)
Differential revision: https://reviews.llvm.org/D150338
This reverts commit 245d10b7a2c12ec25e7b5860a38c61991543a739 which causes
errors like the ones below on slightly older versions of clang:
```
In file included from .../clang/lib/AST/Interp/Source.h:17:
In file included from .../llvm/include/llvm/ADT/PointerUnion.h:19:
In file included from .../llvm/include/llvm/ADT/PointerIntPair.h:18:
.../llvm/include/llvm/Support/PointerLikeTypeTraits.h:61:28: error: invalid application of 'alignof' to an incomplete type 'clang::Decl'
61 | detail::ConstantLog2<alignof(T)>::value;
| ^~~~~~~~~~
.../llvm/include/llvm/Support/PointerLikeTypeTraits.h:101:56: note: in instantiation of static data member 'llvm::PointerLikeTypeTraits<clang::Decl *>::NumLowBitsAvailable' requested here
101 | static constexpr int NumLowBitsAvailable = NonConst::NumLowBitsAvailable;
| ^
.../llvm/include/llvm/ADT/PointerUnion.h:38:54: note: in instantiation of static data member 'llvm::PointerLikeTypeTraits<const clang::Decl *>::NumLowBitsAvailable' requested here
38 | return std::min<int>({PointerLikeTypeTraits<Ts>::NumLowBitsAvailable...});
| ^
.../llvm/include/llvm/ADT/PointerUnion.h:52:48: note: in instantiation of function template specialization 'llvm::pointer_union_detail::lowBitsAvailable<const clang::Decl *, const clang::Stmt *>' requested here
52 | static constexpr int NumLowBitsAvailable = lowBitsAvailable<PTs...>();
| ^
.../llvm/include/llvm/ADT/PointerIntPair.h:169:28: note: in instantiation of static data member 'llvm::pointer_union_detail::PointerUnionUIntTraits<const clang::Decl *, const clang::Stmt *>::NumLowBitsAvailable' requested here
169 | static_assert(PtrTraits::NumLowBitsAvailable <
| ^
.../llvm/include/llvm/ADT/PointerIntPair.h:111:13: note: in instantiation of template class 'llvm::PointerIntPairInfo<void *, 1, llvm::pointer_union_detail::PointerUnionUIntTraits<const clang::Decl *, const clang::Stmt *>>' requested here
111 | Value = Info::updateInt(Info::updatePointer(0, PtrVal),
| ^
.../llvm/include/llvm/ADT/PointerIntPair.h:89:5: note: in instantiation of member function 'llvm::PointerIntPair<void *, 1, int, llvm::pointer_union_detail::PointerUnionUIntTraits<const clang::Decl *, const clang::Stmt *>>::setPointerAndInt' requested here
89 | setPointerAndInt(PtrVal, IntVal);
| ^
.../llvm/include/llvm/ADT/PointerUnion.h:77:16: note: in instantiation of member function 'llvm::PointerIntPair<void *, 1, int, llvm::pointer_union_detail::PointerUnionUIntTraits<const clang::Decl *, const clang::Stmt *>>::PointerIntPair' requested here
77 | : Base(ValTy(const_cast<void *>(
| ^
.../clang/lib/AST/Interp/Source.h:76:31: note: in instantiation of member function 'llvm::pointer_union_detail::PointerUnionMembers<llvm::PointerUnion<const clang::Decl *, const clang::Stmt *>, llvm::PointerIntPair<void *, 1, int, llvm::pointer_union_detail::PointerUnionUIntTraits<const clang::Decl *, const clang::Stmt *>>, 1, const clang::Stmt *>::PointerUnionMembers' requested here
76 | SourceInfo(const Stmt *E) : Source(E) {}
| ^
.../clang/lib/AST/Interp/Source.h:22:7: note: forward declaration of 'clang::Decl'
22 | class Decl;
| ^
```
This helps transition code bases to handle the new warning added in 3632e2f5179
Before:
```
clang/test/FixIt/format.cpp:10:16: warning: format specifies type 'int' but the argument has type 'N::E' [-Wformat]
10 | printf("%d", N::E::One); // expected-warning{{format specifies type 'int' but the argument has type 'N::E'}}
| ~~ ^~~~~~~~~
| %d
```
After:
```
clang/test/FixIt/format.cpp:10:16: warning: format specifies type 'int' but the argument has type 'N::E' [-Wformat]
10 | printf("%d", N::E::One); // expected-warning{{format specifies type 'int' but the argument has type 'N::E'}}
| ~~ ^~~~~~~~~
| static_cast<int>( )
```
Differential Revision: https://reviews.llvm.org/D153623
This patch changes the -Wformat diagnostic to suggest static_cast over
a C-style cast for {,Objective}C++ when recommending the argument be
casted rather than changing the format string.
Before:
```
clang/test/FixIt/format.mm:11:16: warning: format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'wchar_t' [-Wformat]
11 | NSLog(@"%C", wchar_data); // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'wchar_t'}}
| ~~ ^~~~~~~~~~
| (unsigned short)
```
After:
```
clang/test/FixIt/format.mm:11:16: warning: format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'wchar_t' [-Wformat]
11 | NSLog(@"%C", wchar_data); // expected-warning{{format specifies type 'unichar' (aka 'unsigned short') but the argument has type 'wchar_t'}}
| ~~ ^~~~~~~~~~
| static_cast<unsigned short>( )
```
Differential Revision: https://reviews.llvm.org/D153622
Now that clang supports printing of multiple lines of code snippet in diagnostics, source ranges in diagnostics that are located in different lines from the diagnosed source location get to be printed if the gap happened to be less than the maximum number of lines clang is allowed to print in.
Many of the bad-conversion notes in overload resolution failures have their source location in the function declaration and source range in the argument of function call. This can cause an unnecessarily many lines of snippet printing.
This patch fixes it by changing the source range from function callsite to the problematic parameter in function declaration.
e.g.
```
void func(int aa, int bb);
void test() { func(1, "two"); }
```
BEFORE this patch:
```
source:4:15: error: no matching function for call to 'func'
4 | void test() { func(1, "two"); }
| ^~~~
source:1:6: note: candidate function not viable: no known conversion from 'const char[4]' to 'int' for 2nd argument
1 | void func(int aa, int bb);
| ^
2 |
3 |
4 | void test() { func(1, "two"); }
| ~~~~~
1 error generated.
```
AFTER this patch:
```
source:4:15: error: no matching function for call to 'func'
4 | void test() { func(1, "two"); }
| ^~~~
source:1:6: note: candidate function not viable: no known conversion from 'const char[4]' to 'int' for 2nd argument
1 | void func(int aa, int bb);
| ^ ~~~~~~
```
Reviewed By: cjdb
Differential Revision: https://reviews.llvm.org/D153359
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
In our downstream, we define some intrinsics that don't require any
extra extension enabled. Such as
TARGET_BUILTIN(__builtin_riscv_xxx, "LiLi", "nc", "")
But `split` function's `KeepEmpty` argument is True. Got the error message
error: builtin requires at least one of the following extensions support to be enabled : ''
when we use our customized intrinsic.
Reviewed By: craig.topper, wangpc
Differential Revision: https://reviews.llvm.org/D154596
I'm using clang to compile CUDA code. And just found that clang doesn't support the per-thread stream option for NV CUDA. I don't know if there is another solution.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D154822
In D114095, `HeaderFileInfo::NumIncludes` was moved into `Preprocessor`. This still makes sense, because we want to track this on the granularity of submodules (D112915, D114173), but the way this information is serialized is not ideal. In `ASTWriter`, the set of included files gets deserialized eagerly, issuing lots of calls to `FileManager::getFile()` for input files the PCM consumer might not be interested in.
This patch makes the information part of the header file info table, taking advantage of its lazy deserialization which typically happens when a file is about to be included.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D155131
When -mcpu=native is specified, try detecting GPU
on the system by using amdgpu-arch tool. If it
fails to detect GPU, emit an error about GPU
not detected. If multiple GPUs are detected,
use the first GPU and emit a warning.
Reviewed by: Matt Arsenault, Fangrui Song
Differential Revision: https://reviews.llvm.org/D154531
ENABLE_X86_RELAX_RELOCATIONS has defaulted to on
(c41a18cf61790fc898dcda1055c3efbf442c14c0) for nearly 3 years.
As a clean-up, remove overrides from some early adopters.
Change OHOS to use true as agreed by the patch author D145227.
This seems to match https://gcc.gnu.org/install/specific.html#powerpc-x-eabi
It seems that anything with OS `none` (although that doesn’t seem to be distinguished from `unknown`) or with environment `eabi` should be treated as bare-metal.
Since this seems to have been handled on a case-by-case basis in the past ([arm](https://reviews.llvm.org/D33259), [riscv](https://reviews.llvm.org/D91442), [aarch64](https://reviews.llvm.org/D111134)), what I am proposing here is to add another case to the list to also handle `powerpc[64][le]-unknown-unknown-eabi` using the `BareMetal` toolchain, following the example of the existing cases. (We don’t care about powerpc64 and powerpc[64]le, but it seemed appropriate to lump them in.)
At Indel, we have been building bare-metal embedded applications that run on custom PowerPC and ARM systems with Clang and LLD for a couple of years now, using target triples `powerpc-indel-eabi`, `powerpc-indel-eabi750`, `arm-indel-eabi`, `aarch64-indel-eabi` (which I just learned from D153430 is wrong and should be `aarch64-indel-elf` instead, but that’s a different matter). This has worked fine for ARM, but for PowerPC we have been unable to call the linker (LLD) through the Clang driver, because it would insist on calling GCC as the linker, even when told `-fuse-ld=lld`. That does not work for us, there is no GCC around. Instead we had to call `ld.lld` directly, introducing some special cases in our build system to translate between linker-via-driver and linker-called-directly command line arguments. I have now dug into why that is, and found that the difference between ARM and PowerPC is that `arm-indel-eabi` hits a special case that causes the Clang driver to instantiate a `BareMetal` toolchain that is able to call LLD and works the way we need, whereas `powerpc-indel-eabi` lands in the default case of a `Generic_ELF` (subclass of `Generic_GCC`) toolchain which expects GCC.
Reviewed By: MaskRay, michaelplatings, #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D154357
