| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
such executable.
llvm-svn: 185308
|
|
|
|
| |
llvm-svn: 185307
|
|
|
|
| |
llvm-svn: 185306
|
|
|
|
| |
llvm-svn: 185305
|
|
|
|
|
|
| |
InitListExpr.
llvm-svn: 185304
|
|
|
|
| |
llvm-svn: 185303
|
|
|
|
|
|
| |
operator.
llvm-svn: 185302
|
|
|
|
| |
llvm-svn: 185301
|
|
|
|
|
|
| |
standards.
llvm-svn: 185300
|
|
|
|
|
|
|
|
| |
Math functions are mark as readonly because they read the floating point
rounding mode. Because we don't vectorize loops that would contain function
calls that set the rounding mode it is safe to ignore this memory read.
llvm-svn: 185299
|
|
|
|
|
|
| |
so as to correctly handle EOF. This fixes http://llvm.org/bugs/show_bug.cgi?id=16427
llvm-svn: 185298
|
|
|
|
|
|
| |
overly general and getting confused with the copy constructor and copy assignment operators. Constrained them. This fixes http://llvm.org/bugs/show_bug.cgi?id=16385
llvm-svn: 185297
|
|
|
|
| |
llvm-svn: 185296
|
|
|
|
| |
llvm-svn: 185295
|
|
|
|
| |
llvm-svn: 185294
|
|
|
|
| |
llvm-svn: 185293
|
|
|
|
| |
llvm-svn: 185292
|
|
|
|
|
|
| |
This allows clang to use the backend parameter attribute 'returned' when generating 'this'-returning constructors and destructors in ARM and MSVC C++ ABIs.
llvm-svn: 185291
|
|
|
|
|
|
| |
argument with the 'returned' attribute (rather than generate invalid IR); however, if both can be eliminated, both will be
llvm-svn: 185290
|
|
|
|
|
|
| |
false instead of give a compile time error, always. The problem was down in ____mu_return, the version that handles nested bind objects. This fixes http://llvm.org/bugs/show_bug.cgi?id=16343
llvm-svn: 185289
|
|
|
|
|
|
| |
typo or two.
llvm-svn: 185288
|
|
|
|
|
|
| |
Apparently, there are platforms where the clang defaults are different from gcc
llvm-svn: 185287
|
|
|
|
| |
llvm-svn: 185286
|
|
|
|
| |
llvm-svn: 185285
|
|
|
|
|
|
|
|
| |
trying to remove a sext from a compare.
Fixes PR16462.
llvm-svn: 185284
|
|
|
|
| |
llvm-svn: 185283
|
|
|
|
|
|
|
|
|
| |
before the value computation of the result. In C, this is implied by there being
a sequence point after their evaluation, and in C++, it's implied by the
side-effects being sequenced before the expressions and statements in the
function body.
llvm-svn: 185282
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
standard's rule that an extern "C" declaration conflicts with any entity in the
global scope with the same name. Now we only care if the global scope entity is
a variable declaration (and so might have the same mangled name as the extern
"C" declaration). This has been reported as a standard defect.
Original commit message:
PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.
When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.
When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).
llvm-svn: 185281
|
|
|
|
| |
llvm-svn: 185280
|
|
|
|
|
|
|
| |
WalkUpFromLambdaExpr, so that the Visit* functions are called
on that AST node.
llvm-svn: 185277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicitly specify use of C++98 or C++11. Lang_CXX is preserved as
an alias for Lang_CXX98.
This does not add Lang_CXX1Y or Lang_C11, on the assumption that it's
better to add them if/when they are needed.
(This is a prerequisite for a test in a later patch for RecursiveASTVisitor.)
Reviewed by Richard Smith.
llvm-svn: 185276
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by user
code to specify what version of POSIX the system should provide. If
you want to check what version of POSIX is actually available, you're
supposed to test _POSIX_VERSION.
However, since sysconf() has been in POSIX since 1995, it's probably
safe to assume it's available on any system with a C++11 compiler,
especially if _SC_NPROCESSORS_ONLN is defined too. So no point in a
complicated preprocessor rule if just we unconditionally include
<unistd.h> (on non-Windows systems).
Also, I've added a #warning for to help porters detect when a suitable
implementation isn't detected at compile-time.
Howard: Matthew, can you patch CREDITS.TXT? Thanks.
llvm-svn: 185275
|
|
|
|
|
|
| |
'len strlen(msg)', so we can use memcpy() instead of strcpy().
llvm-svn: 185274
|
|
|
|
|
|
| |
http://llvm.org/bugs/show_bug.cgi?id=16240. Sorry, I can not think of a good test case for this one, except by running valgrind as reported in the bug.
llvm-svn: 185273
|
|
|
|
|
|
|
|
|
| |
X is a power of two
This allows us to simplify urem instructions involving the add+xor to
turn into simpler math.
llvm-svn: 185272
|
|
|
|
|
|
| |
Avoids unused variable warnings in release builds.
llvm-svn: 185271
|
|
|
|
|
|
|
|
|
| |
don't match.
Inserting a zext or trunc is sufficient. This pattern is somewhat common in
LLVM's pointer mangling code.
llvm-svn: 185270
|
|
|
|
|
|
|
| |
operator++ on an enum is not legal. clang happens to accept it anyways, I think
that's a known bug.
llvm-svn: 185269
|
|
|
|
| |
llvm-svn: 185268
|
|
|
|
| |
llvm-svn: 185267
|
|
|
|
| |
llvm-svn: 185266
|
|
|
|
|
|
| |
and libc++ to see if this error occurred elsewhere and didn't see any other place. This fixes http://llvm.org/bugs/show_bug.cgi?id=16207
llvm-svn: 185265
|
|
|
|
| |
llvm-svn: 185264
|
|
|
|
| |
llvm-svn: 185263
|
|
|
|
| |
llvm-svn: 185262
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 185261
|
|
|
|
|
|
|
|
|
|
|
| |
Orignally, we first test if a ValueMap contains a Value, and than use the
index operator to get the corresponding new value. This requires the ValueMap
to lookup the key (i.e. the old value) twice.
Now, we directly use the "lookup" function provided by DenseMap to implement
the same functionality.
llvm-svn: 185260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changing the sign when comparing the base pointer would introduce all
sorts of unexpected things like:
%gep.i = getelementptr inbounds [1 x i8]* %a, i32 0, i32 0
%gep2.i = getelementptr inbounds [1 x i8]* %b, i32 0, i32 0
%cmp.i = icmp ult i8* %gep.i, %gep2.i
%cmp.i1 = icmp ult [1 x i8]* %a, %b
%cmp = icmp ne i1 %cmp.i, %cmp.i1
ret i1 %cmp
into:
%cmp.i = icmp slt [1 x i8]* %a, %b
%cmp.i1 = icmp ult [1 x i8]* %a, %b
%cmp = xor i1 %cmp.i, %cmp.i1
ret i1 %cmp
By preserving the original sign, we now get:
ret i1 false
This fixes PR16483.
llvm-svn: 185259
|
|
|
|
| |
llvm-svn: 185258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Real world code sometimes has the denominator of a 'udiv' be a
'select'. LLVM can handle such cases but only when the 'select'
operands are symmetric in structure (both select operands are a constant
power of two or a left shift, etc.). This falls apart if we are dealt a
'udiv' where the code is not symetric or if the select operands lead us
to more select instructions.
Instead, we should treat the LHS and each select operand as a distinct
divide operation and try to optimize them independently. If we can
to simplify each operation, then we can replace the 'udiv' with, say, a
'lshr' that has a new select with a bunch of new operands for the
select.
llvm-svn: 185257
|