| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
catches uses of an extremely minor and widely-available C++ extension (which
every C++ compiler I could find supports, but EDG and Clang reject in strict
mode).
The diagnosed code pattern looks like this:
struct X {
union {
struct {
int a;
int b;
} S;
};
};
llvm-svn: 174103
|
|
|
|
| |
llvm-svn: 174102
|
|
|
|
| |
llvm-svn: 174101
|
|
|
|
| |
llvm-svn: 174100
|
|
|
|
|
|
|
| |
Patch by: Vincent Lejeune
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 174099
|
|
|
|
|
|
|
| |
Patch by: Vincent Lejeune
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 174098
|
|
|
|
|
|
|
| |
Patch by: Vincent Lejeune
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 174097
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This matches our behavior for autorelease pools created by +alloc. Some
people like to create autorelease pools in one method and release them
somewhere else.
If you want safe autorelease pool semantics, use the new ARC-compatible
syntax: @autoreleasepool { ... }
<rdar://problem/13121353>
llvm-svn: 174096
|
|
|
|
|
|
|
|
|
|
| |
you happen to have stopped in it due to a crash.)
Make the message when you hit an crash while evaluating an expression a little clearer, and mention "thread return -x".
rdar://problem/13110464
llvm-svn: 174095
|
|
|
|
| |
llvm-svn: 174094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a re-worked version of r174048.
Given source IR:
call void @llvm.dbg.declare(metadata !{i32* %argc.addr}, metadata !14), !dbg !15
we used to generate
call void @llvm.dbg.declare(metadata !27, metadata !28), !dbg !29
!27 = metadata !{null}
With this patch, we will correctly generate
call void @llvm.dbg.declare(metadata !{i32* %argc.addr}, metadata !27), !dbg !28
Looking up %argc.addr in ValueMap will return null, since %argc.addr is already
correctly set up, we can use identity mapping.
rdar://problem/13089880
llvm-svn: 174093
|
|
|
|
| |
llvm-svn: 174092
|
|
|
|
| |
llvm-svn: 174091
|
|
|
|
|
|
|
|
|
|
| |
Attributes that are strings are typically target-dependent attributes. They are
of this form in the IR:
"attr"
"attr" = "val"
llvm-svn: 174090
|
|
|
|
|
|
| |
- Also, change the exit code to match 'sh'.
llvm-svn: 174089
|
|
|
|
| |
llvm-svn: 174088
|
|
|
|
|
|
| |
- Testing finds bugs, who knew.
llvm-svn: 174087
|
|
|
|
| |
llvm-svn: 174086
|
|
|
|
|
|
| |
past the natural stack alignment.
llvm-svn: 174085
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to create children DIEs for a scope, then check whether ScopeDIE is
null. If ScopeDIE is null, the children DIEs will be dangling. Other DIEs can
link to those dangling DIEs, which are not emitted at all, causing dwarf error.
The current testing case is 4k lines, from MultiSource/BenchMark/McCat/09-vor.
rdar://problem/13071959
llvm-svn: 174084
|
|
|
|
|
|
|
| |
Each target implementation was needlessly recomputing the index.
Part of rdar://13076458
llvm-svn: 174083
|
|
|
|
|
|
|
|
| |
expressions.
<rdar://problem/13121442>
llvm-svn: 174082
|
|
|
|
|
|
|
|
|
| |
This allows people to use Unicode in their #pragma mark and in macros
that exist only to be string-ized.
<rdar://problem/13107323&13121362>
llvm-svn: 174081
|
|
|
|
| |
llvm-svn: 174080
|
|
|
|
| |
llvm-svn: 174079
|
|
|
|
| |
llvm-svn: 174078
|
|
|
|
|
|
|
| |
Compilation always sets this explicitly, but creating a preprocessor
manually should still put the 'IsPreprocessedOutput' flag in a valid state.
llvm-svn: 174077
|
|
|
|
| |
llvm-svn: 174076
|
|
|
|
| |
llvm-svn: 174075
|
|
|
|
| |
llvm-svn: 174074
|
|
|
|
|
|
|
|
|
| |
gcc produces false positives for empty braces so turning the warning off.
Instead, turning the warning on for clang so proper warnings aren't missed.
Reviewers: dblaikie, chandlerc
llvm-svn: 174073
|
|
|
|
| |
llvm-svn: 174072
|
|
|
|
| |
llvm-svn: 174071
|
|
|
|
|
|
| |
- Also, kill the pointless LitFormats module.
llvm-svn: 174070
|
|
|
|
|
|
|
|
|
| |
It's causing hangs on our internal analyzer buildbot. Will restore after
investigating.
This reverts r173951 / baa7ca1142990e1ad6d4e9d2c73adb749ff50789.
llvm-svn: 174069
|
|
|
|
| |
llvm-svn: 174068
|
|
|
|
|
|
| |
boundaries
llvm-svn: 174067
|
|
|
|
| |
llvm-svn: 174065
|
|
|
|
|
|
| |
XFAIL:mingw32, for now.
llvm-svn: 174064
|
|
|
|
|
|
| |
Just put it in one unwrapped line and let the formatter handle it.
llvm-svn: 174063
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Never avoid bin packing in static initializers as this can
lead to terrible results.
2. If an element has to be broken over multiple lines, break after
the following comma.
This should be a step forward, but there are still many cases
especially with nested static initializers that we handle badly.
More patches will follow.
llvm-svn: 174061
|
|
|
|
| |
llvm-svn: 174060
|
|
|
|
|
|
| |
tool name
llvm-svn: 174059
|
|
|
|
|
|
| |
that makes sure users can include interface header
llvm-svn: 174058
|
|
|
|
| |
llvm-svn: 174057
|
|
|
|
| |
llvm-svn: 174056
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In cooperation with the LLVM patch, this should implement all scalar front-end
parts of the C and C++ ABIs for AArch64.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for AArch64 (ARM's 64-bit architecture) to
LLVM in the "experimental" category. Currently, it won't be built
unless requested explicitly.
This initial commit should have support for:
+ Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions
(except the late addition CRC instructions).
+ CodeGen features required for C++03 and C99.
+ Compilation for the "small" memory model: code+static data <
4GB.
+ Absolute and position-independent code.
+ GNU-style (i.e. "__thread") TLS.
+ Debugging information.
The principal omission, currently, is performance tuning.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174054
|
|
|
|
|
|
| |
by it again!
llvm-svn: 174053
|
|
|
|
|
|
| |
breakage with builds without X86-support.
llvm-svn: 174052
|