| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
On Linux there is no separate notion of a process (vs. a thread) for
ptrace(); each thread needs to be individually detached. On FreeBSD
we have a separate process context, and we detach just it.
Review: http://llvm-reviews.chandlerc.com/D1418
llvm-svn: 189666
|
|
|
|
| |
llvm-svn: 189665
|
|
|
|
| |
llvm-svn: 189664
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Almost by accident, clang-format seems to be able to format protocol
buffer definitions (https://code.google.com/p/protobuf/).
The only change is that a space is required between numeric constants
and opening square brackets (for default values). While this might in
theory be used for array subscripts (int val = 4[MyArray]), I have not
seen this pattern in practice much. If this is wrong, we can make this
smarter in the future.
llvm-svn: 189663
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
namespace n {
enum Type {
One,
Two, // missing };
int i;
} void g() {
}
After:
namespace n {
enum Type {
One,
Two, // missing };
int i;
}
void g() {}
llvm-svn: 189662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This never really worked. Even if we find and execute link.exe in the VS bin dir
this way, link.exe wouldn't find the DLLs it needs, libraries, etc.
It also causes trouble when the user has multiple versions of VS installed,
one of them is in the path, but this code finds the other one (PR17041).
Revert until we can fix this properly.
> Windows ToolChain: add VS bin dir to PogramPaths
>
> We have a lot of fancy logic to find Visual Studio, which is currently used
> to set the system header include paths.
>
> Use the same code to set the ProgramPaths, which is used for finding programs
> such as link.exe. Previously, Clang would just search PATH for link.exe,
> but now it should find it if it's able to find Visual Studio.
llvm-svn: 189661
|
|
|
|
| |
llvm-svn: 189660
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, Sema was reusing parts of the AST when synthesizing an assignment
operator, turning it into a AS-dag. This caused problems for the static
analyzer, which assumed an expression appears in the tree only once.
Here I make sure to always create a fresh Expr, when inserting something into
the AST, fixing PR16745 in the process.
Reviewers: doug.gregor
CC: cfe-commits, jordan_rose
Differential Revision: http://llvm-reviews.chandlerc.com/D1425
llvm-svn: 189659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccccc(
dddddddddddddddddddddddddddddd));
aaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(
dddddddddddddddddddddddddddddd));
After:
aaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccccc(
dddddddddddddddddddddddddddddd));
aaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(
dddddddddddddddddddddddddddddd));
This was overlooked when interducing the new builder-type call
detection in r189337. Also, some minor reorganization of a test.
llvm-svn: 189658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While this looks kind of nice, it wastes horizontal space and does not
seem to be common in the LLVM codebase.
Before:
return llvm::StringSwitch<Reference::Kind>(name)
.StartsWith(".eh_frame_hdr", ORDER_EH_FRAMEHDR)
.StartsWith(".eh_frame", ORDER_EH_FRAME)
.StartsWith(".init", ORDER_INIT)
.StartsWith(".fini", ORDER_FINI)
.StartsWith(".hash", ORDER_HASH)
.Default(ORDER_TEXT);
After:
return llvm::StringSwitch<Reference::Kind>(name)
.StartsWith(".eh_frame_hdr", ORDER_EH_FRAMEHDR)
.StartsWith(".eh_frame", ORDER_EH_FRAME)
.StartsWith(".init", ORDER_INIT)
.StartsWith(".fini", ORDER_FINI)
.StartsWith(".hash", ORDER_HASH)
.Default(ORDER_TEXT);
llvm-svn: 189657
|
|
|
|
| |
llvm-svn: 189656
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaaaa()->aaaaaaaaaaaaaae(
0)->aaaaaaaaaaaaaaa();
After:
aaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaaaa()
->aaaaaaaaaaaaaae(0)
->aaaaaaaaaaaaaaa();
llvm-svn: 189655
|
|
|
|
| |
llvm-svn: 189654
|
|
|
|
|
|
| |
Y), -1)). Fixes PR17038.
llvm-svn: 189653
|
|
|
|
|
|
|
| |
The patch was discussed in Phabricator. See:
http://llvm-reviews.chandlerc.com/D1281
llvm-svn: 189649
|
|
|
|
|
|
|
|
| |
This reverts commit r189619.
The commit was breaking the arm_neon_intrinsic test.
llvm-svn: 189648
|
|
|
|
| |
llvm-svn: 189647
|
|
|
|
|
|
| |
from a PCH/module.
llvm-svn: 189646
|
|
|
|
| |
llvm-svn: 189645
|
|
|
|
|
|
| |
Based on a patch by Benno Rice!
llvm-svn: 189644
|
|
|
|
|
|
|
| |
This removes all expensive pressure tracking logic from the scheduling
critical path of node comparison.
llvm-svn: 189643
|
|
|
|
|
|
| |
Return true for LRGs that end at EarlyClobber or Register slots.
llvm-svn: 189642
|
|
|
|
|
|
|
| |
Only compare pressure within the same set. When multiple sets are
affected, we prioritize the most constrained set.
llvm-svn: 189641
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
liveness later.
Created SUPressureDiffs array to hold the per node PDiff computed during DAG building.
Added a getUpwardPressureDelta API that will soon replace the old
one. Compute PressureDelta here from the precomputed PressureDiffs.
Updating for liveness will come next.
llvm-svn: 189640
|
|
|
|
|
|
|
| |
Mostly trivial patch adding support for compares. The meat of the
work was added with the branch support.
llvm-svn: 189639
|
|
|
|
| |
llvm-svn: 189638
|
|
|
|
|
|
|
| |
Here are a few more tests that now pass after the recent fast-isel
commits.
llvm-svn: 189637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the next big chunk of fast-isel code. The primary purpose is
to implement selection of loads and stores, but there is a lot of
drag-along to support this. The common code to analyze addresses for
both loads and stores is substantial. It's also necessary to add the
materialization code for global values.
Related to load-store processing is the code to fold loads into
integer extends, since otherwise we generate lots of redundant
instructions. We also need to add some overrides to some FastEmit
routines to ensure we don't assign GPR 0 to a virtual register when
this would change the meaning of an instruction.
I added handling selection of a few binary arithmetic instructions, to
enable committing some test cases I wrote a while back.
Finally, ap couple of miscellaneous changes:
* I cleaned up some poor style from a previous patch in
PPCISelLowering.cpp, pointed out by David Blaikie.
* I enlarged the Addr.Offset field to avoid sign problems with 32-bit
offsets.
llvm-svn: 189636
|
|
|
|
| |
llvm-svn: 189635
|
|
|
|
| |
llvm-svn: 189634
|
|
|
|
|
|
|
|
|
| |
again.
This test should a) test IR or be moved, and b) get an actual option
for the dwarf pub sections.
llvm-svn: 189633
|
|
|
|
|
|
| |
createInternalizePass uses an ArrayRef.
llvm-svn: 189632
|
|
|
|
|
|
| |
any maintained consumers of it on that platform.
llvm-svn: 189631
|
|
|
|
| |
llvm-svn: 189630
|
|
|
|
|
|
| |
decl chains.
llvm-svn: 189629
|
|
|
|
|
|
| |
should infer migration to NS_OPTIONS.
llvm-svn: 189628
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
these in eagerly if we're not actually processing a translation unit. The added
laziness here also avoids us loading in parts of a CXXRecordDecl earlier than an
upcoming class template specialization merging patch would like.
Ideally, we should mark the vtable as used when we see a definition for the key
function, rather than having a separate pass over dynamic classes at the end of
the TU. The existing approach is pretty bad for PCH/modules, since it forcibly
loads the declarations of all key functions in all imported modules, whether or
not those key functions are defined.
llvm-svn: 189627
|
|
|
|
| |
llvm-svn: 189626
|
|
|
|
|
|
|
|
| |
I changed the diagnostic printing code because it's probably better
to cut off a digit from DBL_MAX than to print something like
1.300000001 when the user wrote 1.3.
llvm-svn: 189625
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a re-commit of r189442; I'll follow up with clang changes.
The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.
I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.
llvm-svn: 189624
|
|
|
|
| |
llvm-svn: 189623
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use CXX mangler to generate unique identifier for external C++ struct,
union, class and enum. Types with unique identifier are added to retained
types by DIBuilder.
Testing cases are updated to reflect the unique identifier generated for types.
The order of MDNodes is changed because of retained types and testing cases
are updated accordingly.
Testing case debug-info-uuid.cpp now emits error with Itanium mangler, since
uuid is not yet handled in Itanium mangler. And it will check for the error
message.
llvm-svn: 189622
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
createClassType, createStructType, createUnionType, createEnumerationType,
and createForwardDecl will retain a type when created with a unique identifier,
to make sure they are treated as used even when all uses are replaced with
the identifiers.
Use TrackingVH<MDNode> instead of MDNode in AllRetainTypes, since the created
node can later be updated.
The change will be tested when clients of DIBuilder start to pass in non-empty
unique identifier.
llvm-svn: 189621
|
|
|
|
| |
llvm-svn: 189620
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to recognizing when the multiply's second argument is
coming from an explicit VDUPLANE, also look for a plain scalar
f32 reference and reference it via the corresponding vector
lane.
rdar://14870054
llvm-svn: 189619
|
|
|
|
| |
llvm-svn: 189618
|
|
|
|
| |
llvm-svn: 189617
|
|
|
|
|
|
| |
Patch by chris.wailes@gmail.com.
llvm-svn: 189616
|
|
|
|
|
|
|
| |
Requires shuffling the CPack code up before add_subdirectory(tools), but
that's where the version settings are anyway.
llvm-svn: 189615
|
|
|
|
| |
llvm-svn: 189614
|