As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549
There's potential for a lot more cleanups around these APIs. This is
just a start.
Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using `llvm::demangle`. Add a
release note.
Differential Revision: https://reviews.llvm.org/D149104
Correctly account for the fact that certain targets do not use the generic address space for the implicit VTT argument. This entails adjusting `ItaniumCXXABI::buildStructorSignature`, `ItaniumCXXABI::addImplicitStructorParams` and `ItaniumCXXABI::getImplicitConstructorArgs` to use the target's global variable address space. The associated test is temporarily marked `XFAIL` as additional fixes are needed.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D150746
This patch uses castAs instead of getAs which will assert if the type doesn't match to resolve dereference issue with nullptr FPT when calling getThisType() in clang::CodeGen::CGDebugInfo::CreateType(clang::MemberPointerType const *, llvm::DIFile *).
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D151947
Make `qualifyWindowsLibrary` and `addStackProbeTargetAttributes`
protected members of `TargetCodeGenInfo`.
These are helper functions used by `getDependentLibraryOption` and
`setTargetAttributes` methods when targeting Windows. The change will
allow these functions to be reused after splitting `TargetInfo.cpp`.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D150178
This patch uses castAs instead of getAs which will assert if the type doesn't match in clang::CodeGen::CodeGenTypes::GetFunctionTypeForVTable(clang::GlobalDecl).
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D151957
LLVM IR already allows floating point type in atomicrmw.
Update clang atomic fetch max/min builtins to accept
floating point type like we did for fetch add/sub.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D150985
Fixes: SWDEV-401056
There are places in the runtime, like __kmp_init_indirect_csptr, which
assume these pointers are aligned to sizeof(void*), so make sure we emit
them with the correct alignment.
Fixes#62668
Reviewed By: jlpeyton
Differential Revision: https://reviews.llvm.org/D150723
Currently compiler assert when passing variable "memspace" in
omp_init_allocator.
omp_allocator_handle_t alloc=omp_init_allocator(memspace,1,traits)
The problem is memspace is not mapping to the target region. During
the call to emitAllocatorInit, calls to EmitVarDecl for "alloc", then
emit initialization of "alloc" that cause to assert.
If I understant correct, it is not necessary to emit variable
initialization, since "allocator" is private to target region.
To fix this call CGF.EmitAutoVarAlloca(allocator) instead
CGF.EmitVarDecl(allocator).
Differential Revision: https://reviews.llvm.org/D151743
The rest of the fetch/op intrinsics were added in e13246a2ec but sub
was conspicuous by its absence.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D151701
This patch adds support for the following SME ACLE intrinsics (as defined
in https://arm-software.github.io/acle/main/acle.html):
- svld1_hor_za8 // also for _za16, _za32, _za64 and _za128
- svld1_hor_vnum_za8 // also for _za16, _za32, _za64 and _za128
- svld1_ver_za8 // also for _za16, _za32, _za64 and _za128
- svld1_ver_vnum_za8 // also for _za16, _za32, _za64 and _za128
- svst1_hor_za8 // also for _za16, _za32, _za64 and _za128
- svst1_hor_vnum_za8 // also for _za16, _za32, _za64 and _za128
- svst1_ver_za8 // also for _za16, _za32, _za64 and _za128
- svst1_ver_vnum_za8 // also for _za16, _za32, _za64 and _za128
SveEmitter.cpp is extended to generate arm_sme.h (currently named
arm_sme_draft_spec_subject_to_change.h) and other SME definitions from
arm_sme.td, which is modeled after arm_sve.td. Common TableGen definitions
are moved into arm_sve_sme_incl.td.
Co-authored-by: Sagar Kulkarni <sagar.kulkarni1@huawei.com>
Reviewed By: sdesmalen, kmclaughlin
Differential Revision: https://reviews.llvm.org/D127910
The corresponding function definition was removed by:
commit cf8ff75bad
Author: Leonard Chan <leonardchan@google.com>
Date: Tue Jul 14 14:56:38 2020 -0700
CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.
Differential Revision: https://reviews.llvm.org/D146389
Pursuant to discussions at
https://discourse.llvm.org/t/rfc-c-23-p1467r9-extended-floating-point-types-and-standard-names/70033/22,
this commit enhances the handling of the __bf16 type in Clang.
- Firstly, it upgrades __bf16 from a storage-only type to an arithmetic
type.
- Secondly, it changes the mangling of __bf16 to DF16b on all
architectures except ARM. This change has been made in
accordance with the finalization of the mangling for the
std::bfloat16_t type, as discussed at
https://github.com/itanium-cxx-abi/cxx-abi/pull/147.
- Finally, this commit extends the existing excess precision support to
the __bf16 type. This applies to hardware architectures that do not
natively support bfloat16 arithmetic.
Appropriate tests have been added to verify the effects of these
changes and ensure no regressions in other areas of the compiler.
Reviewed By: rjmccall, pengfei, zahiraam
Differential Revision: https://reviews.llvm.org/D150913
First, removes the invocation of the memprof instrumentation passes from
the end of the module simplification pass builder, where it doesn't
really belong. However, it turns out that this was never being invoked,
as it is guarded by an internal option not used anywhere (even tests).
These passes are actually added via clang under the -fmemory-profile
option. Changed this to add via the EP callback interface, similar to
the sanitizer passes. They are added to the EP for the end of the
optimization pipeline, which is roughly where they were being added
already (end of the pre-LTO link pipelines and non-LTO optimization
pipeline).
Ideally we should plumb the output file through to LLVM and set it up
there, so I have added a TODO.
Differential Revision: https://reviews.llvm.org/D151593
It seems load of traits.addr should be passed in runtime call. Currently
the load of load traits.addr gets passed cause runtime to fail.
To fix this, skip the call to EmitLoadOfScalar for extra load.
Differential Revision: https://reviews.llvm.org/D151576
The corresponding function definition was removed by:
commit 56e5a2e13e
Author: George Burgess IV <george.burgess.iv@gmail.com>
Date: Sat Mar 10 01:11:17 2018 +0000
Reported by Static Code Analyzer Tool:
Inside "CGExprConstant.cpp" file, VisitObjCEncodeExpr() returns null value which is dereferenced without checking.
This patch adds an assert.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D151280
This patch fixes the issue that list items in `has_device_addr` are still mapped
to the target device because front end emits map type `OMP_MAP_TO`.
Fix#59160.
Reviewed By: jyu2
Differential Revision: https://reviews.llvm.org/D141627
Function pointers are checked by loading a prefix structure from just
before the function's entry point. However, on Arm, the function
pointer is not always exactly equal to the address of the entry point,
because Thumb function pointers have the low bit set to tell the BX
instruction to enter them in Thumb state. So the generated code loads
from an odd address and suffers an alignment fault.
Fixed by clearing the low bit of the function pointer before
subtracting 8.
Differential Revision: https://reviews.llvm.org/D151308
If there is an infinite cycle in the IR, the loop will never exit. Keep
track of visited basic blocks in a set and return nullptr if a block is
visited again.
Fixes#62830.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D151076
flexible array member
A zero-element array type was incorrectly being used when an incomplete
array was being initialized with a non-empty initializer.
This fixes an assertion failure in AddInitializerToStaticVarDecl. See
the discussion here: https://reviews.llvm.org/D123649#4362210
Differential Revision: https://reviews.llvm.org/D151172
Reported by Coverity static analyzer tool:
Inside "ItaniumCXXABI.cpp" file, in <unnamed>::ItaniumCXXABI::EmitLoadOfMemberFunctionPointer(clang::CodeGen::CodeGenFunction &, clang::Expr const *, clang::CodeGen::Address, llvm::Value *&, llvm::Value *, clang::MemberPointerType const *): Return value of function which returns null is dereferenced without checking.
//returned_null: getAs returns nullptr (checked 130 out of 156 times).
//var_assigned: Assigning: FPT = nullptr return value from getAs.
const FunctionProtoType *FPT =
MPT->getPointeeType()->getAs<FunctionProtoType>();
auto *RD =
cast<CXXRecordDecl>(MPT->getClass()->castAs<RecordType>()->getDecl());
// Dereference null return value (NULL_RETURNS)
//dereference: Dereferencing a pointer that might be nullptr FPT when calling arrangeCXXMethodType.
llvm::FunctionType *FTy = CGM.getTypes().GetFunctionType(
CGM.getTypes().arrangeCXXMethodType(RD, FPT, /*FD=*/nullptr));
This patch uses castAs instead of getAs which will assert if the type doesn't match.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D151054
There are two motivations.
`-fno-pic -fstack-protector -mstack-protector-guard=global` created
`__stack_chk_guard` is referenced directly on all ELF OSes except FreeBSD.
This patch allows referencing the symbol indirectly with
-fno-direct-access-external-data.
Some Linux kernel folks want
`-fno-pic -fstack-protector -mstack-protector-guard-reg=gs -mstack-protector-guard-symbol=__stack_chk_guard`
created `__stack_chk_guard` to be referenced directly, avoiding
R_X86_64_REX_GOTPCRELX (even if the relocation may be optimized out by the linker).
https://github.com/llvm/llvm-project/issues/60116
Why they need this isn't so clear to me.
---
Add module flag "direct-access-external-data" and set the dso_local property of
the stack protector symbol. The module flag can benefit other LLVMCodeGen
synthesized symbols that are not represented in LLVM IR.
Nowadays, with `-fno-pic` being uncommon, ideally we should set
"direct-access-external-data" when it is true. However, doing so would require
~90 clang/test tests to be updated, which are too much.
As a compromise, we set "direct-access-external-data" only when it's different
from the implied default value.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D150841
Reported by Coverity:
Inside "CGExpr.cpp" file, in clang::CodeGen::CodeGenFunction::EmitOMPArraySectionExpr(clang::OMPArraySectionExpr const *, bool): Return value of function which returns null is dereferenced without checking.
} else {
//returned_null: getAsConstantArrayType returns nullptr (checked 83 out of 95 times).
// var_assigned: Assigning: CAT = nullptr return value from getAsConstantArrayType.
auto *CAT = C.getAsConstantArrayType(ArrayTy);
//identity_transfer: Member function call CAT->getSize() returns an offset off CAT (this).
// Dereference null return value (NULL_RETURNS)
//dereference: Dereferencing a pointer that might be nullptr CAT->getSize() when calling APInt.
ConstLength = CAT->getSize();
}
This patch adds an assert to resolve the bug.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D151137
Add more builtins for stdio functions as in GCC, along with their
mutations under IEEE float128 ABI.
Reviewed By: tuliom
Differential Revision: https://reviews.llvm.org/D150087
With D148785, -fsanitize=function no longer uses C++ RTTI objects and therefore
can support C. The rationale for reporting errors is C11 6.5.2.2p9:
> If the function is defined with a type that is not compatible with the type (of the expression) pointed to by the expression that denotes the called function, the behavior is undefined.
The mangled types approach we use does not exactly match the C type
compatibility (see `f(callee1)` below).
This is probably fine as the rules are unlikely leveraged in practice. In
addition, the call is warned by -Wincompatible-function-pointer-types-strict.
```
void callee0(int (*a)[]) {}
void callee1(int (*a)[1]) {}
void f(void (*fp)(int (*)[])) { fp(0); }
int main() {
int a[1];
f(callee0);
f(callee1); // compatible but flagged by -fsanitize=function, -fsanitize=kcfi, and -Wincompatible-function-pointer-types-strict
}
```
Skip indirect call sites of a function type without a prototype to avoid deal
with C11 6.5.2.2p6. -fsanitize=kcfi skips such calls as well.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D148827
For the cover letter of this patch-set, please checkout D146872.
Depends on D147731.
This is the 4th patch of the patch-set.
This patch is a proof-of-concept and will be extended to full coverage
in the future. Currently, the old non-tuple unit-stride segment store is
not removed, and only signed integer unit-strided segment store of NF=2,
EEW=32 is defined here.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D147774
For the cover letter of this patch-set, please checkout D146872.
Depends on D146872.
This is the 2nd patch of the patch-set. This patch originates from
D97264. This patch further allows local variable declaration and
function parameter passing by adjustment in clang lowering.
Test cases are provided to demonstrate the LLVM IR generated.
Note: This patch is currently only a proof-of-concept with only a
single RVV tuple type declared here, the rest will be added when
the concept of this patch-set is accepted.
Authored-by: eop Chen <eop.chen@sifive.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D146873
Currently we use RTTI objects to check type compatibility. To support non-unique
RTTI objects, commit 5745eccef5 added a
`checkTypeInfoEquality` string matching to the runtime.
The scheme is inefficient.
```
_Z1fv:
.long 846595819 # jmp
.long .L__llvm_rtti_proxy-_Z3funv
...
main:
...
# Load the second word (pointer to the RTTI object) and dereference it.
movslq 4(%rsi), %rax
movq (%rax,%rsi), %rdx
# Is it the desired typeinfo object?
leaq _ZTIFvvE(%rip), %rax
# If not, call __ubsan_handle_function_type_mismatch_v1, which may recover if checkTypeInfoEquality allows
cmpq %rax, %rdx
jne .LBB1_2
...
.section .data.rel.ro,"aw",@progbits
.p2align 3, 0x0
.L__llvm_rtti_proxy:
.quad _ZTIFvvE
```
Let's replace the indirect `_ZTI` pointer with a type hash similar to
`-fsanitize=kcfi`.
```
_Z1fv:
.long 3238382334
.long 2772461324 # type hash
main:
...
# Load the second word (callee type hash) and check whether it is expected
cmpl $-1522505972, -4(%rax)
# If not, fail: call __ubsan_handle_function_type_mismatch
jne .LBB2_2
```
The RTTI object derives its name from `clang::MangleContext::mangleCXXRTTI`,
which uses `mangleType`. `mangleTypeName` uses `mangleType` as well. So the
type compatibility change is high-fidelity.
Since we no longer need RTTI pointers in
`__ubsan::__ubsan_handle_function_type_mismatch_v1`, let's switch it back to
version 0, the original signature before
e215996a29 (2019).
`__ubsan::__ubsan_handle_function_type_mismatch_abort` is not
recoverable, so we can revert some changes from
e215996a29.
Reviewed By: samitolvanen
Differential Revision: https://reviews.llvm.org/D148785
CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.
Differential Revision: https://reviews.llvm.org/D146389
Make `occupiesMoreThan` a protected member of `SwiftABIInfo`.
This method is only used by implementations of `SwiftABIInfo`.
Making it protected will allow to use it after the implementations
are moved to dedicated cpp files.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D148093
Remove `getABIInfo` overrides returning references to target-specific
implementations of `ABIInfo`.
The methods may be convenient, but they are only used in one place and
prevent from `ABIInfo` implementations from being put into anonymous
namespaces in different cpp files.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D148092
Don't derive from `DefaultTargetCodeGenInfo`.
This class is going to stay in `TargetInfo.cpp`, whereas its derivants
are going to be moved to separate translation units. Just derive from
the base `TargetCodeGenInfo` class instead.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D148091
Move `ABIKind` enums out of `*ABIInfo` classes to break the dependency
between `getTargetCodeGenInfo` and the classes.
This will allow to move the classes to different cpp files.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D148090
`CCState` is a helper class originally used by the x86 implementation
but has since been abused by other implementations.
Remove this dependency by implementing customized versions of the class
for implementations that need such functionality.
Reviewed By: efriedma, MaskRay
Differential Revision: https://reviews.llvm.org/D148089
The current implementation of -fsanitize=function places two words (the prolog
signature and the RTTI proxy) at the function entry, which makes the feature
incompatible with Intel Indirect Branch Tracking (IBT) that needs an ENDBR instruction
at the function entry. To allow the combination, move the two words before the
function entry, similar to -fsanitize=kcfi.
Armv8.5 Branch Target Identification (BTI) has a similar requirement.
Note: for IBT and BTI, whether a function gets a marker instruction at the entry
generally cannot be assumed (it can be disabled by a function attribute or
stronger LTO optimizations).
It is extremely unlikely for two words preceding a function entry to be
inaccessible. One way to achieve this is by ensuring that a function is
aligned at a page boundary and making the preceding page unmapped or
unreadable. This is not reasonable for application or library code.
(Think: the first text section has crt* code not instrumented by
-fsanitize=function.)
We use 0xc105cafe for all targets. .long 0xc105cafe disassembles to invalid
instructions on all architectures I have tested, except Power where it is
`lfs 8, -13570(5)` (Load Floating-Point with a weird offset, unlikely to be used in real code).
---
For the removed function in AsmPrinter.cpp, remove an assert: `mdconst::extract`
already asserts non-nullness.
For compiler-rt/test/ubsan/TestCases/TypeCheck/Function/function.cpp,
when the function doesn't have prolog/epilog (-O1 and above), after moving the two words,
the address of the function equals the address of ret instruction,
so symbolizing the function will additionally get a non-zero column number.
Adjust the test to allow an optional column number.
```
.long 3238382334
.long .L__llvm_rtti_proxy-_Z1fv
_Z1fv: // symbolizing here retrieves the line table entry from the second .loc
.file 0 ...
.loc 0 1 0
.cfi_startproc
.loc 0 2 1 prologue_end
retq
```
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D148665
