This makes the range loop warnings part of -Wall.
Fixes PR32823: Warn about accidental coping of data in range based for
Differential Revision: https://reviews.llvm.org/D68912
Recomitted after fixing the warnings it created.
Summary:
Running an end-to-end test last week I noticed that a lot of the ACLE
intrinsics that operate differently on vectors of signed and unsigned
integers were ending up generating the signed version of the
instruction unconditionally. This is because the IR intrinsics had no
way to distinguish signed from unsigned: the LLVM type system just
calls them both `v8i16` (or whatever), so you need either separate
intrinsics for signed and unsigned, or a flag parameter that tells
ISel which one to choose.
This patch fixes all the problems of that kind that I've noticed, by
adding an i32 flag parameter to many of the IR intrinsics which is set
to 1 for unsigned (matching the existing practice in cases where we
got it right), and conditioning all the isel patterns on that flag. So
the fundamental change is in `IntrinsicsARM.td`, changing the
low-level IR intrinsics API; there are knock-on changes in
`arm_mve.td` (adjusting code gen for the ACLE intrinsics to use the
modified API) and in `ARMInstrMVE.td` (adjusting isel to expect the
new unsigned flags). The rest of this patch is boringly updating tests.
Reviewers: dmgreen, miyuki, MarkMurrayARM
Reviewed By: dmgreen
Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D72270
Summary:
The ACLE intrinsics with `gather_base` or `scatter_base` in the name
are wrappers on the MVE load/store instructions that take a vector of
base addresses and an immediate offset. The immediate offset can be up
to 127 times the alignment unit, and it can be positive or negative.
At the MC layer, we got that right. But in the Sema error checking for
the wrapping intrinsics, the offset was erroneously constrained to be
positive.
To fix this I've adjusted the `imm_mem7bit` class in the Tablegen that
defines the intrinsics. But that causes integer literals like
`0xfffffffffffffe04` to appear in the autogenerated calls to
`SemaBuiltinConstantArgRange`, which provokes a compiler warning
because that's out of the non-overflowing range of an `int64_t`. So
I've also tweaked `MveEmitter` to emit that as `-0x1fc` instead.
Updated the tests of the Sema checks themselves, and also adjusted a
random sample of the CodeGen tests to actually use negative offsets
and prove they get all the way through code generation without causing
a crash.
Reviewers: dmgreen, miyuki, MarkMurrayARM
Reviewed By: dmgreen
Subscribers: kristof.beyls, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D72268
Summary:
Found a bug introduced with BraceWrappingFlags AfterControlStatement MultiLine. This feature conflicts with the existing BeforeCatch and BeforeElse flags.
For example, our team uses BeforeElse.
if (foo ||
bar) {
doSomething();
}
else {
doSomethingElse();
}
If we enable MultiLine (which we'd really love to do) we expect it to work like this:
if (foo ||
bar)
{
doSomething();
}
else {
doSomethingElse();
}
What we actually get is:
if (foo ||
bar)
{
doSomething();
}
else
{
doSomethingElse();
}
Reviewers: MyDeveloperDay, Bouska, mitchell-stellar
Patch by: pastey
Subscribers: Bouska, cfe-commits
Tags: clang
Differential Revision: https://reviews.llvm.org/D71939
Driver test `cross-linux.c` fails when CLANG_DEFAULT_RTLIB is "compiler-rt"
as the it expects a GCC-style `"crtbegin.o"` after `"crti.o"` but instead
receives something akin to this in the frontend invocation:
```
"crt1.o" "crti.o"
"/o/b/llvm/bin/../lib/clang/10.0.0/lib/linux/clang_rt.crtbegin-x86_64.o"
```
This patch adds an override to `cross-linux.c` tests so the expected result
is produced regardless of the compile-time default rtlib, as having tests
fail due to that is fairly confusing. After applying the patch, the test
passes regardless of the CLANG_DEFAULT_RTLIB setting.
Differential Revision: https://reviews.llvm.org/D72236
Linux' current addLibCxxIncludePaths and addLibStdCxxIncludePaths
are actually almost non-Linux-specific at all, and can be reused
almost as such for all gcc toolchains. Only keep
Android/Freescale/Cray hacks in Linux's version.
Patch by sthibaul (Samuel Thibault)
Differential Revision: https://reviews.llvm.org/D69758
-mpacked-stack is currently not supported with -mbackchain, so this should
result in a compilation error message instead of being silently ignored.
Review: Ulrich Weigand
The patch files section is redundant to https://llvm.org/docs/GettingStarted.html.
There is nothing clang specific here. We are talking about a monorepo after all.
While it may seem nice to have one single clang page which explains everything,
it's not: It doesn't cover the topics in sufficient depth, it's redundant to
other pages and it's hard to keep it up to date as we see with the svn
instructions.
Before:
class Foo {
@CommandLineFlags
.Add
@Features.foo
public void test() {}
}
Now:
class Foo {
@Features.foo
@CommandLineFlags.Add
public void test() { }
}
See also https://crbug.com/1034115
The OpenMP specification disallows having zero-length array
sections in the depend clause (OpenMP 5.0 2.17.11).
Differential Revision: https://reviews.llvm.org/D71969
Summary:
this allow much better support of codebases like the linux kernel that mix tabs and spaces.
-ftabstop=//Width// allow specifying how large tabs are considered to be.
Reviewers: xbolva00, aaron.ballman, rsmith
Reviewed By: aaron.ballman
Subscribers: mstorsjo, cfe-commits, jyknight, riccibruno, rsmith, nathanchance
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71037
Remove description of language mode from the language
extensions and add a link to pdf document.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72076
When they are free-standing, e.g. `struct X;` or `struct X {};`.
Although this complicates the common case (of free-standing class
declarations), this ensures the less common case (e.g. `struct X {} a;`)
are handled uniformly and produce similar syntax trees.
We would like to use clang-scan-deps in Fuchsia build so include it
in the toolchain distribution.
Differential Revision: https://reviews.llvm.org/D72113
Added codegen support for lastprivate conditional. According to the
standard, if when the conditional modifier appears on the clause, if an
assignment to a list item is encountered in the construct then the
original list item is assigned the value that is assigned to the new
list item in the sequentially last iteration or lexically last section
in which such an assignment is encountered.
We look for the assignment operations and check if the left side
references lastprivate conditional variable. Then the next code is
emitted:
if (last_iv_a <= iv) {
last_iv_a = iv;
last_a = lp_a;
}
At the end the implicit barrier is generated to wait for the end of all
threads and then in the check for the last iteration the private copy is
assigned the last value.
if (last_iter) {
lp_a = last_a; // <--- new code
a = lp_a; // <--- store of private value to the original variable.
}
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This restores 68a235d07f,
e6c7ed6d21. The problem with the windows
bot is a need for clearing the cache.
Adds a new ASTMatcher condition called 'hasInitStatement()' that matches if,
switch and range-for statements with an initializer. Reworked clang-tidy
readability-else-after-return to handle variables in the if condition or init
statements in c++17 ifs. Also checks if removing the else would affect object
lifetimes in the else branch.
Fixes PR44364.
This reverts commit 68a235d07f.
This commit broke the clang-x64-windows-msvc build bot and a follow-up
commit did not fix it. Reverting to fix the bot.
There's quite a lot of references to Polly in the LLVM CMake codebase. However
the registration pattern used by Polly could be useful to other external
projects: thanks to that mechanism it would be possible to develop LLVM
extension without touching the LLVM code base.
This patch has two effects:
1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it
with a generic mechanism
2. Provide a generic mechanism to register compiler extensions.
A compiler extension is similar to a pass plugin, with the notable difference
that the compiler extension can be configured to be built dynamically (like
plugins) or statically (like regular passes).
As a result, people willing to add extra passes to clang/opt can do it using a
separate code repo, but still have their pass be linked in clang/opt as built-in
passes.
Differential Revision: https://reviews.llvm.org/D61446
Summary: `getListOfPossibleValues()` formatted incorrectly when there is only one value, emitting something like `expected 'conditional' or in OpenMP clause 'lastprivate'`.
Reviewers: jdoerfert, ABataev
Reviewed By: jdoerfert
Subscribers: guansong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71884
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This makes the range loop warnings part of -Wall.
Fixes PR32823: Warn about accidental coping of data in range based for
Differential Revision: https://reviews.llvm.org/D68912
The Wrange-loop-analyses warns if a copy is made. Suppress this warning when
a temporary is bound to a rvalue reference.
While fixing this issue also found a copy-paste error in test6, which is also
fixed.
Differential Revision: https://reviews.llvm.org/D71806
clang/lib/CodeGen/CodeGenModule performs the -mpie-copy-relocations
check and sets dso_local on applicable global variables. We don't need
to duplicate the work in TargetMachine shouldAssumeDSOLocal.
Verified that -mpie-copy-relocations can still emit PC relative
relocations for external variable accesses.
clang -target x86_64 -fpie -mpie-copy-relocations -c => R_X86_64_PC32
clang -target aarch64 -fpie -mpie-copy-relocations -c => R_AARCH64_ADR_PREL_PG_HI21+R_AARCH64_LDST64_ABS_LO12_NC
This reverts commit b47b35ff51.
This caused failed asserts (Assertion `FIDAndOffset.second >
ColNo && "Column number smaller than file offset?"' failed.)
on a source file with a single line containing
"int main (void) { for( int i = 0; i < 9; i++ ); return 0; }".
We already recognize the __builtin versions of these, might as well
recognize the libcall version.
Differential Revision: https://reviews.llvm.org/D72028
Summary:
These overloads make it possible to wrap unless(), anyOf(), has() etc
with the traverse matcher.
Reviewers: aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71977
This fixes the following failure:
C:\[...]\llvm\tools\clang\test\VFS\external-names.c:34:26: error: CHECK-DEBUG-EXTERNAL: expected string not found in input
// CHECK-DEBUG-EXTERNAL: ![[Num]] = !DIFile(filename: "{{[^"]*}}Inputs{{.}}external-names.h"
^
[...]
<stdin>:42:54: note: possible intended match here
!10 = !DIFile(filename: "C:/[...]\\llvm\\tools\\clang\\test\\VFS\\Inputs\\external-names.h", directory: "")
Differential Revision: https://reviews.llvm.org/D71991
This replaces the fsub -0.0 idiom with an fneg instruction. We didn't see to have a test that showed the current codegen. Just some tests for constant folding and a test that was only checking the declare lines for libcalls. The latter just checked that we did not have a declare for @conj when using __builtin_conj.
Differential Revision: https://reviews.llvm.org/D72012
We have an fneg instruction now and should use it instead of the fsub -0.0 idiom. Looks like we had no test that showed that we handled the negation cases here so I've added new tests.
Differential Revision: https://reviews.llvm.org/D72010
stevewan