| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When files often get touched during builds, the mtime based validation
leads to different problems in implicit modules builds, even when the
content doesn't actually change:
- Modules only: module invalidation due to out of date files. Usually causing rebuild traffic.
- Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH.
- PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime.
This patch proposes hashing the content of input files (headers and
module maps), which is performed during serialization time. When looking
at input files for validation, clang only computes the hash in case
there's a mtime mismatch.
I've tested a couple of different hash algorithms availble in LLVM in
face of building modules+pch for `#import <Cocoa/Cocoa.h>`:
- `hash_code`: performace diff within the noise, total module cache increased by 0.07%.
- `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`.
- `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file.
Given the numbers above, the patch uses `hash_code`. The patch also
improves invalidation error msgs to point out which type of problem the
user is facing: "mtime", "size" or "content".
rdar://problem/29320105
Reviewers: dexonsmith, arphaman, rsmith, aprantl
Subscribers: jkorous, cfe-commits, ributzka
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67249
> llvm-svn: 374841
llvm-svn: 374895
|
|
|
|
| |
llvm-svn: 374893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet, jdoerfert
Reviewed By: courbet
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D68792
llvm-svn: 374884
|
|
|
|
|
|
| |
Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof.
llvm-svn: 374882
|
|
|
|
| |
llvm-svn: 374876
|
|
|
|
| |
llvm-svn: 374864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The WebAssembly backend lowers fptoint instructions to a code sequence
that checks for overflow to avoid traps because fptoint is supposed to
be speculatable. These new builtins and intrinsics give users a way to
depend on the trapping semantics of the underlying instructions and
avoid the extra code generated normally.
Patch by coffee and tlively.
Reviewers: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D68902
llvm-svn: 374856
|
|
|
|
|
|
| |
This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f.
llvm-svn: 374844
|
|
|
|
|
|
|
|
| |
as it's breaking a few bots.
This reverts r374841 (git commit 2a1386c81de504b5bda44fbecf3f7b4cdfd748fc)
llvm-svn: 374842
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When files often get touched during builds, the mtime based validation
leads to different problems in implicit modules builds, even when the
content doesn't actually change:
- Modules only: module invalidation due to out of date files. Usually causing rebuild traffic.
- Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH.
- PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime.
This patch proposes hashing the content of input files (headers and
module maps), which is performed during serialization time. When looking
at input files for validation, clang only computes the hash in case
there's a mtime mismatch.
I've tested a couple of different hash algorithms availble in LLVM in
face of building modules+pch for `#import <Cocoa/Cocoa.h>`:
- `hash_code`: performace diff within the noise, total module cache increased by 0.07%.
- `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`.
- `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file.
Given the numbers above, the patch uses `hash_code`. The patch also
improves invalidation error msgs to point out which type of problem the
user is facing: "mtime", "size" or "content".
rdar://problem/29320105
Reviewers: dexonsmith, arphaman, rsmith, aprantl
Subscribers: jkorous, cfe-commits, ributzka
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67249
llvm-svn: 374841
|
|
|
|
|
|
| |
we're running and to make flipping the default not regress testing.
llvm-svn: 374840
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we will unroll loops. Also comment a few occasions where we need to
know whether or not we're forcing the unwinder or not.
The default before and after this patch is for LoopUnroll to be enabled,
and for it to use a cost model to determine whether to unroll the loop
(`OnlyWhenForced = false`). Before this patch, disabling loop unroll
would not run the LoopUnroll pass. After this patch, the LoopUnroll pass
is being run, but it restricts unrolling to only the loops marked by a
pragma (`OnlyWhenForced = true`).
In addition, this patch disables the UnrollAndJam pass when disabling unrolling.
Testcase is in clang because it's controlling how the loop optimizer
is being set up and there's no other way to trigger the behavior.
llvm-svn: 374838
|
|
|
|
|
|
| |
Include linux as a test requirement.
llvm-svn: 374837
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The version mismatch symbol is version 9 on 32 bit android. Since
this test isn't actually testing any android specific functionality,
we force the target triple to x86_64-unknown-unknown in order to have
a consistent version number. It seems the test was already trying to
do this, just not doing it right
Patch by Christopher Tetrault
Differential Revision: https://reviews.llvm.org/D68882
llvm-svn: 374836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently clang does not support -Wa,-W, which suppresses warning
messages in GNU assembler. Add this option for gcc compatibility.
https://bugs.llvm.org/show_bug.cgi?id=43651. Reland with differential
information.
Reviewers: bcain
Reviewed By: bcain
Subscribers: george.burgess.iv, gbiv, llozano, manojgupta, nickdesaulniers, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68884
llvm-svn: 374834
|
|
|
|
|
|
| |
This reverts commit e72eeca43b9577be2aae55f7603febbf223a6ab3.
llvm-svn: 374833
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We don't know what context to use until the classification result is
consumed by the parser, which could happen in a different semantic
context. So don't build the expression that results from name
classification until we get to that point and can handle it properly.
This covers everything except C++ implicit class member access, which
is a little awkward to handle properly in the face of the protected
member access check. But it at least fixes all the currently-filed
instances of PR43080.
Reviewers: efriedma
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68896
llvm-svn: 374826
|
|
|
|
|
|
|
|
| |
Currently clang does not support -Wa,-W, which suppresses warning
messages in GNU assembler. Add this option for gcc compatibility.
https://bugs.llvm.org/show_bug.cgi?id=43651
llvm-svn: 374822
|
|
|
|
|
|
| |
Follow-up to c5d14b5c6fa
llvm-svn: 374821
|
|
|
|
|
|
|
| |
The expression of the num_tasks clause must be captured in the combined
task-based directives, like 'parallel master taskloop' directive.
llvm-svn: 374819
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal is to have 100% fidelity in clang-scan-deps behavior when
--analyze is present in compilation command.
At the same time I don't want to break clang-tidy which expects
__static_analyzer__ macro defined as built-in.
I introduce new cc1 options (-setup-static-analyzer) that controls
the macro definition and is conditionally set in driver.
Differential Revision: https://reviews.llvm.org/D68093
llvm-svn: 374815
|
|
|
|
|
|
|
| |
The expression of the grainsize clause must be captured in the combined
task-based directives, like 'parallel master taskloop' directive.
llvm-svn: 374810
|
|
|
|
|
|
|
| |
Adding the quotes breaks tests because on Darwin the name mangling is prefixed
with an underscore.
llvm-svn: 374805
|
|
|
|
|
|
|
|
|
|
|
| |
Microsoft's ABI mangles names differently than Itanium and this breaks the LLVM
yaml parser unless the name is escaped in quotes. Quotes are being added to the
mangled names of the IFS file generation so that llvm-ifs doesn't break when
Windows triples are passed to the driver.
Differential Revision: https://reviews.llvm.org/D68915
llvm-svn: 374798
|
|
|
|
|
|
|
|
|
| |
Added parsing/sema/codegen support for 'parallel master taskloop'
constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final'
and 'priority' are not supported in full, only constant expressions can
be used currently in these clauses.
llvm-svn: 374791
|
|
|
|
|
|
|
|
|
|
|
| |
constructs.
If OpenMP construct includes several capturing regions and the variable
is declared as private, the length of the inner variable length array is
not captured in outer captured regions, only in the innermost region.
Patch fixes this bug.
llvm-svn: 374787
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch restores the behaviour that -fpu overwrites the
architecture obtained from -march or -mcpu flags, not enforcing to
disable 'crypto' if march=armv7 and mfpu=neon-fp-armv8.
However, it does warn that 'crypto' is ignored when passing
mfpu=crypto-neon-fp-armv8.
Reviewers: peter.smith, labrinea
Reviewed By: peter.smith
Subscribers: nickdesaulniers, kristof.beyls, dmgreen, cfe-commits, krisb
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67608
llvm-svn: 374785
|
|
|
|
|
|
|
|
| |
Reapply r374240 with fix for Ocaml test, namely Bindings/OCaml/core.ml.
Differential Revision: https://reviews.llvm.org/D61675
llvm-svn: 374782
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
1. enable LTO need to pass target feature and abi to LTO code generation
RISCV backend need the target feature to decide which extension used in
code generation.
2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag
3. add general tools::getTargetABI in CommonArgs.h because different target uses different
way to get the target ABI.
Patch by Kuan Hsu Chen (khchen)
Reviewers: lenary, lewis-revill, asb, MaskRay
Reviewed By: lenary
Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini, inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67409
llvm-svn: 374774
|
|
|
|
|
|
|
|
|
|
|
| |
Following our discussion on the cfe dev list:
http://lists.llvm.org/pipermail/cfe-dev/2019-August/063054.html,
I have added a paragraph that is explicit about loop pragmas, and
transformation options implying the corresponding transformation.
Differential Revision: https://reviews.llvm.org/D66199
llvm-svn: 374756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow finding installed llvm-objcopy in PATH if it's not present
in the directory containing clang-offload-bundler. This is the case
if clang is being built stand-alone, and llvm-objcopy is already
installed while the c-o-b tool is still present in build directory.
This is consistent with how e.g. llvm-symbolizer is found in LLVM.
However, most of similar searches in LLVM and Clang are performed
without special-casing the program directory.
Fixes r369955.
Differential Revision: https://reviews.llvm.org/D68931
llvm-svn: 374754
|
|
|
|
|
|
|
|
|
| |
That way, lit's builtin 'env' command can be used for the 'env' bit.
Also it's clearer that way that the 'not' shouldn't cover 'env'
failures.
llvm-svn: 374749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_constant_p used to be short-cut evaluated to false when
building with -O0. This is undesirable as it means that constant folding
in the front-end can give different results than folding in the back-end.
It can also create conditional branches on constant conditions that don't
get folded away. With the pending improvements to the llvm.is.constant
handling on the LLVM side, the short-cut is no longer useful.
Adjust various codegen tests to not depend on the short-cut or the
backend optimisations.
Differential Revision: https://reviews.llvm.org/D67638
llvm-svn: 374742
|
|
|
|
|
|
| |
relanding {D68554} with fixed lit tests, checked on Windows and MacOS
llvm-svn: 374720
|
|
|
|
|
|
|
|
| |
dereference warning. NFCI.
The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us.
llvm-svn: 374717
|
|
|
|
|
|
|
|
|
|
| |
style warnings"
The test fails on macOS and looks a bit wrong, see comments on the review.
Also revert follow-up r374686.
llvm-svn: 374688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Related somewhat to {D29039}
On seeing a quote on twitter by @invalidop
> If it's not formatted with clang-format it's a build error.
This made me want to change the way I use clang-format into a tool that could optionally show me where my source code violates clang-format syle.
When I'm making a change to clang-format itself, one thing I like to do to test the change is to ensure I didn't cause a huge wave of changes, what I want to do is simply run this on a known formatted directory and see if any new differences arrive in a manner I'm used to.
This started me thinking that we should allow build systems to run clang-format on a whole tree and emit compiler style warnings about files that fail clang-format in a form that would make them as a warning in most build systems and because those build systems range in their construction I don't think its unreasonable to NOT expect them to have to do the directory searching or parsing the output replacements themselves, but simply transform that into an error code when there are changes required.
I am starting this by suggesing adding a -n or -dry-run command line argument which would emit a warning/error of the form
Support for various common compiler command line argumuments like '-Werror' and '-ferror-limit' could make this very flexible to be integrated into build systems and CI systems.
```
> $ /usr/bin/clang-format --dry-run ClangFormat.cpp -ferror-limit=3 -fcolor-diagnostics
> ClangFormat.cpp:54:29: warning: code should be clang-formatted [-Wclang-format-violations]
> static cl::list<std::string>
> ^
> ClangFormat.cpp:55:20: warning: code should be clang-formatted [-Wclang-format-violations]
> LineRanges("lines", cl::desc("<start line>:<end line> - format a range of\n"
> ^
> ClangFormat.cpp:55:77: warning: code should be clang-formatted [-Wclang-format-violations]
> LineRanges("lines", cl::desc("<start line>:<end line> - format a range of\n"
> ^
```
Reviewers: mitchell-stellar, klimek, owenpan
Reviewed By: klimek
Subscribers: mgorny, cfe-commits
Tags: #clang-format, #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D68554
llvm-svn: 374663
|
|
|
|
|
|
| |
assignment check
llvm-svn: 374659
|
|
|
|
|
|
| |
This is just a long standing spelling error that was found recently.
llvm-svn: 374638
|
|
|
|
|
|
|
|
|
| |
Special thanks to JamesNagurne who got to the bottom of this; landing this on
his behalf.
Differential Revision: https://reviews.llvm.org/D68897
llvm-svn: 374632
|
|
|
|
| |
llvm-svn: 374627
|
|
|
|
|
|
|
|
| |
Currently there is no need to make ObjCTypeParamType have a canonical type
different from the one in corresponding ObjCTypeParamDecl. So remove the
corresponding unused API.
llvm-svn: 374596
|
|
|
|
|
|
| |
https://reviews.llvm.org/D66733
llvm-svn: 374593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rdar://problem/55715134
Reviewers: dsanders, bogner, rtereshin
Reviewed By: dsanders
Subscribers: hiraditya, jkorous, dexonsmith, ributzka, cfe-commits, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68252
llvm-svn: 374581
|
|
|
|
|
|
| |
__is_*_assignable(volatile T&, U).
llvm-svn: 374580
|
|
|
|
|
|
|
|
|
|
| |
The clang IFS ASTConsumer was asserting on enums, records (struct definitions in
C), and typedefs. All it needs to do is skip them because the stub just needs to
expose global object instances and functions.
Differential Revision: https://reviews.llvm.org/D68859
llvm-svn: 374573
|
|
|
|
| |
llvm-svn: 374571
|
|
|
|
|
|
|
|
|
| |
__builtin_assume_aligned takes a size_t which is a 32 bit int on
hexagon. Thus, the constant gets converted to a 32 bit value, resulting
in 0 not being a power of 2. This patch changes the constant being
passed to 2**30 so that it fails, but doesnt exceed 30 bits.
llvm-svn: 374569
|
|
|
|
|
|
|
|
|
|
| |
The behavior from the original patch has changed, since we're no longer
allowing LLVM to just ignore the alignment. Instead, we're just
assuming the maximum possible alignment.
Differential Revision: https://reviews.llvm.org/D68824
llvm-svn: 374562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Move the `RewriteRule` class and related declarations into its own set
of files (header, implementation). Only the `Transformer` class is left in the
Transformer-named files. This change clarifies the distinction between the
`RewriteRule` class, which is essential to the Transformer library, and the
`Transformer` class, which is only one possible `RewriteRule` interpreter
(compare to `TransformerClangTidyCheck`, a clang-tidy based interpreter).
Reviewers: gribozavr
Subscribers: jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68795
llvm-svn: 374558
|