| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
members
Flexible array members only work out if they are the last field of a
record, however virtual bases would give us many situations where the
flexible array member would overlap with the virtual base fields.
It is unlikely in the extreme that this behavior was intended by the
user so raise a diagnostic instead of accepting. This is will not
reject conforming code because flexible array members are an extension
in C++ mode.
llvm-svn: 193920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The determination of which diagnostics would be issued for certain
anonymous unions started to get a little ridiculous. Clean this up by
inverting the condition-tree's logic from dialect -> issue to
issue -> diagnostic.
As part of this cleanup, move ext_c99_flexible_array_member from
DiagnosticParseKinds.td to DiagnosticSemaKinds.td because it's driven by
Sema, not Parse.
Also, the liberty was taken to edit ext_c99_flexible_array_member to
match other, similar, diagnostics.
llvm-svn: 193919
|
|
|
|
|
|
|
| |
The declaration of a flexible array member was correctly diagnosed as an
extension in C89 mode but not in C++.
llvm-svn: 193918
|
|
|
|
|
|
|
| |
- Don't seek "entry:" It dosen't appear with -Asserts.
- Take care that Codegen'ed Instruction(s) wouldn't have name(s) in -Asserts.
llvm-svn: 193908
|
|
|
|
|
|
|
| |
specializations. Also switch to -Wuninitialized for a test case that depended
on a warning firing in template specializations.
llvm-svn: 193906
|
|
|
|
| |
llvm-svn: 193902
|
|
|
|
|
|
|
| |
long in linux 64 is 64 bits but is always 32 bits on windows. The lit test was modified
to use long long instead of long and check for 64-bit mangling.
llvm-svn: 193901
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2090
Clang was "improperly" over-aligning arrays with sizes are not a multiple of
their alignment.
This behavior was removed in microsoft 32 bit mode.
In addition, after examination of ASTContext::getTypeInfoImpl, a redundant code block in
MicrosoftRecordLayoutBuilder::getAdjustedFieldInfo was deleted.
llvm-svn: 193898
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2082
Adds a lang_c LinkageSpecDecl to lazily generated builtins. This enforces correct
behavior for builtins in a variety of cases without special treatment elsewhere within
the compiler (special treatment is removed by the patch). It also allows for C++
overloads of builtin functions, which Microsoft uses in their headers e.g.
_InterlockedExchangeAdd is an extern C builtin for the long type but an inline wrapper
for int type.
llvm-svn: 193896
|
|
|
|
|
|
| |
warning in template specializations.
llvm-svn: 193890
|
|
|
|
|
|
|
|
|
|
|
| |
-fobjc-subscripting-legacy-runtime which is off
by default and on only when using ObjectiveC
legacy runtime. Use this flag to allow
array and dictionary subscripting and disallow
objectiveC pointer arithmatic in ObjectiveC
legacy runtime. // rdar://15363492
llvm-svn: 193889
|
|
|
|
| |
llvm-svn: 193888
|
|
|
|
| |
llvm-svn: 193887
|
|
|
|
|
|
|
|
|
|
|
|
| |
The thread, memory, dataflow and function sanitizers are now diagnosed if
enabled explicitly on an unsupported platform. Unsupported sanitizers which
are enabled implicitly (as part of a larger group) are silently disabled. As a
side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus
essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain.
Differential Revision: http://llvm-reviews.chandlerc.com/D1990
llvm-svn: 193875
|
|
|
|
| |
llvm-svn: 193858
|
|
|
|
|
|
|
|
| |
(microsoft) mode
Please see http://llvm-reviews.chandlerc.com/D2053 for discussion and Richard's stamp.
llvm-svn: 193849
|
|
|
|
|
|
|
|
|
|
| |
do not remove the setter if its availability differs
from availability of the getter (which is now turned into
a property). Otherwise, synthesized setter will
inherit availability of the property (which is incorrect).
// rdar://15300059
llvm-svn: 193837
|
|
|
|
|
|
| |
instructions.
llvm-svn: 193817
|
|
|
|
| |
llvm-svn: 193799
|
|
|
|
| |
llvm-svn: 193791
|
|
|
|
|
|
|
|
|
| |
This was just left unimplemnted from r191381; the fix is to report this call
location as the location of the 'delete' expr.
PR17746
llvm-svn: 193783
|
|
|
|
|
|
|
| |
deprecated categories, fixes a typo reported by
Jordan.
llvm-svn: 193759
|
|
|
|
|
|
|
|
|
|
| |
Enables the clang driver to begin targeting specific CPUs. Introduced a
"generic" CPU which will ensure that the optional FP feature is enabled
by default when it gets to LLVM, without needing any extra arguments.
Cortex-A53 and A-57 are also introduced with tests, although backend
handling of them does not yet exist.
llvm-svn: 193740
|
|
|
|
|
|
|
|
|
| |
into a separate "parse an attribute that takes a type argument" codepath. This
results in both codepaths being a lot cleaner and simpler, and fixes some bugs
where the type argument handling bled into the expression argument handling and
caused us to both accept invalid and reject valid attribute arguments.
llvm-svn: 193731
|
|
|
|
|
|
|
| |
a category with NSxxxDeprecated name with deprecated
annotation. // rdar://15337661
llvm-svn: 193726
|
|
|
|
|
|
| |
We don't support these options, but should at least parse them.
llvm-svn: 193702
|
|
|
|
| |
llvm-svn: 193695
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
normal IR (i.e. not intrinsics)
Also corrected the definition of the intrinsics for these instructions (the
result register is also the first operand), and added intrinsics for bsel and
bseli to clang (they already existed in the backend).
These four operations are mostly equivalent to bsel, and bseli (the difference
is which operand is tied to the result). As a result some of the tests changed
as described below.
bitwise.ll:
- bsel.v test adapted so that the mask is unknown at compile-time. This stops
it emitting bmnzi.b instead of the intended bsel.v.
- The bseli.b test now tests the right thing. Namely the case when one of the
values is an uimm8, rather than when the condition is a uimm8 (which is
covered by bmnzi.b)
compare.ll:
- bsel.v tests now (correctly) emits bmnz.v instead of bsel.v because this
is the same operation (see MSA.txt).
i8.ll
- CHECK-DAG-ized test.
- bmzi.b test now (correctly) emits equivalent bmnzi.b with swapped operands
because this is the same operation (see MSA.txt).
- bseli.b still emits bseli.b though because the immediate makes it
distinguishable from bmnzi.b.
vec.ll:
- CHECK-DAG-ized test.
- bmz.v tests now (correctly) emits bmnz.v with swapped operands (see
MSA.txt).
- bsel.v tests now (correctly) emits bmnz.v with swapped operands (see
MSA.txt).
llvm-svn: 193693
|
|
|
|
| |
llvm-svn: 193692
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not intrinsics)
This required correcting the definition of the bins[lr]i intrinsics because
the result is also the first operand.
It also required removing the (arbitrary) check for 32-bit immediates in
MipsSEDAGToDAGISel::selectVSplat().
Currently using binsli.d with 2 bits set in the mask doesn't select binsli.d
because the constant is legalized into a ConstantPool. Similar things can
happen with binsri.d with more than 10 bits set in the mask. The resulting
code when this happens is correct but not optimal.
llvm-svn: 193687
|
|
|
|
| |
llvm-svn: 193686
|
|
|
|
|
|
|
| |
It's possible to embed the frontend in applications that haven't initialized
backend targets so we need to handle this condition gracefully.
llvm-svn: 193685
|
|
|
|
|
|
|
|
| |
adjustment when using -cxx-abi microsoft
Reviewed at http://llvm-reviews.chandlerc.com/D2026
llvm-svn: 193679
|
|
|
|
|
|
|
| |
scope, be careful about function-scope declarations (which are not declared in
their semantic context).
llvm-svn: 193671
|
|
|
|
| |
llvm-svn: 193664
|
|
|
|
| |
llvm-svn: 193648
|
|
|
|
|
|
| |
Patch by Jeff Muizelaar.
llvm-svn: 193642
|
|
|
|
| |
llvm-svn: 193640
|
|
|
|
| |
llvm-svn: 193622
|
|
|
|
|
|
| |
reduce code duplication
llvm-svn: 193610
|
|
|
|
| |
llvm-svn: 193608
|
|
|
|
|
|
|
|
|
|
|
| |
The AST was constructed so that this builtin returned the default BoolTy and
since I'd opted for custom SemaChecking, I should have set it properly at that
point.
This caused an assertion failure when the types didn't match up with what we
generated. This makes it return an IntTy, which is as good as anything.
llvm-svn: 193606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which doesn't use that multilib. As a consequence, fix Clang's support
for cross compiling environments that were relying on this quirk to
ensure the correct library search path ordering.
This also re-instates the new test cases from Rafael's r193528 for
cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the
existing test cases (they were no longer needed).
This solution was the result of a lot of IRC debugging and trying to
understand *exactly* what quirk was being relied upon. It took some time
for me to figure out that it was the use of 'lib32' is a multilib that
was throwing a wrench in the works.
In case you are thinking that its silly to use a multilib of 'lib' at
all, entertainingly, GCC does so as well (you can see it with the
.../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of
search paths (multilib followed by non-multilib) has observable (if
dubious) consequences. =/ Yuck.
llvm-svn: 193601
|
|
|
|
|
|
|
|
| |
Allow users to disable or enable CRC subtarget feature.
Differential Revision: http://llvm-reviews.chandlerc.com/D2037
llvm-svn: 193600
|
|
|
|
|
|
| |
[[gnu::no_address_safety_analysis]].
llvm-svn: 193583
|
|
|
|
|
|
| |
the difference.
llvm-svn: 193582
|
|
|
|
| |
llvm-svn: 193578
|
|
|
|
| |
llvm-svn: 193561
|
|
|
|
|
|
|
|
| |
This reverts commit r193528 (and fixes).
It broke Chandler's setup.
llvm-svn: 193554
|
|
|
|
|
|
|
|
|
|
|
|
| |
requires ! feature
The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).
llvm-svn: 193549
|