| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This commit adds back the code that seems to have been dropped unintentionally
in r176985.
rdar://problem/13752163
Differential Revision: http://reviews.llvm.org/D10100
llvm-svn: 239426
|
|
|
|
|
|
|
|
|
|
| |
GCC mangles long double like __float128 in order to support
compatibility with ABI variants which had a different interpretation of
long double.
This fixes PR23791.
llvm-svn: 239421
|
|
|
|
|
|
|
| |
This reverts commit r239415. This was committed accidentally, LLVM isn't
ready for this.
llvm-svn: 239417
|
|
|
|
|
|
|
|
| |
This reverts r236167.
LLVM should be ready for this now.
llvm-svn: 239415
|
|
|
|
|
|
| |
This revision just fixes the formatting of altivec.h.
llvm-svn: 239408
|
|
|
|
|
|
| |
Patch by Nick Sumner!
llvm-svn: 239406
|
|
|
|
| |
llvm-svn: 239404
|
|
|
|
| |
llvm-svn: 239400
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have not succeeded in writing a proper test case for this yet and we
also need to solve the underlying fundamental problem of trying too
many combinations with nested blocks (basically this somewhat works
around our Dijkstra algorithm). Preventing this linebreak is good
anyways as usually the penalties never make us choose it (that's why I
can't create a test) and it also looks ugly.
Also cleaned up state comparison code that I discovered while hunting
this down.
llvm-svn: 239398
|
|
|
|
|
|
|
|
|
| |
This matches the cl.exe behavior (tested with 18.00.31101). In order to
specify an output file for /P, use the /Fi option instead.
Differential Revision: http://reviews.llvm.org/D10313
llvm-svn: 239393
|
|
|
|
|
|
|
|
| |
The object file format is sometimes overridden for MSVC targets to use
ELF instead of COFF. Make sure we preserve this choice when setting the
msvc version number in the triple.
llvm-svn: 239388
|
|
|
|
|
|
|
|
| |
The machinery added to permit a static_cast from void-ptr to fn-ptr
unintentionally gets triggered for c-style casts and function-style
casts. The observable effect was a diagnostic issued inappropriately.
llvm-svn: 239382
|
|
|
|
|
|
|
| |
We already have Args->filtered(...) which is a drop-in range-for
replacement.
llvm-svn: 239381
|
|
|
|
|
|
| |
We weren't using the short-circuiting property anyway.
llvm-svn: 239376
|
|
|
|
|
|
|
|
| |
This is a follow-up to r225570 which enabled adding DLL attributes when a
class template goes from explicit instantiation declaration to explicit
instantiation definition.
llvm-svn: 239375
|
|
|
|
|
|
|
|
| |
instantiation declaration
This is a follow-up to r238266 which failed to take MinGW into account.
llvm-svn: 239374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates in some cases
It is safe to add a dll attribute if the base class template previously only had
an explicit instantiation declaration, or was implicitly instantiated.
I both those cases, the members would not have been codegenned yet. In the case
of explicit instantiation declaration this is natural, and for implicit
instantiations, codegen is deferred (see r225570).
This is work towards fixing PR23770.
llvm-svn: 239373
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't warn about not being able to propagate dll attribute to a base class template
when that base already has a different attribute.
MSVC doesn't actually try to do this; the first attribute that was propagated
takes precedence, so Clang is already doing the right thing and there's no
need to warn.
(This is a step towards fixing PR21718.)
llvm-svn: 239372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are still problems here, but this is a better starting point.
The main part of the change is: when doing a lookup that would accept visible
or hidden declarations, prefer to produce the latest visible declaration if
there are any visible declarations, rather than always producing the latest
declaration.
Thus, when we inherit default arguments (and other properties) from a previous
declaration, we inherit them from the previous visible declaration; if the
previous declaration is hidden, we already suppress inheritance of default
arguments.
There are a couple of other changes here that fix latent bugs exposed by this
change.
llvm-svn: 239371
|
|
|
|
| |
llvm-svn: 239365
|
|
|
|
|
|
| |
When pragma clang loop unroll() is specified without an argument the diagnostic message should inform that user that 'full' and 'disable' are valid arguments (not 'enable').
llvm-svn: 239363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This modifies Clang to reflect that under pre-C99 ISO C, decimal
constants may have type `unsigned long` even if they do not contain `u`
or `U` in their suffix (C90 subclause 6.1.3.2 paragraph 5). The same is
done for C++ without C++11 which--because of undefined behaviour--allows
for behaviour compatible with ISO C90 in the case of an unsuffixed
decimal literal and is otherwise identical to C90 in its treatment of
integer literals (C++03 subclause 2.13.1 [lex.icon] paragraph 2).
Messages are added to the `c99-compat` and `c++11-compat` groups to warn
on such literals, since they behave differently under the newer
standards.
Fixes PR 16678.
Test Plan:
A new test file is added to exercise both pre-C99/C++11 and C99/C++11-up
on decimal literals with no suffix or suffixes `l`/`L` for both 32-bit
and 64-bit `long`.
In the file, 2^31 (being `INT_MAX+1`) is tested for the expected type
using `__typeof__` and multiple declarations of the same entity. 2^63
is similarly tested when it is within the range of `unsigned long`.
Preprocessor arithmetic tests are added to ensure consistency given
that Clang (like GCC) uses greater than 32 bits for preprocessor
arithmetic even when `long` and `unsigned long` is 32 bits and a
pre-C99/C++11 mode is in effect.
Tests added:
test/Sema/PR16678.c
Reviewers: fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9794
llvm-svn: 239356
|
|
|
|
|
|
|
|
|
|
| |
unused result detection)
This patch fixes issues with unused result detection which were found in patch http://reviews.llvm.org/D9743.
Differential Revision: http://reviews.llvm.org/D10042
llvm-svn: 239294
|
|
|
|
|
|
|
| |
Encoding the version into the triple will allow us to communicate to
LLVM what functions it can expect to depend upon in the implementation.
llvm-svn: 239273
|
|
|
|
|
|
|
|
| |
No documentation yet; the linker needs more work.
Differential Revision: http://reviews.llvm.org/D10270
llvm-svn: 239213
|
|
|
|
|
|
|
|
| |
It's better not to rely on the diagnostics engine to pretty print the
argument to decltype. Instead, exercise the functionality in
DeclPrinterTest.
llvm-svn: 239197
|
|
|
|
| |
llvm-svn: 239194
|
|
|
|
|
|
| |
and update all callers.
llvm-svn: 239193
|
|
|
|
|
|
| |
This change was unrelated to r239170.
llvm-svn: 239176
|
|
|
|
|
|
|
|
|
|
| |
We would crash in the DeclPrinter trying to pretty-print the
static_assert message. C++1z-style assertions don't have a message so
we would crash.
This fixes PR23756.
llvm-svn: 239170
|
|
|
|
|
|
|
|
|
|
|
| |
Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9
layout for sparc (32bit), sparc (32bit) with lib64 multilib, and
sparc64.
The test cases added here also cover r239047, which fixed the linker
paths.
llvm-svn: 239154
|
|
|
|
|
|
|
|
|
|
|
|
| |
input / output with memory constraint.
One generally can't get address of a bit field, so the general solution is to
error on such cases. GCC does the same.
Patch by Andrey Bokhanko
Differential Revision: http://reviews.llvm.org/D10086
llvm-svn: 239153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main effect of this is to fix anomalies where certain -mfpu options didn't
disable everything that they should causing strange behaviour when combined
with -mcpu or -march values that themselves enabled fpu subtarget features,
e.g. -mfpu=fpv5-dp-d16 with -march=armv7em previously behaved the same as
-mfpu=fpv5-sp-d16 due to fp-only-sp not being disabled.
Invalid -mfpu options now also give an error, which is consistent with the
handling of the .fpu directive.
Differential Revision: http://reviews.llvm.org/D10239
llvm-svn: 239152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
template <typename T>
auto aaaaaaaaaaaaaaaaaaaaaa(T t) -> decltype(eaaaaaaaaaaaaaaa<T>(t.a)
.aaaaaaaa());
After:
template <typename T>
auto aaaaaaaaaaaaaaaaaaaaaa(T t)
-> decltype(eaaaaaaaaaaaaaaa<T>(t.a).aaaaaaaa());
Also add a test case for a difficult template parsing case I stumbled accross.
Needs fixing.
llvm-svn: 239149
|
|
|
|
| |
llvm-svn: 239140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a more correct representation than using "Equality" introduced
in r238942 which was a quick fix to solve an actual regression.
According to the typescript spec, arrows behave like "low-precedence"
assignments.
Before:
var a = a.aaaaaaa((a: a) => aaaaaaaaaaaaaaaaaaaaa(bbbbbbbbb) &&
aaaaaaaaaaaaaaaaaaaaa(bbbbbbb));
After:
var a = a.aaaaaaa((a: a) => aaaaaaaaaaaaaaaaaaaaa(bbbbbbbbb) &&
aaaaaaaaaaaaaaaaaaaaa(bbbbbbb));
llvm-svn: 239137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch enables lexing of `concept` and `requires` as keywords.
Further changes which add messages for future keyword compat are to
follow.
Test Plan:
Testing of C++14 + Concepts TS mode is added to
`test/Lexer/keywords_test.cpp`, which expects that the new keywords are
enabled under said mode.
Reviewers: faisalv, fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10233
llvm-svn: 239128
|
|
|
|
| |
llvm-svn: 239123
|
|
|
|
|
|
| |
Fixes trailing whitespace in lib/Sema/JumpDiagnostics.cpp.
llvm-svn: 239112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
following r239099
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10256
llvm-svn: 239101
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vector Programming" from appendix A of the OpenPOWER ABI for Linux Supplement document.
I also added tests for the new functions and updated another test that was looking for specific line numbers in error messages from altivec.h.
https://llvm.org/bugs/show_bug.cgi?id=23679
http://reviews.llvm.org/D10131
llvm-svn: 239066
|
|
|
|
| |
llvm-svn: 239064
|
|
|
|
|
|
|
| |
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option.
llvm-svn: 239059
|
|
|
|
| |
llvm-svn: 239047
|
|
|
|
|
|
|
|
| |
They should be 'int' instead of 'long int' everywhere else except
NetBSD too, from what I gather in GCC's spec files. So, optimistically
changing it for everyone else, too.
llvm-svn: 239046
|
|
|
|
| |
llvm-svn: 239038
|
|
|
|
| |
llvm-svn: 239028
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On ARM/AArch64, we currently always use EmitScalarExpr for the immediate
builtin arguments, instead of directly emitting the constant. When the
overflow sanitizer is enabled, this generates overflow intrinsics
instead of constants, breaking assumptions in various places.
Instead, use the knowledge of "immediates" to directly emit a constant:
- teach the tablegen backend to emit the "immediate" modifiers
- use those modifiers in the NEON CodeGen, on ARM and AArch64.
Fixes PR23517.
Differential Revision: http://reviews.llvm.org/D10045
llvm-svn: 239002
|
|
|
|
| |
llvm-svn: 238993
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10224
llvm-svn: 238992
|