Summary:
See comments in patch; we were assuming that some stdlib math functions
would be defined in namespace std, when in fact the spec says they
should be defined in the global namespace. libstdc++4.9 became more
conforming and broke us.
This new implementation seems to cover the known knowns.
Reviewers: rsmith
Subscribers: cfe-commits, tra
Differential Revision: http://reviews.llvm.org/D18882
llvm-svn: 265751
Now, recordRegBankForType records only the first register bank that
covers a type instead of the last. This behavior can, nevertheless, be
override with the additional Force parameter to force the update.
llvm-svn: 265741
TUs in each unit refer to the unit they are in, if the unit is moved
this reference is invalidated & things break.
No test case because UB isn't testable - ASan would likely catch this on
a large enough test case (just needs to have enough TUs that a
reallocation of the vector would occur) but didn't seem worthwhile. Up
for debate/revisiting if anyone feels strongly.
llvm-svn: 265740
The Python import works by ensuring the directory of the module or package is in sys.path, and then it does a Python `import foo`. The original code was not escaping the backslashes in the directory path, so this wasn't working.
Differential Revision: http://reviews.llvm.org/D18873
llvm-svn: 265738
Previously, we supported only one hash function, FNV-1, so
BuildIdSection directly handled hash computation. In this patch,
I made BuildIdSection an abstract class and defined two subclasses,
BuildIdFnv1 and BuildIdMd5.
llvm-svn: 265737
specific type.
This will be used to find the default mapping of the instruction.
Also, this information is recorded, instead of computed, because it is
expensive from a type to know which register bank maps it.
Indeed, we need to iterate through all the register classes of all the
register banks to find the one that maps the given type.
llvm-svn: 265736
os to "ios" or "macosx" if it is unspecified. For environments
where there genuinely is no os, we don't want to errantly
convert that to ios/macosx, e.g. bare board debugging.
Change PlatformRemoteiOS, PlatformRemoteAppleWatch, and
PlatformRemoteAppleTV to not create themselves if we have
an unspecified OS. Same problem - these are not appropriate
platforms for bare board debugging environments.
Have Process::Attach's logging take place if either
process or target logging is enabled.
<rdar://problem/25592378>
llvm-svn: 265732
iterate over register class bitmask.
Thanks to this helper class, it would not require for each user of the
register classes bitmask to actually know how they are represents.
Moreover, it will make the code much easier to read.
llvm-svn: 265730
CodeGen-level implementation. Instead of adding an attribute to clang's
FunctionDecl, add the IR attribute directly. This means a module built with
this flag is now compatible with code built without it and vice versa.
This change also results in the 'noalias' attribute no longer being added to
calls to operator new in the IR; it's now only added to the declaration. It
also fixes a bug where we failed to add the attribute to the 'nothrow' versions
(because we didn't implicitly declare them, there was no good time to inject a
fake attribute).
llvm-svn: 265728
from a register.
On top of duplicating the logic, it was buggy! It would assert on
physical registers, since MachineRegisterInfo does not have any
information regarding register classes/banks for them.
llvm-svn: 265727
Summary:
EHPad BB are not entered the classic way and therefor do not need to be placed after their predecessors. This patch make sure EHPad BB are not chosen amongst successors to form chains, and are selected as last resort when selecting the best candidate.
EHPad are scheduled in reverse probability order in order to have them flow into each others naturally.
Reviewers: chandlerc, majnemer, rafael, MatzeB, escha, silvas
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17625
llvm-svn: 265726
glibc can use one of 2 layouts for semaphores: architectures that
don't HAVE_64B_ATOMIC use an uint32_t field with semaphore value,
then a private field, then a waiting thread count field - this is
the layout currently assumed by the test. However, HAVE_64B_ATOMIC
arches use a fused uint64_t field that contains the value in low bits
and waiting thread count in high bits, followed by a private field.
This resulted in taking private field from the wrong offset on 64-bit
atomic platforms (the test still passed, but didn't actually test
the private field). On big-endian platforms, this resulted in a fail,
since the first 4 bytes overlay the thread count field, and not
the value field.
Found while porting ASan to s390x.
Patch by Marcin Kościelnicki.
llvm-svn: 265715
Instead of searching the global pool multiple times: in
LookupFactoryMethodInGlobalPool, LookupInstanceMethodInGlobalPool,
CollectMultipleMethodsInGlobalPool, and AreMultipleMethodsInGlobalPool,
we now collect the method candidates in CollectMultipleMethodsInGlobalPool
only, and other functions will use the collected method set.
This commit adds parameter "Methods" to AreMultipleMethodsInGlobalPool,
and SelectBestMethod. It also changes the implementation of
CollectMultipleMethodsInGlobalPool to collect the desired kind first, if none is
found, to collect the other kind. This avoids the need to call both
LookupFactoryMethodInGlobalPool and LookupInstanceMethodInGlobalPool.
llvm-svn: 265711
start-lib and end-lib are options to link object files in the same
semantics as archive files. If an object is in start-lib and end-lib,
the object is linked only when the file is needed to resolve
undefined symbols. That means, if an object is in start-lib and end-lib,
it behaves as if it were in an archive file.
In this patch, I introduced a new notion, LazyObjectFile. That is
analogous to Archive file type, but that works for a single object
file instead of for an archive file.
http://reviews.llvm.org/D18814
llvm-svn: 265710
Standard load/store instructions with GLC bit set.
Reviewers: tstellardAMD, arsenm
Differential Revision: http://reviews.llvm.org/D18760
llvm-svn: 265709
Rui Ueyama