| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Should fix Windows bot failure:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/16956
llvm-svn: 331681
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch tackles long hanging fruit for the builtin operator<=> expressions. It is currently needs some cleanup before landing, but I want to get some initial feedback.
The main changes are:
* Lookup, build, and store the required standard library types and expressions in `ASTContext`. By storing them in ASTContext we don't need to store (and duplicate) the required expressions in the BinaryOperator AST nodes.
* Implement [expr.spaceship] checking, including diagnosing narrowing conversions.
* Implement `ExprConstant` for builtin spaceship operators.
* Implement builitin operator<=> support in `CodeGenAgg`. Initially I emitted the required comparisons using `ScalarExprEmitter::VisitBinaryOperator`, but this caused the operand expressions to be emitted once for every required cmp.
* Implement [builtin.over] with modifications to support the intent of P0946R0. See the note on `BuiltinOperatorOverloadBuilder::addThreeWayArithmeticOverloads` for more information about the workaround.
Reviewers: rsmith, aaron.ballman, majnemer, rnk, compnerd, rjmccall
Reviewed By: rjmccall
Subscribers: rjmccall, rsmith, aaron.ballman, junbuml, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D45476
llvm-svn: 331677
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently LLVM CFI tries to use an implicit blacklist file, currently
in /usr/lib64/clang/<version>/share. If the file is not there, LLVM
happily continues, which causes CFI to add checks to files/functions
that are known to fail, generating binaries that fail. This CL causes
LLVM to die (I hope) if it can't find these implicit blacklist files.
Patch by Caroline Tice!
Differential Revision: https://reviews.llvm.org/D46403
llvm-svn: 331674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As identified and briefly discussed here:
https://bugs.llvm.org/show_bug.cgi?id=37305
Converting a floating point number to an integer type when
the integral part is out of the range of the integer type is
undefined behavior in C. Additionally, CodeGen emits an undef
in this situation.
HOWEVER, we've been giving a warning that says that the value is
changed. This patch corrects the warning to list that it is actually
undefined behavior.
Differential Revision: https://reviews.llvm.org/D46535
llvm-svn: 331673
|
|
|
|
|
|
|
|
| |
Don't use the GNU extension form of line markers in MSVC mode.
Differential Revision: https://reviews.llvm.org/D46520
llvm-svn: 331666
|
|
|
|
| |
llvm-svn: 331654
|
|
|
|
|
|
| |
Added correct codegen for the critical construct on NVPTX devices.
llvm-svn: 331652
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I found that explicit template parameters that caused a
narrowing integer conversion resulted in the incorrect parameter
being mentioned in the note (see test attached). This is because
the argument checking code doesn't check to see if it caused
SFINAE errors when checking the arguments, so instead of giving
up on the first error, it continues through the list. This
makes the error reporting pick up the last template param every time.
This patch checks these parameters on each argument and gives up
if there is an error. The result is that only the required amount
of arguments are checked, and that the 'Converted' array contains
only the successful arguments before the first failure, as the
calls seem to all expect.
llvm-svn: 331651
|
|
|
|
| |
llvm-svn: 331644
|
|
|
|
|
|
|
| |
Added initial codegen for level 2, 3 etc. parallelism. Currently, all
the second, the third etc. parallel regions will run sequentially.
llvm-svn: 331642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to disable PIC and to match GCC behaviour, -mno-abicalls
option is neccessary. When -fno-[pic/PIC] is used witout -mno-abicalls,
warning is reported. An error is reported when -fno-pic or -fno-PIC is
used in combination with -mabicalls.
In this commit, test case is added.
Depends on D44381.
Differential Revision: https://reviews.llvm.org/D44684
llvm-svn: 331640
|
|
|
|
|
|
| |
This reverts commit r331636. Forgot to add the test case.
llvm-svn: 331639
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to disable PIC and to match GCC behaviour, -mno-abicalls
option is neccessary. When -fno-[pic/PIC] is used witout -mno-abicalls,
warning is reported. An error is reported when -fno-pic or -fno-PIC is
used in combination with -mabicalls.
Depends on D44381.
Differential Revision: https://reviews.llvm.org/D44684
llvm-svn: 331636
|
|
|
|
|
|
|
|
|
|
| |
DependentScopeDeclRefExpr
The visit callback implementations for the 3 C++ AST Node added to the ASTImporter.
Differential Revision: https://reviews.llvm.org/D38845
llvm-svn: 331630
|
|
|
|
|
|
| |
emptyness in MS record layout.
llvm-svn: 331621
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the rule intended by the standard (see LWG 2358)
and the rule intended by the Itanium C++ ABI (see
https://github.com/itanium-cxx-abi/cxx-abi/pull/51), and makes
Clang match the behavior of GCC, ICC, and MSVC.
A pedantic reading of both the standard and the ABI indicate that Clang
is currently technically correct, but that's not worth much when it's
clear that the wording is wrong in both those places.
This is an ABI break for classes that derive from a class that is empty
other than one or more unnamed non-zero-length bit-fields. Such cases
are expected to be rare, but -fclang-abi-compat=6 restores the old
behavior just in case.
Differential Revision: https://reviews.llvm.org/D45174
llvm-svn: 331620
|
|
|
|
|
|
|
|
|
|
|
|
| |
Diagnoses code like:
void f(const int *ptr) {
__sync_fetch_and_add(ptr, 1);
}
which matches the behavior of GCC and ICC.
llvm-svn: 331598
|
|
|
|
|
|
|
|
|
|
|
| |
The error turns out to be:
Assertion failed: (Target.isCompatibleDataLayout(getDataLayout()) && "Can't create a MachineFunction using a Module with a " "Target-incompatible DataLayout attached\n"), function init, file /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/lib/CodeGen/MachineFunction.cpp, line 180.
Add -target to address this. Also re-enable the test I had temporarily
commented, and move it further down in case there is still a failure
(since it pipes stderr to FileCheck).
llvm-svn: 331597
|
|
|
|
|
|
|
|
|
|
| |
Trying to debug why/where a few bots getting exit code 256 e.g.
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/48471/testReport/Clang/CodeGen/thinlto_diagnostic_handler_remarks_with_hotness_ll/
and a few windows bots getting no output from that RUN line e.g.
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/11865/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Athinlto-diagnostic-handler-remarks-with-hotness.ll
llvm-svn: 331596
|
|
|
|
|
|
| |
Failing on non-x86 bots, needs x86 target for code gen.
llvm-svn: 331593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Passes down the necessary code ge options to the LTO Config to enable
-fdiagnostics-show-hotness and -fsave-optimization-record in the ThinLTO
backend for a distributed build.
Also, remove warning about not having PGO when the input is IR.
Reviewers: pcc
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D46464
llvm-svn: 331592
|
|
|
|
|
|
|
|
| |
dyn_cast.
It looks like it safe to just use cast for both cases.
llvm-svn: 331578
|
|
|
|
|
|
|
|
|
|
| |
The C standard doesn't allow comparisons like "f1 < f2" (where f1 and f2
are function pointers), but we allow them as an extension. Add a
warning flag to control this warning.
Differential Revision: https://reviews.llvm.org/D46155
llvm-svn: 331570
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 331565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We weren't invalidating our unions correctly. The previous behavior in
invalidateRegionsWorker::VisitCluster() was to direct-bind an UnknownVal
to the union (at offset 0).
For that reason we were never actually loading default bindings from our unions,
because there never was any default binding to load, and the value
that is presumed when there's no default binding to load
is usually completely incorrect (eg. UndefinedVal for stack unions).
The new behavior is to default-bind a conjured symbol (of irrelevant type)
to the union that's being invalidated, similarly to what we do for structures
and classes. Then it becomes safe to load the value properly.
Differential Revision: https://reviews.llvm.org/D45241
llvm-svn: 331563
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C allows us to write any bytes into any memory region. When loading weird bytes
from memory regions of known types, the analyzer is required to make sure that
the loaded value makes sense by casting it to an appropriate type.
Fix such cast for loading values that represent void pointers from non-void
pointer type places.
Differential Revision: https://reviews.llvm.org/D46415
llvm-svn: 331562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bindDefault() API of the ProgramState allows setting a default value
for reads from memory regions that were not preceded by writes.
It was used for implementing C++ zeroing constructors (i.e. default constructors
that boil down to setting all fields of the object to 0).
Because differences between zeroing consturctors and other forms of default
initialization have been piling up (in particular, zeroing constructors can be
called multiple times over the same object, probably even at the same offset,
requiring a careful and potentially slow cleanup of previous bindings in the
RegionStore), we split the API in two: bindDefaultInitial() for modeling
initial values and bindDefaultZero() for modeling zeroing constructors.
This fixes a few assertion failures from which the investigation originated.
The imperfect protection from both inability of the RegionStore to support
binding extents and lack of information in ASTRecordLayout has been loosened
because it's, well, imperfect, and it is unclear if it fixing more than it
was breaking.
Differential Revision: https://reviews.llvm.org/D46368
llvm-svn: 331561
|
|
|
|
|
|
| |
'nothrow'
llvm-svn: 331560
|
|
|
|
|
|
|
|
| |
headers.
Some were too long and some were too short.
llvm-svn: 331559
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many glvalue expressions aren't of their respective reference type -
they are simply glvalues of their value type.
This was causing problems when we were trying to obtain type of the original
expression while evaluating certain glvalue bit-casts.
Fixed by artificially forging a reference type to provide to the casting
procedure.
Differential Revision: https://reviews.llvm.org/D46224
llvm-svn: 331558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When loading from a variable or a field that is declared as constant,
the analyzer will try to inspect its initializer and constant-fold it.
Upon success, the analyzer would skip normal load and return the respective
constant.
The new behavior also applies to fields/elements of brace-initialized structures
and arrays.
Patch by Rafael Stahl!
Differential Revision: https://reviews.llvm.org/D45774
llvm-svn: 331556
|
|
|
|
|
| |
Author: mikhail.ramalho@gmail.com
llvm-svn: 331552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The class will be moved into libToolingCore as followup.
The new behaviors in this patch:
- New #include is inserted in the right position in a #include block to
preserver sorted #includes. This is best effort - only works when the
block is already sorted.
- When inserting multiple #includes to the end of a file which doesn't
end with a "\n" character, a "\n" will be prepended to each #include.
This is a special and rare case that was previously handled. This is now
relaxed to avoid complexity as it's rare in practice.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: klimek, cfe-commits, djasper
Differential Revision: https://reviews.llvm.org/D46180
llvm-svn: 331544
|
|
|
|
| |
llvm-svn: 331536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/EP or /P
This replicates 'cl.exe' behavior and allows for both preprocessor output and
dependency information to be extraced with a single compiler invocation.
This is especially useful for compiler caching with tools like Mozilla's sccache.
See: https://github.com/mozilla/sccache/issues/246
Patch By: fxb
Differential Revision: https://reviews.llvm.org/D46394
llvm-svn: 331533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Remove explicit -analyzer-config cfg-temporary-dtors=true in analyzer tests,
since this option defaults to true since r326461.
Reviewers: NoQ
Reviewed By: NoQ
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46393
llvm-svn: 331520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
http://wg21.link/P0664r2 section "Evolution/Core Issues 24" describes a
proposed change to Coroutines TS that would have any exceptions thrown
after the initial suspend point of a coroutine be caught by the handler
specified by the promise type's 'unhandled_exception' member function.
This commit provides a sample implementation of the specified behavior.
Test Plan: `check-clang`
Reviewers: GorNishanov, EricWF
Reviewed By: GorNishanov
Subscribers: cfe-commits, lewissbaker, eric_niebler
Differential Revision: https://reviews.llvm.org/D45860
llvm-svn: 331519
|
|
|
|
|
|
|
|
|
| |
This avoids warnings about unused linker parameters, just like
other flags are ignored if they're from config files.
Differential Revision: https://reviews.llvm.org/D46286
llvm-svn: 331504
|
|
|
|
| |
llvm-svn: 331496
|
|
|
|
|
|
| |
These builtins snuck in while I was in the middle of adding nothrow to the other builtins in my local clone and I guess I missed them.
llvm-svn: 331483
|
|
|
|
|
|
|
|
| |
separator instead of StringRef separator. NFC
The char separator version should be a little better optimized.
llvm-svn: 331482
|
|
|
|
|
|
|
|
| |
Reviewed by: ABataev
Differential Revision: https://reviews.llvm.org/D46370
llvm-svn: 331469
|
|
|
|
|
|
| |
Sorry, forgot to add commit log attributes.
llvm-svn: 331468
|
|
|
|
| |
llvm-svn: 331466
|
|
|
|
|
|
| |
Calling convention attributes notionally appertain to the function type -- they modify the mangling of the function, change the behavior of assignment operations, etc. This commit allows the calling convention attributes to be written in the type position as well as the declaration position.
llvm-svn: 331459
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is one of the initial commit of "RFC: Devirtualization v2" proposal:
https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit?usp=sharing
Reviewers: rsmith, amharc, kuhar, sanjoy
Subscribers: arsenm, nhaehnle, javed.absar, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45111
llvm-svn: 331448
|
|
|
|
| |
llvm-svn: 331440
|
|
|
|
| |
llvm-svn: 331438
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FunctionProtoType.
We previously re-evaluated the expression each time we wanted to know whether
the type is noexcept or not. We now evaluate the expression exactly once.
This is not quite "no functional change": it fixes a crasher bug during AST
deserialization where we would try to evaluate the noexcept specification in a
situation where we have not deserialized sufficient portions of the AST to
permit such evaluation.
llvm-svn: 331428
|
|
|
|
|
|
|
|
|
| |
This changes some aspects of the build that are not relevant or useful
for Fuchsia like setting the RPATH/RUNPATH.
Differential Revision: https://reviews.llvm.org/D46361
llvm-svn: 331425
|