| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and is unrelated to the NEON intrinsics in arm_neon.h. On little
endian machines it works fine, however on big endian machines it
exhibits surprising behaviour:
uint32x2_t x = {42, 64};
return vget_lane_u32(x, 0); // Will return 64.
Because of this, explicitly call out that it is unsupported on big
endian machines.
This patch will emit the following warning in big-endian mode:
test.c:3:15: warning: vector initializers are a GNU extension and are not compatible with NEON intrinsics [-Wgnu]
int32x4_t x = {0, 1, 2, 3};
^
test.c:3:15: note: consider using vld1q_s32() to initialize a vector from memory, or vcombine_s32(vcreate_s32(), vcreate_s32()) to initialize from integer constants
1 warning generated.
llvm-svn: 211362
|
| |
|
|
| |
llvm-svn: 211361
|
| |
|
|
|
|
|
|
|
|
| |
On PowerPC LE the system uses the /lib64/ld64.so.2 dynamic linker name
instead of /lib64/ld64.so.1 (to indicate the ELFv2 ABI version).
This fixes the clang driver to pass the appropriate -dynamic-linker
setting, and adds some more tests to linux-ld.c.
llvm-svn: 211360
|
| |
|
|
|
|
|
|
|
|
| |
There was already partial support for multi-arch on powerpc64le,
but the MultiarchIncludeDirs setting was missing. This patch
adds the appropriate definition, and also extends the
linux-header-search.cpp test case to verify an Ubuntu 14.04
powerpc64le tree.
llvm-svn: 211359
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D4222
llvm-svn: 211357
|
| |
|
|
|
|
|
| |
Add module flags metadata to record the settings for enum and wchar width,
to allow correct ARM build attribute generation
llvm-svn: 211354
|
| |
|
|
| |
llvm-svn: 211352
|
| |
|
|
| |
llvm-svn: 211347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When adding the implicit compound statement (required for Codegen?), the
end location was previously overridden by the start location, probably
based on the assumptions:
* The location of the compound statement should be the member's location
* The compound statement if present is the last element of a FunctionDecl
This patch changes the location of the compound statement to the
member's end location.
Code review: http://reviews.llvm.org/D4175
llvm-svn: 211344
|
| |
|
|
| |
llvm-svn: 211342
|
| |
|
|
|
|
|
|
| |
a qualified-id type because pointer is object of a forward
class declaration, include this info in a diagnostic note.
// rdar://10751015
llvm-svn: 211324
|
| |
|
|
|
|
|
| |
Checking the filesystem seems to be a bit unreliable. Limit the tests
to the VFS map for now.
llvm-svn: 211310
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the -module-dependency-dir to clang -cc1, which specifies a
directory to copy all of a module's dependencies into in a form
suitable to be used as a VFS using -ivfsoverlay with the generated
vfs.yaml.
This is useful for crashdumps that involve modules, so that the module
dependencies will be intact when a crash report script is used to
reproduce a problem on another machine.
We currently encode the absolute path to the dump directory, due to
limitations in the VFS system. Until we can handle relative paths in
the VFS, users of the VFS map may need to run a simple search and
replace in the file.
llvm-svn: 211303
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a crash when handling malformed arguments to loop pragmas such
as: "#pragma clang loop vectorize(()". Essentially any argument which is not an
identifier or constant resulted in a crash. This patch also changes a couple of
the error messages which weren't quite correct. New behavior with this patch vs
old behavior:
#pragma clang loop vectorize(1)
OLD: error: missing keyword; expected 'enable' or 'disable'
NEW: error: invalid argument; expected 'enable' or 'disable'
#pragma clang loop vectorize()
OLD: error: expected ')'
NEW: error: missing argument to loop pragma 'vectorize'
#pragma clang loop vectorize_width(bad)
OLD: error: missing value; expected a positive integer value
NEW: error: invalid argument; expected a positive integer value
#pragma clang loop vectorize(bad)
OLD: invalid keyword 'bad'; expected 'enable' or 'disable'
NEW: error: invalid argument; expected 'enable' or 'disable'
http://reviews.llvm.org/D4197
Patch by Mark Heffernan
llvm-svn: 211292
|
| |
|
|
|
|
|
| |
Fix clang tests to not break if the ID numbers of module flags metadata
nodes change.
llvm-svn: 211276
|
| |
|
|
|
|
|
|
| |
property accesses used with overloaded binary operators.
rdar://17153478
llvm-svn: 211270
|
| |
|
|
|
|
|
|
|
|
|
|
| |
super-terse notation
for (x : range) { ... }
which is equivalent to
for (auto &&x : range) { ... }
llvm-svn: 211267
|
| |
|
|
|
|
| |
sharing attributes and reformatting
llvm-svn: 211262
|
| |
|
|
|
|
|
|
| |
retainable ObjC pointers without requiring a bridge-cast
in the context of pointer comparison as this is in effect
a +0 context. // rdar://16627903
llvm-svn: 211243
|
| |
|
|
|
|
|
|
|
|
|
| |
CL permits static redeclarations to follow extern declarations. The
storage specifier on the latter declaration has no effect.
This fixes PR20034.
Differential Revision: http://reviews.llvm.org/D4149
llvm-svn: 211238
|
| |
|
|
| |
llvm-svn: 211237
|
| |
|
|
|
|
|
| |
retainable ObjC pointers without requiring a bridge-cast
by recognizing this as a +0 context. // rdar://16627903
llvm-svn: 211234
|
| |
|
|
|
|
|
|
|
|
| |
Relax the tests to allow for differences between release and debug builds. This
should fix the buildbots.
Thanks to Benjamin Kramer and Eric Christo for their invaluable tip that this
was release build specific issue.
llvm-svn: 211227
|
| |
|
|
| |
llvm-svn: 211224
|
| |
|
|
|
|
|
| |
This patch enables clang to generate calls to __RTtypeid when lowering
typeid on win32 targets. Test cases are included.
llvm-svn: 211223
|
| |
|
|
|
|
|
|
|
| |
Add support for _InterlockedCompareExchangePointer, _InterlockExchangePointer,
_InterlockExchange. These are available as a compiler intrinsic on ARM and x86.
These are used directly by the Windows SDK headers without use of the intrin
header.
llvm-svn: 211216
|
| |
|
|
|
|
| |
boxed expression. // rdar://16417427
llvm-svn: 211215
|
| |
|
|
|
|
|
|
| |
Doing this caused us to mistakenly think we'd seen a particular state before
when we actually hadn't, which resulted in false negatives. Credit to
Rafael Auler for discovering this issue!
llvm-svn: 211209
|
| |
|
|
| |
llvm-svn: 211197
|
| |
|
|
|
|
|
| |
to forward class declarations for diagnosis.
// rdar://16681279
llvm-svn: 211195
|
| |
|
|
|
|
|
|
|
|
| |
Patch by Ehsan Akhgari!
(Tiny tweak by me: renamed PathSegment to LibDir.)
Differential Revision: http://reviews.llvm.org/D4192
llvm-svn: 211189
|
| |
|
|
|
|
| |
The backend option does not have an '-enable' prefix.
llvm-svn: 211177
|
| |
|
|
|
|
|
|
| |
This makes us handle static locals in exported/imported functions correctly.
Differential Revision: http://reviews.llvm.org/D4136
llvm-svn: 211173
|
| |
|
|
|
|
|
|
| |
In the final phase of the merge, I managed to disable a bunch of Clang
tests accidentally. Fortunately none of them seem to have broken in
the interim.
llvm-svn: 211149
|
| |
|
|
|
|
| |
MSVC).
llvm-svn: 211140
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When instantiating dllimport variables with dynamic initializers, don't
bail out of Sema::InstantiateVariableInitializer without calling
PopExpressionEvaluationContext().
This was causing a stale object to stay on the ExprEvalContexts stack,
causing subsequent calls to getCurrentMangleNumberContext() to fail,
resulting in incorrect numbering of static locals (and probably other
broken things).
llvm-svn: 211137
|
| |
|
|
|
|
|
|
|
| |
IBOutlet and weak attributes when accessed being
unpredictably set to nil because usage of such properties
are always single threaded and its ivar cannot be set
to nil asynchronously. // rdar://15885642
llvm-svn: 211132
|
| |
|
|
|
|
|
|
| |
This reverts commit r211096. Looks like it broke the msvc build:
SemaOpenMP.cpp(140) : error C4519: default template arguments are only allowed on a class template
llvm-svn: 211113
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There comes a time in the life of any amateur code generator when dumb string
concatenation just won't cut it any more. For NeonEmitter.cpp, that time has
come.
There were a bunch of magic type codes which meant different things depending on
the context. There were a bunch of special cases that really had no reason to be
there but the whole thing was so creaky that removing them would cause something
weird to fall over. There was a 1000 line switch statement for code generation
involving string concatenation, which actually did lexical scoping to an extent
(!!) with a bunch of semi-repeated cases.
I tried to refactor this three times in three different ways without
success. The only way forward was to rewrite the entire thing. Luckily the
testing coverage on this stuff is absolutely massive, both with regression tests
and the "emperor" random test case generator.
The main change is that previously, in arm_neon.td a bunch of "Operation"s were
defined with special names. NeonEmitter.cpp knew about these Operations and
would emit code based on a huge switch. Actually this doesn't make much sense -
the type information was held as strings, so type checking was impossible. Also
TableGen's DAG type actually suits this sort of code generation very well
(surprising that...)
So now every operation is defined in terms of TableGen DAGs. There are a bunch
of operators to use, including "op" (a generic unary or binary operator), "call"
(to call other intrinsics) and "shuffle" (take a guess...). One of the main
advantages of this apart from making it more obvious what is going on, is that
we have proper type inference. This has two obvious advantages:
1) TableGen can error on bad intrinsic definitions easier, instead of just
generating wrong code.
2) Calls to other intrinsics are typechecked too. So
we no longer need to work out whether the thing we call needs to be the Q-lane
version or the D-lane version - TableGen knows that itself!
Here's an example: before:
case OpAbdl: {
std::string abd = MangleName("vabd", typestr, ClassS) + "(__a, __b)";
if (typestr[0] != 'U') {
// vabd results are always unsigned and must be zero-extended.
std::string utype = "U" + typestr.str();
s += "(" + TypeString(proto[0], typestr) + ")";
abd = "(" + TypeString('d', utype) + ")" + abd;
s += Extend(utype, abd) + ";";
} else {
s += Extend(typestr, abd) + ";";
}
break;
}
after:
def OP_ABDL : Op<(cast "R", (call "vmovl", (cast $p0, "U",
(call "vabd", $p0, $p1))))>;
As an example of what happens if you do something wrong now, here's what happens
if you make $p0 unsigned before the call to "vabd" - that is, $p0 -> (cast "U",
$p0):
arm_neon.td:574:1: error: No compatible intrinsic found - looking up intrinsic 'vabd(uint8x8_t, int8x8_t)'
Available overloads:
- float64x2_t vabdq_v(float64x2_t, float64x2_t)
- float64x1_t vabd_v(float64x1_t, float64x1_t)
- float64_t vabdd_f64(float64_t, float64_t)
- float32_t vabds_f32(float32_t, float32_t)
... snip ...
This makes it seriously easy to work out what you've done wrong in fairly nasty
intrinsics.
As part of this I've massively beefed up the documentation in arm_neon.td too.
Things still to do / on the radar:
- Testcase generation. This was implemented in the previous version and not in
the new one, because
- Autogenerated tests are not being run. The testcase in test/ differs from
the autogenerated version.
- There were a whole slew of special cases in the testcase generation that just
felt (and looked) like hacks.
If someone really feels strongly about this, I can try and reimplement it too.
- Big endian. That's coming soon and should be a very small diff on top of this one.
llvm-svn: 211101
|
| |
|
|
|
|
|
| |
Patch by Janusz Sobczak (slightly extended).
This fixes llvm.org/19929.
llvm-svn: 211098
|
| |
|
|
| |
llvm-svn: 211096
|
| |
|
|
|
|
|
|
| |
Patch by Ehsan Akhgari!
Differential Revision: http://reviews.llvm.org/D4143
llvm-svn: 211081
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4165
llvm-svn: 211079
|
| |
|
|
|
|
|
|
|
|
| |
We may not have the mangling for static locals vs. enums completely figured out,
but at least for my simple test cases, enums should not increment the mangling
number.
Differential Revision: http://reviews.llvm.org/D4164
llvm-svn: 211078
|
| |
|
|
| |
llvm-svn: 211075
|
| |
|
|
|
|
| |
rdar://9283021
llvm-svn: 211064
|
| |
|
|
|
|
|
|
| |
__builtin_arm_rbit() and __builtin_arm_rbit64().
rdar://9283021
llvm-svn: 211060
|
| |
|
|
|
|
|
|
| |
Reverse the bits in a word. Maps to the RBIT instruction.
rdar://9283021
llvm-svn: 211059
|
| |
|
|
|
|
|
| |
record, mark all subsequent decls as 'used' too, to maintain the AST invariant
that getPreviousDecl()->Used implies this->Used.
llvm-svn: 211050
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The RTTI scheme for x86_64 is largely the same as the one for i386.
Differences are largely limited to avoiding load-time relocations by
replacing pointers to RTTI metadata with the difference of that data
relative to the load address of the module.
Interestingly, this precludes the possibility of successfully using RTTI
data from another DLL. The ImageBase reference is always relative to
the current DLL.
Differential Revision: http://reviews.llvm.org/D4148
llvm-svn: 211041
|