| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: I left --build-system for backwards compat, in case there are scripts using it. Feel free to ask for its removal too.
Reviewers: chapuni, tstellarAMD
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17886
llvm-svn: 262924
|
|
|
|
| |
llvm-svn: 262923
|
|
|
|
| |
llvm-svn: 262922
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to the template cases in r262050, when a C++ method in an
unavailable struct/class calls unavailable API, don't diagnose an error.
I.e., this case was failing:
void foo() __attribute__((unavailable));
struct __attribute__((unavailable)) A {
void bar() { foo(); }
};
Since A is unavailable, A::bar is allowed to call foo. However, we were
emitting a diagnostic here. This commit checks up the context chain
from A::bar, in a manner inspired by SemaDeclAttr.cpp:isDeclUnavailable.
I expected to find other related issues but failed to trigger them:
- I wondered if DeclBase::getAvailability should check for
`TemplateDecl` instead of `FunctionTemplateDecl`, but I couldn't find
a way to trigger this. I left behind a few extra tests to make sure
we don't regress.
- I wondered if Sema::isFunctionConsideredUnavailable should be
symmetric, checking up the context chain of the callee (this commit
only checks up the context chain of the caller). However, I couldn't
think of a testcase that didn't require first referencing the
unavailable type; this, we already diagnose.
rdar://problem/25030656
llvm-svn: 262921
|
|
|
|
| |
llvm-svn: 262920
|
|
|
|
| |
llvm-svn: 262919
|
|
|
|
|
|
| |
This commit removes pr25342 for reverting r262670 clearly.
llvm-svn: 262918
|
|
|
|
| |
llvm-svn: 262917
|
|
|
|
|
|
| |
This reverts commit r262670 due to compile failure.
llvm-svn: 262916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to r261512, which made the 'strict' availability
attribute flag behave like 'unavailable'. However, that fix was
insufficient. The following case would (erroneously) error when the
deployment target was older than 10.9:
struct __attribute__((availability(macosx,strict,introduced=10.9))) A;
__attribute__((availability(macosx,strict,introduced=10.9))) void f(A*);
The use of A* in the argument list for f is valid here, since f and A
have the same availability.
The fix is to return AR_Unavailable from DeclBase::getAvailability
instead of AR_NotYetIntroduced. This also reverts the special handling
added in r261163, instead relying on the well-tested logic for
AR_Unavailable.
rdar://problem/23791325
llvm-svn: 262915
|
|
|
|
| |
llvm-svn: 262914
|
|
|
|
| |
llvm-svn: 262913
|
|
|
|
|
|
|
|
| |
- move alias help generation to CommandAlias, out of CommandInterpreter
- make alias creation use argument strings instead of OptionArgVectorSP; the former is a more reasonable currency than the latter
- remove m_is_alias from CommandObject, it wasn't actually being used
llvm-svn: 262912
|
|
|
|
|
|
|
|
| |
The variables corresponding to command line options are named mechanically.
Because the option for the variable is -noinhibit-exec and not -no-inhibit-exec,
it should be name this way.
llvm-svn: 262911
|
|
|
|
|
|
|
| |
GNU ld and gold have these paths as default search paths.
If you don't want these directories, pass -nostdlib.
llvm-svn: 262910
|
|
|
|
|
|
|
| |
Eventually, there will be more things that CommandAlias contains, and I don't want accessors for each of them on the CommandIntepreter
Eventually, we also won't pass around copies of CommandAlias, but that's for a later patch
llvm-svn: 262909
|
|
|
|
|
|
| |
Should fix the breakage in r262902.
llvm-svn: 262908
|
|
|
|
| |
llvm-svn: 262907
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and scalar
We follow the comments mentioned in http://reviews.llvm.org/D16842#344378 to
implement this new patch.
This patch implements the following vsx instructions:
Vector load/store:
lxv lxvx lxvb16x lxvl lxvll lxvh8x lxvwsx
stxv stxvb16x stxvh8x stxvl stxvll stxvx
Scalar load/store:
lxsd lxssp lxsibzx lxsihzx
stxsd stxssp stxsibx stxsihx
21 instructions
Phabricator: http://reviews.llvm.org/D16919
llvm-svn: 262906
|
|
|
|
|
|
| |
template function in lldb_private
llvm-svn: 262905
|
|
|
|
| |
llvm-svn: 262904
|
|
|
|
|
|
|
| |
Also note that the operand order changed; the default label is now listed
after the regular labels.
llvm-svn: 262903
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This re-applies r262886 with a fix for 32 bit platforms that have 8 byte
pointer alignment, effectively reverting r262892.
Original Message:
Currently some SDNode operands are malloc'd, some are stored inline in
subclasses of SDNode, and some are thrown into a BumpPtrAllocator.
This scheme is complex, inconsistent, and makes refactoring SDNodes
fairly difficult.
Instead, we can allocate all of the operands using an ArrayRecycler
that wraps a BumpPtrAllocator. This keeps the cache locality when
iterating operands, improves locality when iterating SDNodes without
looking at operands, and vastly simplifies the ownership semantics.
It also means we stop overallocating SDNodes by 2-3x and will make it
simpler to fix the rampant undefined behaviour we have in how we
mutate SDNodes from one kind to another (See llvm.org/pr26808).
This is NFC other than the changes in memory behaviour, and I ran some
LNT tests to make sure this didn't hurt compile time. Not many tests
changed: there were a couple of 1-2% regressions reported, but there
were more improvements (of up to 4%) than regressions.
llvm-svn: 262902
|
|
|
|
|
|
|
|
| |
any instance data on the CommandInterpreter anyway
This small step removes one piece of alias machinery from the CommandInterpreter into the CommandAlias
llvm-svn: 262901
|
|
|
|
|
|
|
|
|
|
|
| |
the alias -> underlying command binding and another map holds the alias -> options, to a model where one single map holds the alias -> (all useful data) combination
Right now, obviously, this is just the pair of (CommandObjectSP,OptionArgVectorSP), so NFC
This is step one of a larger - and tricky - refactoring which will turn command aliases into interesting objects instead of passive storage that the command interpreter does smart things to
This refactoring, in turn, will allow us to do interesting things with aliases, such as intelligent and customizable help
llvm-svn: 262900
|
|
|
|
|
|
|
|
| |
parser.
Thanks to Ahmed Bougacha for noticing!
llvm-svn: 262899
|
|
|
|
| |
llvm-svn: 262898
|
|
|
|
| |
llvm-svn: 262897
|
|
|
|
| |
llvm-svn: 262896
|
|
|
|
|
|
|
|
| |
The doxygen comments are automatically generated based on Sony's intrinsics document.
I got an OK from Eric Christopher to commit doxygen comments without prior code review upstream.
llvm-svn: 262895
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the wide character strdup variants (wcsdup, _wcsdup) and the MSVC
version of alloca (_alloca) and other differently named function used
by the Malloc checker.
A patch by Alexander Riccio!
Differential Revision: http://reviews.llvm.org/D17688
llvm-svn: 262894
|
|
|
|
|
|
| |
register class.
llvm-svn: 262893
|
|
|
|
|
|
|
|
|
| |
Looks like the largest SDNode is different between 32 and 64 bit now,
so this is breaking 32 bit bots. Reverting while I figure out a fix.
This reverts r262886.
llvm-svn: 262892
|
|
|
|
| |
llvm-svn: 262891
|
|
|
|
|
|
|
|
| |
instructions.
By complex types, I mean aggregate or vector types.
llvm-svn: 262890
|
|
|
|
| |
llvm-svn: 262889
|
|
|
|
| |
llvm-svn: 262888
|
|
|
|
|
|
| |
year is it?!)
llvm-svn: 262887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently some SDNode operands are malloc'd, some are stored inline in
subclasses of SDNode, and some are thrown into a BumpPtrAllocator.
This scheme is complex, inconsistent, and makes refactoring SDNodes
fairly difficult.
Instead, we can allocate all of the operands using an ArrayRecycler
that wraps a BumpPtrAllocator. This keeps the cache locality when
iterating operands, improves locality when iterating SDNodes without
looking at operands, and vastly simplifies the ownership semantics.
It also means we stop overallocating SDNodes by 2-3x and will make it
simpler to fix the rampant undefined behaviour we have in how we
mutate SDNodes from one kind to another (See llvm.org/pr26808).
This is NFC other than the changes in memory behaviour, and I ran some
LNT tests to make sure this didn't hurt compile time. Not many tests
changed: there were a couple of 1-2% regressions reported, but there
were more improvements (of up to 4%) than regressions.
llvm-svn: 262886
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions.
Before this change, we would get the type definition in the middle
of the instruction.
E.g., %0(48) = G_ADD %struct_alias = type { i32, i16 } %edi, %edi
Now, we have just the expected type name:
%0(48) = G_ADD %struct_alias %edi, %edi
llvm-svn: 262885
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without actually parsing a type it is difficult to perdict where
the type definition ends. In other words, instead of expecting
the user of the parser API to hand over only the relevant bits
of the string being parsed, take the whole string, parse the type,
and get back the number of characters that have been read.
This will be used by the MIR testing infrastructure.
llvm-svn: 262884
|
|
|
|
| |
llvm-svn: 262883
|
|
|
|
| |
llvm-svn: 262882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exactly the same as clang's existing [[clang::fallthrough]] attribute, which
has been updated to have the same semantics. The one significant difference
is that [[fallthrough]] is ill-formed if it's not used immediately before a
switch label (even when -Wimplicit-fallthrough is disabled). To support that,
we now build a CFG of any function that uses a '[[fallthrough]];' statement
to check.
In passing, fix some bugs with our support for statement attributes -- in
particular, diagnose their use on declarations, rather than asserting.
llvm-svn: 262881
|
|
|
|
| |
llvm-svn: 262880
|
|
|
|
| |
llvm-svn: 262879
|
|
|
|
| |
llvm-svn: 262878
|
|
|
|
|
|
|
|
| |
llvm-config can know tell whether or not a build has been configured to support
global-isel.
Use '--has-global-isel' for that.
llvm-svn: 262877
|
|
|
|
|
|
|
|
|
|
| |
TSan instrumentation functions for atomic stores, loads, and cmpxchg work on
integer value types. This patch adds casts before calling TSan instrumentation
functions in cases where the value is a pointer.
Differential Revision: http://reviews.llvm.org/D17833
llvm-svn: 262876
|
|
|
|
|
|
|
|
| |
This should make it clearer how this proposed patch:
http://reviews.llvm.org/D11393
...will change codegen.
llvm-svn: 262875
|