| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Also update "test/Modules/macros.c" to test modified semantics:
-When there is an ambiguous macro, expand using the latest introduced version, not the first one.
-#undefs in submodules cause the macro to not be exported by that submodule, it doesn't cause
undefining of macros in the translation unit that imported that submodule.
This reduces macro namespace interference across modules.
llvm-svn: 178105
|
| |
|
|
|
|
| |
unnecessary c_str() calls. Reformatted with clang-format.
llvm-svn: 178104
|
| |
|
|
|
|
|
|
| |
uninstantiated exception specification when a special member within a class
template is both defaulted and given an exception specification on its first
declaration.
llvm-svn: 178103
|
| |
|
|
|
|
|
| |
backend output; there's no need to report a fatal error. This reverts r178042.
Part of rdar://13295753 and rdar://13401547
llvm-svn: 178102
|
| |
|
|
|
|
|
|
|
| |
The test was removed since I had not turned off the test during release
builds. This fails since ARC annotations support is conditionally
compiled out during release builds. I added the proper requires header
to assuage this issue.
llvm-svn: 178101
|
| |
|
|
|
|
|
| |
This accounts for the addition of another field to DIScopes that will be used
to store a list of DIImportedModules in the future.
llvm-svn: 178100
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is just the basic groundwork for supporting DW_TAG_imported_module but I
wanted to commit this before pushing support further into Clang or LLVM so that
this rather churny change is isolated from the rest of the work. The major
churn here is obviously adding another field (within the common DIScope prefix)
to all DIScopes (files, classes, namespaces, lexical scopes, etc). This should
be the last big churny change needed for DW_TAG_imported_module/using directive
support/PR14606.
llvm-svn: 178099
|
| |
|
|
|
|
|
| |
declarations at any point. Patch by Alexander Zinenko, and
report by Richard Smith.
llvm-svn: 178098
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously all unimplemented methods for a class were grouped under
a single warning, with all the unimplemented methods mentioned
as notes. Based on feedback from users, most users would like
a separate warning for each method, with a note pointing back to
the original method declaration.
Implements <rdar://problem/13350414>
llvm-svn: 178097
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As Bill Schmidt pointed out to me, only on Darwin do we need to spill/restore
VRSAVE in the SjLj code. For non-Darwin, don't spill/restore VRSAVE (and I've
added some asserts to make sure that we're not).
As it turns out, we're not currently handling the Darwin case correctly (I've
added a FIXME in the test case). I've tried adding various implied register
definitions/uses to force the spill without success, so I'll need to address
this later.
llvm-svn: 178096
|
| |
|
|
|
|
| |
reference to an lvalue of compatible type.
llvm-svn: 178095
|
| |
|
|
|
|
| |
Jordan pointed out that my previously committed test was bogus.
llvm-svn: 178094
|
| |
|
|
|
|
|
|
|
| |
Register the nil tracking visitors with the region and refactor trackNullOrUndefValue a bit.
Also adds the cast and paren stripping before checking if the value is an OpaqueValueExpr
or ExprWithCleanups.
llvm-svn: 178093
|
| |
|
|
|
|
| |
DICompositeType::setContainingType
llvm-svn: 178092
|
| |
|
|
|
|
| |
rather than DIType
llvm-svn: 178091
|
| |
|
|
|
|
| |
usage in Clang
llvm-svn: 178090
|
| |
|
|
|
|
|
| |
to execute as the crash will surely reoccur while generating the diagnostics.
rdar://13362359
llvm-svn: 178089
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
returns consistent results with invalid types.
When Sema::RequireCompleteType() is given a class template
specialization type that then fails to instantiate, it returns
'true'. On subsequent invocations, it can return false. Make sure that
this difference doesn't change the result of
Sema::CompareReferenceRelationship, which is expected to remain stable
while we're checking an initialization sequence.
llvm-svn: 178088
|
| |
|
|
|
|
|
|
|
|
| |
if execution failed. ExecuteAndWait returns -1 upon an execution failure, but
checking the return value isn't sufficient because the wait command may
return -1 as well. This new parameter is to be used by the clang driver in a
subsequent commit.
Part of rdar://13362359
llvm-svn: 178087
|
| |
|
|
|
|
| |
diagnostics for the first failing command.
llvm-svn: 178086
|
| |
|
|
|
|
| |
dependencies.
llvm-svn: 178085
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we compile a single source program, the `.gcda' file will be generated where
the program was executed. This isn't desirable, because that place may be at an
unpredictable place (the program could call `chdir' for instance).
Instead, we will output the `.gcda' file in the same place we output the `.gcno'
file. I.e., the directory where the executable was generated. This matches GCC's
behavior.
<rdar://problem/13061072> & PR11809
llvm-svn: 178084
|
| |
|
|
| |
llvm-svn: 178083
|
| |
|
|
| |
llvm-svn: 178082
|
| |
|
|
|
|
| |
return types.
llvm-svn: 178081
|
| |
|
|
|
|
|
|
|
|
|
|
| |
All Intel CPUs since Yonah look a lot alike, at least at the granularity
of the scheduling models. We can add more accurate models for
processors that aren't Sandy Bridge if required. Haswell will probably
need its own.
The Atom processor and anything based on NetBurst is completely
different. So are the non-Intel chips.
llvm-svn: 178080
|
| |
|
|
|
|
| |
metadata fields
llvm-svn: 178079
|
| |
|
|
|
|
|
|
| |
This will be used to factor out some uses of magic number operand offsets
inside Clang where these fields were updated in an effort to resolve forward
declarations/circular references.
llvm-svn: 178078
|
| |
|
|
|
|
|
|
|
|
| |
As suggested by Bill Schmidt (in reviewing r178067), use the real register
number bit lengths (which is self-documenting, and prevents using illegal
numbers), and set only the relevant bits in HWEncoding (which defaults to 0).
No functionality change intended.
llvm-svn: 178077
|
| |
|
|
|
|
|
| |
The algorithm to access an item in a __NSArrayM was not reacting properly to deletions
The fix is to use a smarter formula that accounts for items shifting and the resulting notion of offsets in the table
llvm-svn: 178076
|
| |
|
|
|
|
| |
is especially important for the constructors so that is_constructible<vector<T>, I, I> gives the right answer when T can not be constructed from *I. Test case included for this latter point.
llvm-svn: 178075
|
| |
|
|
|
|
| |
Allow variants to be defined only for some processors on a target.
llvm-svn: 178074
|
| |
|
|
|
|
|
|
|
|
|
| |
As pointed out by Richard Sandiford, my recent updates to the register
scavenger broke targets that use custom spilling (because the new code assumed
that if there were no valid spill slots, than spilling would be impossible).
I don't have a test case, but it should be possible to create one for Thumb 1,
Mips 16, etc.
llvm-svn: 178073
|
| |
|
|
|
|
| |
Make format uint64_t[] actually work as designed
llvm-svn: 178072
|
| |
|
|
| |
llvm-svn: 178071
|
| |
|
|
| |
llvm-svn: 178070
|
| |
|
|
| |
llvm-svn: 178069
|
| |
|
|
|
|
| |
object” logging is on.
llvm-svn: 178068
|
| |
|
|
|
|
|
|
|
|
|
| |
As pointed out by Jakob, we don't need to maintain a separate
register-numbering table. Instead we should let TableGen generate the table for
us from the information (already present) in PPCRegisterInfo.td.
TRI->getEncodingValue is now used to access register-encoding values.
No functionality change intended.
llvm-svn: 178067
|
| |
|
|
|
|
| |
[-Wunused-private-field]
llvm-svn: 178065
|
| |
|
|
|
|
| |
This partially addresses http://llvm.org/bugs/show_bug.cgi?id=15576.
llvm-svn: 178064
|
| |
|
|
|
|
|
|
| |
ObjC methods as top level.
This allows us to better reason about(inline) small wrapper functions.
llvm-svn: 178063
|
| |
|
|
| |
llvm-svn: 178062
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
for now.
With dosish filename, it misgenerates an improper extra entry.
!1 = metadata !{metadata !"E:\5Cllvm\5Cllvm-project\5Cclang\5Ctest\5CCodeGenCXX/debug-info-namespace.cpp", metadata !"E:\5Cllvm\5Cbuild\5Cninja-win32-vs11\5Ctools\5Cclang\5Ctest\5CCodeGenCXX"}
!8 = metadata !{metadata !"E:\5Cllvm\5Cllvm-project\5Cclang\5Ctest\5CCodeGenCXX\5Cdebug-info-namespace.cpp", metadata !"E:\5Cllvm\5Cbuild\5Cninja-win32-vs11\5Ctools\5Cclang\5Ctest\5CCodeGenCXX"}
!8 is unexpected.
llvm-svn: 178061
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that the register scavenger can support multiple spill slots, and PEI can
use virtual-register-based scavenging for multiple simultaneous registers, we
can use a virtual register for the transfer register in the CR spilling code.
This should eliminate the last place (outside of the prologue/epilogue) where
we depend on the unconditional availability of the r0 register. We will soon be
able to allocate it (in a somewhat restricted sense) as a GPR.
llvm-svn: 178060
|
| |
|
|
|
|
|
|
|
|
|
| |
PPC's use of PEI's virtual-register-based scavenging functionality had
redefined the virtual registers (it was non-SSA). Now that PEI supports
dealing with instructions with multiple virtual registers, this can be
cleanup up to use multiple virtual registers and keep SSA form.
No functionality change intended.
llvm-svn: 178059
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
simultaneous mappings
The previous algorithm could not deal properly with scavenging multiple virtual
registers because it kept only one live virtual -> physical mapping (and
iterated through operands in order). Now we don't maintain a current mapping,
but rather use replaceRegWith to completely remove the virtual register as
soon as the mapping is established.
In order to allow the register scavenger to return a physical register killed
by an instruction for definition by that same instruction, we now call
RS->forward(I) prior to eliminating virtual registers defined in I. This
requires a minor update to forward to ignore virtual registers.
These new features will be tested in forthcoming commits.
llvm-svn: 178058
|
| |
|
|
|
|
|
|
|
|
| |
- Making an error message more consistent
- Ensuring the element size is not zero before using it in a modulus
- Properly using target settings to cap the std::list element count
- Removing spurious element size calculations that were unused
- Removing spurious capping in std::map
llvm-svn: 178057
|
| |
|
|
| |
llvm-svn: 178056
|
| |
|
|
|
|
| |
It is unused since pic support went away.
llvm-svn: 178055
|