If a function seen at compile time is not necessarily the one linked to
the binary being built, it is illegal to change the actual arguments
passing to it.
e.g.
--------------------------
void foo(int lol) {
// foo() has linkage satisifying isWeakForLinker()
// "lol" is not used at all.
}
void bar(int lo2) {
// xform to foo(undef) is illegal, as compiler dose not know which
// instance of foo() will be linked to the the binary being built.
foo(lol2);
}
-----------------------------
Such functions can be captured by isWeakForLinker(). NOTE that
mayBeOverridden() is insufficient for this purpose as it dosen't include
linkage types like AvailableExternallyLinkage and LinkOnceODRLinkage.
Take link_odr* as an example, it indicates a set of *EQUIVALENT* globals
that can be merged at link-time. However, the semantic of
*EQUIVALENT*-functions includes parameters. Changing parameters breaks
the assumption.
Thank John McCall for help, especially for the explanation of subtle
difference between linkage types.
rdar://11546243
llvm-svn: 192302
- By default, the above function will wait for at least one event
- Set wait_always=false to make the function return immediately if the process is already stopped
llvm-svn: 192301
With this patch we produce alias for cases like
template<typename T>
struct foobar {
foobar() {
}
};
template struct foobar<void>;
It is safe to use aliases to weak symbols, as long and the alias itself is also
weak.
llvm-svn: 192300
Before, clang-format would always insert a linebreak before the comment
in code like:
template <typename T> // T can be A, B or C.
struct S {};
llvm-svn: 192297
Comparing the parent PID with 1 isn't sufficient to ensure the parent is alive,
because of prctl(PR_SET_CHILD_SUBREAPER, ...). Compare with the real parent's
recorded PID instead.
llvm-svn: 192295
Substantial SelectionDAG scheduling is going away soon, and is
interfering with Hao's attempts to implement LDn/STn instructions, so
I say we make the leap first.
There were a few reorderings (inevitably) which broke some tests. I
tried to replace them with CHECK-DAG variants mostly, but some too
complex for that to be useful and I just reordered them.
llvm-svn: 192282
This change removes code in various places which was setting the File Ordinals.
This is because the file ordinals are assigned by the way files are resolved.
There was no other way than making the getNextFileAndOrdinal be set const and
change the _nextOrdinal to mutable.
There are so many places in code, that you would need to cleanup to make
LinkingContext non-const!
llvm-svn: 192280
This was only working because AVX had cheaper rules in all cases.
I'm sure there are other places in this file where predicates are missing.
llvm-svn: 192276
This associates resolveState to FileNodes. The control node derive
their resolution state from the inputElements that are contained in
it.
This makes --start-group/--end-group to work with ELF linking.
llvm-svn: 192269
Use 32-bit register enums without gaps on 64-bit hosts.
Don't show 64-bit registers when debugging 32-bit targets.
Add psuedo gpr registers (ax, ah, al, etc.)
Add mmx registers.
Fix TestRegisters.py to not read ymm15 register on 32-bit targets.
Fill out and move gcc/dwarf/gdb register enums to RegisterContext_x86.h
llvm-svn: 192263
Constant ValueObjects should clear their description as well as their summary. Rationale being that both can depend on deeper-than-constified data
so both are subject to changes in "unpredictable" ways
To see this consider repeatedly po'ing a persistent variable of a type whose -description result changes at each invocation
llvm-svn: 192259
An invalid decltype expression like 'decltype int' gives:
error: expected '(' after 'decltype'
This makes it so 'sizeof int' gives a similar one:
error: expected parentheses around type name in sizeof expression
llvm-svn: 192258
Now hiding options clang-modernize doesn't use and didn't create. Version
printer specialized for clang-modernize. EXAMPLES text fixed and brought
up-to-date.
Differential Revision: http://llvm-reviews.chandlerc.com/D1849
llvm-svn: 192253
Benjamin Kramer