This adds a check for exported inline functions, that there is a definition in
the definition domain (which, in practice, can only be the module purview but
before any PMF starts) since the PMF definition domain cannot contain exports.
This is:
[dcl.inline]/7
If an inline function or variable that is attached to a named module is declared in
a definition domain, it shall be defined in that domain.
The patch also amends diagnostic output by excluding the PMF sub-module from the
set considered as sources of missing decls. There is no point in telling the user
that the import of a PMF object is missing - since such objects are never reachable
to an importer. We still show the definition (as unreachable), to help point out
this.
Differential Revision: https://reviews.llvm.org/D128328
Adds a builtin that serves as an optimization hint to apply specific optimized
DAG mutations during scheduling. This also disables any other mutations or
clustering that may interfere with the desired pipeline. The first optimization
strategy that is added here is designed to improve the performance of small gemm
kernels on gfx90a.
Reviewed By: jrbyrnes
Differential Revision: https://reviews.llvm.org/D132079
Currently ExtractAPI only emits availability information for the
current platform. This makes it easy for clients to get all availability
information for a given symbol in one invocation as opposed to having to invoke
clang once per-platform and then merge the symbol-graphs.
Differential Revision: https://reviews.llvm.org/D130918
This reverts commit d483730d8c.
This allegedly breaks a significant part of facebooks internal build.
Reverting while we wait for them to provide a reproducer of this from
@wlei.
The hard float ABIs have a rule that if a flattened struct contains
either a single fp value, or an int+fp, or fp+fp then it may be passed
in a pair of registers (if sufficient GPRs+FPRs are available).
detectFPCCEligibleStruct and the helper it calls,
detectFPCCEligibleStructHelper examine the type of the argument/return
value to determine if it complies with the requirements for this ABI
rule.
As reported in bug #57084, this logic produces incorrect results for C++
structs that inherit from other structs. This is because only the fields
of the struct were examined, but enumerating RD->fields misses any
fields in inherited C++ structs. This patch corrects that issue by
adding appropriate logic to enumerate any included base structs.
Differential Revision: https://reviews.llvm.org/D131677
The patch mainly focuses on the no warnings for -Wtautological-compare.
It work fine for the positive numbers but doesn't for the negative
numbers. This is because the warning explicitly checks for an
IntegerLiteral AST node, but -1 is represented by a UnaryOperator with
an IntegerLiteral sub-Expr.
Fixes#42918
Differential Revision: https://reviews.llvm.org/D130510
Implement negating and inverting values. Also implement
IntegralToBoolean casts so the operations are easier to test.
Differential Revision: https://reviews.llvm.org/D132098
This patch replaces svget, svset and svcreate aarch64 intrinsics for tuple
types with the generic llvm-ir intrinsics extract/insert vector
Differential Revision: https://reviews.llvm.org/D131547
The commit of af2d11b1d5 missed a case where
the value of a suggested module needed to be reset to nullptr. Fixed thus
and added a testcase to cover the circumstance.
Instead of complaining about default initialization, tell users that
constexpr variables need to be initialized by a constant expression.
Differential Revision: https://reviews.llvm.org/D131662
Currently, record arguments are always passed by reference by allocating
space for record values in the caller. This is less efficient for
small records which may take one or two registers. For example,
for x86_64 and aarch64, for a record size up to 16 bytes, the record
values can be passed by values directly on the registers.
This patch added BPF support of record argument with direct values
for up to 16 byte record size. If record size is 0, that record
will not take any register, which is the same behavior for x86_64
and aarch64. If the record size is greater than 16 bytes, the
record argument will be passed by reference.
Differential Revision: https://reviews.llvm.org/D132144
Using Max for both "PIC Level" and "PIE Level" is inconsistent. PIC imposes less
restriction while PIE imposes more restriction. The result generally
picks the more restrictive behavior: Min for PIC.
This choice matches `ld -r`: a non-pic object and a pic object merge into a
result which should be treated as non-pic.
To allow linking "PIC Level" using Error/Max from old bitcode files, upgrade
Error/Max to Min.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D130531
The previous implementation translated from names like sifive-7-series
to sifive-7-rv32 or sifive-7-rv64. This also required sifive-7-rv32
and sifive-7-rv64 to be valid CPU names. As those are not real
CPUs it doesn't make sense to accept them in -mcpu.
This patch does away with the translation and adds sifive-7-series
directly to RISCV.td. Removing sifive-7-rv32 and sifive-7-rv64.
sifive-7-series is only allowed in -mtune.
I've also added "rocket" to RISCV.td but have not removed rocket-rv32
or rocket-rv64.
To prevent -mcpu=sifive-7-series or -mcpu=rocket being used with llc,
I've added a Feature32Bit to all rv32 CPUs. And made it an error to
have an rv32 triple without Feature32Bit. sifive-7-series and rocket
do not have Feature32Bit or Feature64Bit set so the user would need
to provide -mattr=+32bit or -mattr=+64bit along with the -mcpu to
avoid the error.
SiFive no longer names their newer products with 3, 5, or 7 series.
Instead we have p200 series, x200 series, p500 series, and p600 series.
Following the previous behavior would require a sifive-p500-rv32 and
sifive-p500-rv64 in order to support -mtune=sifive-p500-series. There
is currently no p500 product, but it could start getting confusing if
there was in the future.
I'm open to hearing alternatives for how to achieve my main goal
of removing sifive-7-rv32/rv64 as a CPU name.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D131708
This patch adds OMPIRBuilder support for the safelen clause for the
simd directive.
Reviewed By: shraiysh, Meinersbur
Differential Revision: https://reviews.llvm.org/D131526
Add the clang option -finline-max-stacksize=<N> to suppress inlining
of functions whose stack size exceeds the given value.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D131986
This patch fixes a crash when trying to emit a constant compound literal.
For C++ Clang evaluates either casts or binary operations at translation time,
but doesn't pass on the InConstantContext information that was inferred when
parsing the statement. Because of this, strict FP evaluation (-ftrapping-math)
which shouldn't be in effect yet, then causes checkFloatingpointResult to return
false, which in tryEmitGlobalCompoundLiteral will trigger an assert that the
compound literal wasn't constant.
The discussion here around 'manifestly constant evaluated contexts' was very
helpful to me when trying to understand what LLVM's position is on what
evaluation context should be in effect, together with the explanatory text in
that patch itself:
https://reviews.llvm.org/D87528
Reviewed By: rjmccall, DavidSpickett
Differential Revision: https://reviews.llvm.org/D131555
We deferred the evaluation of dependent immediate invocations in https://reviews.llvm.org/D119375 until instantiation.
We should also not consider them referenced from a non-consteval context.
Fixes: https://github.com/llvm/llvm-project/issues/55601
```
template<typename T>
class Bar {
consteval static T x() { return 5; }
public:
Bar() : a(x()) {}
private:
int a;
};
Bar<int> g();
```
Is now accepted by clang. Previously it errored with: `cannot take address of consteval function 'x' outside of an immediate invocation Bar() : a(x()) {}`
Differential Revision: https://reviews.llvm.org/D132031
This implements support for using libc++ headers in MSVC toolchain.
We only support libc++ headers that are part of the toolchain, and
not headers installed elsewhere on the system.
Differential Revision: https://reviews.llvm.org/D101479
The restrictions added in D131704 were not sufficient to avoid all non-constant
expression contexts. In particular constant initialization cases.
We need to check EvaluatingDecl to detect if the variable we are initializing is
constexpr or not.
At this point it looks like this is the remaining case affecting various projects
with this diagnostic.
Differential Revision: https://reviews.llvm.org/D131874
This reverts commit 258c3aee54.
This should fix the libc++ issue that caused the revert, by re-designing
slightly how we determined when we should evaluate the constraints.
Additionally, many of the other components to the original patch (the
NFC parts) were committed separately to shrink the size of this patch
for review.
Differential Revision: https://reviews.llvm.org/D126907
Seems this complicated lldb sufficiently for some cases that it hasn't
been worth supporting/fixing there - and it so far hasn't provided any
new use cases/value for debug info consumers, so let's remove it until
someone has a use case for it.
(side note: the original implementation of this still had a bug (I
should've caught it in review) that we still didn't produce
auto-returning function declarations in types where the function wasn't
instantiatied (that requires a fix to remove the `if
getContainedAutoType` condition in
`CGDebugInfo::CollectCXXMemberFunctions` - without that, auto returning
functions were still being handled the same as member function templates
and special member functions - never added to the member list, only
attached to the type via the declaration chain from the definition)
Further discussion about this in D123319
This reverts commit 5ff992bca208a0e37ca6338fc735aec6aa848b72: [DEBUG-INFO] Change how we handle auto return types for lambda operator() to be consistent with gcc
This reverts commit c83602fdf51b2692e3bacb06bf861f20f74e987f: [DWARF5][clang]: Added support for DebugInfo generation for auto return type for C++ member functions.
Differential Revision: https://reviews.llvm.org/D131933
Currently bpf supports calling kernel functions (x86_64, arm64, etc.)
in bpf programs. Tejun discovered a problem where the x86_64 func
return value (a unsigned char type) is stored in 8-bit subregister %al
and the other 56-bits in %rax might be garbage. But based on current
bpf ABI, the bpf program assumes the whole %rax holds the correct value
as the callee is supposed to do necessary sign/zero extension.
This mismatch between bpf and x86_64 caused the incorrect results.
To resolve this problem, this patch forced caller to do needed
sign/zero extension for 8/16-bit return values as well. Note that
32-bit return values already had sign/zero extension even without
this patch.
For example, for the test case attached to this patch:
$ cat t.c
_Bool bar_bool(void);
unsigned char bar_char(void);
short bar_short(void);
int bar_int(void);
int foo_bool(void) {
if (bar_bool() != 1) return 0; else return 1;
}
int foo_char(void) {
if (bar_char() != 10) return 0; else return 1;
}
int foo_short(void) {
if (bar_short() != 10) return 0; else return 1;
}
int foo_int(void) {
if (bar_int() != 10) return 0; else return 1;
}
Without this patch, generated call insns in IR looks like:
%call = call zeroext i1 @bar_bool()
%call = call zeroext i8 @bar_char()
%call = call signext i16 @bar_short()
%call = call i32 @bar_int()
So it is assumed that zero extension has been done for return values of
bar_bool()and bar_char(). Sign extension has been done for the return
value of bar_short(). The return value of bar_int() does not have any
assumption so caller needs to do necessary shifting to get correct
32bit values.
With this patch, generated call insns in IR looks like:
%call = call i1 @bar_bool()
%call = call i8 @bar_char()
%call = call i16 @bar_short()
%call = call i32 @bar_int()
There are no assumptions for return values of the above four function calls,
so necessary shifting is necessary for all of them.
The following is the objdump file difference for function foo_char().
Without this patch:
0000000000000010 <foo_char>:
2: 85 10 00 00 ff ff ff ff call -1
3: bf 01 00 00 00 00 00 00 r1 = r0
4: b7 00 00 00 01 00 00 00 r0 = 1
5: 15 01 01 00 0a 00 00 00 if r1 == 10 goto +1 <LBB1_2>
6: b7 00 00 00 00 00 00 00 r0 = 0
0000000000000038 <LBB1_2>:
7: 95 00 00 00 00 00 00 00 exit
With this patch:
0000000000000018 <foo_char>:
3: 85 10 00 00 ff ff ff ff call -1
4: bf 01 00 00 00 00 00 00 r1 = r0
5: 57 01 00 00 ff 00 00 00 r1 &= 255
6: b7 00 00 00 01 00 00 00 r0 = 1
7: 15 01 01 00 0a 00 00 00 if r1 == 10 goto +1 <LBB1_2>
8: b7 00 00 00 00 00 00 00 r0 = 0
0000000000000048 <LBB1_2>:
9: 95 00 00 00 00 00 00 00 exit
The zero extension of the return 'char' value is done here.
Differential Revision: https://reviews.llvm.org/D131598
Add initial support for NonNull attribute.
(https://github.com/llvm/llvm-project/issues/57113)
Test plan:
verify that for
__thread int x;
int main() {
int* y = &x;
return *y;
}
(with this patch) clang -O -fsanitize=null -S -emit-llvm -o -
doesn't emit a null-pointer check
Differential revision: https://reviews.llvm.org/D131872
When aliasing a static array, the aliasee is going to be a GEP which
points to the value. We should strip pointer casts before forming the
reference. This was occluded by the use of opaque pointers.
This problem has existed since the introduction of the debug info
generation for aliases in b1ea0191a4. The
test case would assert due to the invalid cast with or without
`-no-opaque-pointers` at that revision.
Fixes: #57179
I accidentally broke friend destructor declarations in D130936.
Modify it to skip performing the destructor name check if we have a dependent friend declaration.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D131541
Currently we treat initializers with init_seg(compiler/lib) as similar
to any other init_seg, they simply have a global variable in the proper
section (".CRT$XCC" for compiler/".CRT$XCL" for lib) and are added to
llvm.used. However, this doesn't match with how LLVM sees normal (or
init_seg(user)) initializers via llvm.global_ctors. This
causes issues like incorrect init_seg(compiler) vs init_seg(user)
ordering due to GlobalOpt evaluating constructors, and the
ability to remove init_seg(compiler/lib) initializers at all.
Currently we use 'A' for priorities less than 200. Use 200 for
init_seg(compiler) (".CRT$XCC") and 400 for init_seg(lib) (".CRT$XCL"),
which do not append the priority to the section name. Priorities
between 200 and 400 use ".CRT$XCC${Priority}". This allows for
some wiggle room for people/future extensions that want to add
initializers between compiler and lib.
Fixes#56922
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D131910
I introduced a patch to handle unqualified templated base class
initialization in MSVC compatibility mode:
https://reviews.llvm.org/rGc894e85fc64dd8d83b460de81080fff93c5ca334
We identified a problem with this patch in the case where the base class
is partially specialized, which can lead to triggering an assertion in
the case of a mix between types and values.
The minimal test case is:
template <typename Type, int TSize> class Vec {};
template <int TDim> class Index : public Vec<int, TDim> {
Index() : Vec() {}
};
template class Index<0>;
The detailed problem is that I was using the
`InjectedClassNameSpecialization`, to which the class template arguments
were then applied in order. But in the process, we were losing all the
partial specializations of the base class and creating an index mismatch
between the expected and passed arguments.
Patch By: frederic-tingaud-sonarsource
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D130709
Newer SDKs don't even provide libstdc++ headers, so it's effectively
never valid to build for libstdc++ unless the user explicitly asks
for it (in which case they will need to provide include paths and more).
This is a re-application of c5ccb78ade which had been reverted in
33171df9cc because it broke the Fuchsia CI bots. The issue was that
the test was XPASSing because it didn't fail anymore when the
CLANG_DEFAULT_CXX_LIB was set to libc++, which seems to be done for
Fuchsia. Instead, the test only fails if CLANG_DEFAULT_CXX_LIB is
set to libstdc++.
As a fly-by fix, also adjust the triple used by various tests to
something that is supported. Those tests were shown to fail on
internal bots.
Differential Revision: https://reviews.llvm.org/D131274
The point of a constexpr if statement is to determine which branch to
take at compile time, so warning on unreachable code is meaningless in
these situations.
Fixes#57123.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D131818
When expanding undeclared function parameters, we should initialize
the original number of expansions, if known, before trying to expand
them, otherwise a length mismatch with an outer pack might not be
diagnosed.
Fixes PR56094.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D131802
DR692 handles two cases: pack expansion (for class/var template) and function parameter pack. The former needs DR1432 as a fix, and the latter needs DR1395 as a fix. However, DR1432 has not yet made a wording change. so I made a tentative fix for DR1432 with the same spirit as DR1395.
Reviewed By: aaron.ballman, erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D128745
Iain Sandoe