| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
macro history.
When deserializing macro history, we arrange history such that the
macros that have definitions (that haven't been #undef'd) and are
visible come at the beginning of the list, which is what the
preprocessor and other clients of Preprocessor::getMacroInfo()
expect. If additional macro definitions become visible later, they'll
be moved toward the front of the list. Note that it's possible to have
ambiguities, but we don't diagnose them yet.
There is a partially-implemented design decision here that, if a
particular identifier has been defined or #undef'd within the
translation unit, that definition (or #undef) hides any macro
definitions that come from imported modules. There's still a little
work to do to ensure that the right #undef'ing happens.
Additionally, we'll need to scope the update records for #undefs, so
they only kick in when the submodule containing that update record
becomes visible.
llvm-svn: 165682
|
| |
|
|
|
|
| |
CLANG_ANALYZER_EXEC.
llvm-svn: 165681
|
| |
|
|
|
|
|
|
|
| |
value but later turns out to be a function.
Unfortunately, we can't fold tests into a single file because we only get one
error out of llvm-as.
llvm-svn: 165680
|
| |
|
|
| |
llvm-svn: 165679
|
| |
|
|
|
|
| |
member operator(). PR14057.
llvm-svn: 165678
|
| |
|
|
| |
llvm-svn: 165677
|
| |
|
|
|
|
|
|
| |
This time, actually uncomment the code that's supposed to fix the problem.
This reverts r165671 / 8ceb837585ed973dc36fba8dfc57ef60fc8f2735.
llvm-svn: 165676
|
| |
|
|
|
|
|
|
|
| |
auto x((unknown));
int& y = x;
would crash because we were not flagging 'x' as an invalid declaration here.
llvm-svn: 165675
|
| |
|
|
|
|
|
|
|
| |
in a category class method, don't read 'isa' pointer. Instead,
save the desired OBJC_METACLASS_$_ClassName in
__DATA,__objc_superrefs and read that without reading any
isa pointers. // rdar://12459358
llvm-svn: 165674
|
| |
|
|
| |
llvm-svn: 165673
|
| |
|
|
|
|
| |
lldb_private::Declaration - make a GetDeclaration() API on SBValue to return a declaration. This will only work for vroot variables as they are they only objects for which we currently provide a valid Declaration
llvm-svn: 165672
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
offsets."
Author: Jordan Rose <jordan_rose@apple.com>
Date: Wed Oct 10 21:31:21 2012 +0000
[analyzer] Treat fields of unions as having symbolic offsets.
This allows only one field to be active at a time in RegionStore.
This isn't quite the correct behavior for unions, but it at least
would handle the case of "value goes in, value comes out" from the
same field.
RegionStore currently has a number of places where any access to a union
results in UnknownVal being returned. However, it is clearly missing
some cases, or the original issue wouldn't have occurred. It is probably
now safe to remove those changes, but that's a potentially destabilizing
change that should wait for more thorough testing.
Fixes PR14054.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165660 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit cf9030e480f77ab349672f00ad302e216c26c92c.
llvm-svn: 165671
|
| |
|
|
| |
llvm-svn: 165670
|
| |
|
|
| |
llvm-svn: 165669
|
| |
|
|
| |
llvm-svn: 165668
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Author: Michael J. Spencer <bigcheesegs@gmail.com>
Date: Wed Oct 10 21:48:26 2012 +0000
[Options] make Option a value type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165663 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 0464fd5e4ce2193e786e5adcab6b828f9366dae3.
llvm-svn: 165667
|
| |
|
|
| |
llvm-svn: 165666
|
| |
|
|
|
|
| |
information.
llvm-svn: 165665
|
| |
|
|
| |
llvm-svn: 165664
|
| |
|
|
| |
llvm-svn: 165663
|
| |
|
|
|
|
|
|
|
| |
each instruction,
to once in the AssemblyParse_x86 ctor.
an instruction
llvm-svn: 165662
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original message:
The attached is the fix to radar://11663049. The optimization can be outlined by following rules:
(select (x != c), e, c) -> select (x != c), e, x),
(select (x == c), c, e) -> select (x == c), x, e)
where the <c> is an integer constant.
The reason for this change is that : on x86, conditional-move-from-constant needs two instructions;
however, conditional-move-from-register need only one instruction.
While the LowerSELECT() sounds to be the most convenient place for this optimization, it turns out to be a bad place. The reason is that by replacing the constant <c> with a symbolic value, it obscure some instruction-combining opportunities which would otherwise be very easy to spot. For that reason, I have to postpone the change to last instruction-combining phase.
The change passes the test of "make check-all -C <build-root/test" and "make -C project/test-suite/SingleSource".
llvm-svn: 165661
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows only one field to be active at a time in RegionStore.
This isn't quite the correct behavior for unions, but it at least
would handle the case of "value goes in, value comes out" from the
same field.
RegionStore currently has a number of places where any access to a union
results in UnknownVal being returned. However, it is clearly missing
some cases, or the original issue wouldn't have occurred. It is probably
now safe to remove those changes, but that's a potentially destabilizing
change that should wait for more thorough testing.
Fixes PR14054.
llvm-svn: 165660
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the compiler makes use of GPR0. However, there are two flavors of
GPR0 defined by the target: the 32-bit GPR0 (R0) and the 64-bit GPR0
(X0). The spill/reload code makes use of R0 regardless of whether we
are generating 32- or 64-bit code.
This patch corrects the problem in the obvious manner, using X0 and
ADDI8 for 64-bit and R0 and ADDI for 32-bit.
llvm-svn: 165658
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the Altivec extensions were introduced. Its use is optional, and
allows the compiler to communicate to the operating system which
vector registers should be saved and restored during a context switch.
In practice, this information is ignored by the various operating
systems using the SVR4 ABI; the kernel saves and restores the entire
register state. Setting the VRSAVE register is no longer performed by
the AIX XL compilers, the IBM i compilers, or by GCC on Power Linux
systems. It seems best to avoid this logic within LLVM as well.
This patch avoids generating code to update and restore VRSAVE for the
PowerPC SVR4 ABIs (32- and 64-bit). The code remains in place for the
Darwin ABI.
llvm-svn: 165656
|
| |
|
|
|
|
|
|
|
|
| |
absolute minimum required set. This allows a backend to expand any arbitrary set of comparisons as long as a minimum set is supported.
The minimum set of required instructions is ISD::AND, ISD::OR, ISD::SETO(or ISD::SETOEQ) and ISD::SETUO(or ISD::SETUNE). Everything is expanded into one of two patterns:
Pattern 1: (LHS CC1 RHS) Opc (LHS CC2 RHS)
Pattern 2: (LHS CC1 LHS) Opc (RHS CC2 RHS)
llvm-svn: 165655
|
| |
|
|
|
|
| |
... Apparently the RTTI is still necessary for some reason.
llvm-svn: 165654
|
| |
|
|
| |
llvm-svn: 165653
|
| |
|
|
| |
llvm-svn: 165652
|
| |
|
|
|
|
| |
TableGen no longer needs RTTI!
llvm-svn: 165651
|
| |
|
|
|
|
| |
clang-tblgen no longer needs RTTI!
llvm-svn: 165650
|
| |
|
|
| |
llvm-svn: 165649
|
| |
|
|
| |
llvm-svn: 165648
|
| |
|
|
|
|
| |
Also, some minor cleanup.
llvm-svn: 165647
|
| |
|
|
|
|
|
|
|
|
| |
Some of these dyn_cast<>'s would be better phrased as isa<> or cast<>.
That will happen in a future patch.
There are also two dyn_cast_or_null<>'s slipped in instead of
dyn_cast<>'s, since they were causing crashes with just dyn_cast<>.
llvm-svn: 165646
|
| |
|
|
| |
llvm-svn: 165645
|
| |
|
|
|
|
| |
the new sroa pass handles it right).
llvm-svn: 165644
|
| |
|
|
|
|
|
|
|
|
| |
methods looking for documentation on a particular base
class inherited by any method that overrides the base class.
In case of redeclaration, as when objc method is defined
in the implementation, it also looks up for documentation
in class/class extension being redeclared.
llvm-svn: 165643
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ProcessSP. We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP.
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.
<rdar://problem/12383087>
llvm-svn: 165640
|
| |
|
|
| |
llvm-svn: 165639
|
| |
|
|
| |
llvm-svn: 165638
|
| |
|
|
| |
llvm-svn: 165636
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...but do run them on user headers.
Previously, we were inconsistent here: non-path-sensitive checks on code
/bodies/ were only run in the main source file, but checks on
/declarations/ were run in /all/ headers. Neither of those is the
behavior we want.
Thanks to Sujit for pointing this out!
<rdar://problem/12454226>
llvm-svn: 165635
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 165634
|
| |
|
|
|
|
|
| |
There are only two other instances of using `.. code::` instead of
`.. code-block::`.
llvm-svn: 165633
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hypothesis 1: use of `.. code::` directive instead of `.. code-block::`
is causing Sphinx to discard the block. On my machine, `.. code::`
renders fine. However, I don't think that `.. code::` is actually a
legit Sphinx directive. I believe that on my machine Sphinx is falling
back to just displaying it monospace with no syntax, whereas llvm.org's
Sphinx is just discarding it.
This is truly "remote debugging" since I can't reproduce this on my
machine. It would be helpful to be able to see the llvm.org Sphinx
build logs; if that's possible please let me know.
llvm-svn: 165632
|
| |
|
|
|
|
|
|
|
|
| |
- Due to the current matching vector elements constraints in
ISD::FP_ROUND, rounding from v2f64 to v4f32 (after legalization from
v2f32) is scalarized. Add a customized v2f32 widening to convert it
into a target-specific X86ISD::VFPROUND to work around this
constraints.
llvm-svn: 165631
|
| |
|
|
|
|
| |
users should be able to override them with "unalias" but you can't unalias normal commands.
llvm-svn: 165630
|
| |
|
|
|
|
|
| |
Reading from a weak property, casting the result, and assigning to a
strong pointer should still be considered safe.
llvm-svn: 165629
|
| |
|
|
|
|
|
|
| |
Then, switch users of PropertyIfSetterOrGetter and LookupPropertyDecl
(the latter by name) over to findPropertyDecl. This actually makes
-Wreceiver-is-weak a bit stronger than it was before.
llvm-svn: 165628
|