| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
distinguish them.
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16856
llvm-svn: 260231
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
distinguish them.
Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.
For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.
Reviewers: samsonov
Subscribers: tberghammer, danalbert, srhines, llvm-commits
Differential Revision: http://reviews.llvm.org/D16855
llvm-svn: 260230
|
| |
|
|
|
|
| |
of r260227.
llvm-svn: 260229
|
| |
|
|
| |
llvm-svn: 260228
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes duplicate test names in the test results, so:
PASS: SanitizerCommon-asan :: fopen_nullptr.c (304 of 431)
PASS: SanitizerCommon-asan :: fopen_nullptr.c (305 of 431)
is now:
PASS: SanitizerCommon-asan-i386-Linux :: fopen_nullptr.c (282 of 431)
PASS: SanitizerCommon-asan-x86_64-Linux :: fopen_nullptr.c (316 of 431)
Reviewers: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16850
llvm-svn: 260227
|
| |
|
|
| |
llvm-svn: 260226
|
| |
|
|
|
|
| |
work on various bots
llvm-svn: 260225
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the function equivalent of a copy relocation.
Since functions are expected to change sizes, we cannot use copy
relocations. In situations where one would be needed, what is done
instead is:
* Create a plt entry
* Output an undefined symbol whose addr is the plt entry.
The dynamic linker makes sure any shared library uses the plt entry as
the function address.
llvm-svn: 260224
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16310
llvm-svn: 260223
|
| |
|
|
|
|
| |
available from clang-query.
llvm-svn: 260222
|
| |
|
|
| |
llvm-svn: 260221
|
| |
|
|
| |
llvm-svn: 260220
|
| |
|
|
| |
llvm-svn: 260219
|
| |
|
|
| |
llvm-svn: 260218
|
| |
|
|
|
|
| |
namespaces. Fix PR25812.
llvm-svn: 260217
|
| |
|
|
| |
llvm-svn: 260216
|
| |
|
|
|
|
| |
directive.
llvm-svn: 260215
|
| |
|
|
| |
llvm-svn: 260214
|
| |
|
|
| |
llvm-svn: 260213
|
| |
|
|
| |
llvm-svn: 260212
|
| |
|
|
|
|
|
| |
Clang did not expanded macros in the very first token of the pragmas
during preprocessed output
llvm-svn: 260211
|
| |
|
|
|
|
|
|
|
|
| |
On AVX2 target we are poorly legalizing SIGN_EXTEND ops for which the input's legalized type doesn't have the same number of elements as the destination, resulting in an ANY_EXTEND followed by a SIGN_EXTEND_INREG.
This patch uses the existing SIGN_EXTEND -> SIGN_EXTEND_VECTOR_INREG combine to extend the input to the size of the result and using SIGN_EXTEND_VECTOR_INREG instead.
Differential Revision: http://reviews.llvm.org/D16994
llvm-svn: 260210
|
| |
|
|
| |
llvm-svn: 260209
|
| |
|
|
| |
llvm-svn: 260208
|
| |
|
|
| |
llvm-svn: 260207
|
| |
|
|
|
|
| |
lld/test/old-elf/X86_64/demangle.test as REQUIRES:demangler.
llvm-svn: 260206
|
| |
|
|
|
|
| |
insufficient.
llvm-svn: 260205
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(libgomp has bool as well)
This was causing a test failure in omp_test_if.c when building with GCC in
Debug mode. I have verified that GCC versions 4.9.2 and 5.3.0 now work and
compile-tested this change with clang 3.7.1 and Intel Compiler 16.0.
Differential Revision: http://reviews.llvm.org/D16921
llvm-svn: 260204
|
| |
|
|
|
|
| |
This is in response to silvas' post-commit suggestion.
llvm-svn: 260203
|
| |
|
|
| |
llvm-svn: 260202
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This cache file can be used to generate a 3-stage clang build. You can configure using the following CMake command:
cmake -C <path to clang>/cmake/caches/3-stage.cmake -G Ninja <path to llvm>
You can then run "ninja stage3-clang" to build stage1, stage2 and stage3 clangs.
This is useful for finding non-determinism the compiler by verifying that stage2 and stage3 are identical.
llvm-svn: 260201
|
| |
|
|
| |
llvm-svn: 260200
|
| |
|
|
|
|
|
|
|
|
|
|
| |
causes LLDB to crash
This is because PyThreadState_Get() assumes a non-NULL thread state and crashes otherwise; but PyThreadState_GET is just a shortcut (in non-Python-debugging builds) for the global variable that holds the thread state
The behavior of CTRL+C is slightly more erratic than one would like. CTRL+C in the middle of execution of Python code will cause that execution to be interrupted (e.g. time.sleep(1000)), but a CTRL+C at the prompt will just cause a KeyboardInterrupt and not exit the interpreter - worse, it will only trigger the exception once one presses ENTER.
None of this is optimal, of course, but I don't have a lot of time to appease the Python deities with the proper spells right now, and fixing the crasher is already a good thing in and of itself
llvm-svn: 260199
|
| |
|
|
| |
llvm-svn: 260198
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move the function renaming logic into the Function class, and the
MD5Hash routine into the MD5 header.
This will enable these routines to be shared with ThinLTO, which
will be changed to store the MD5 hash instead of full function name
in the combined index for significant size reductions. And using the same
function naming for locals in the function index facilitates future
integration with indirect call value profiles.
Reviewers: davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17006
llvm-svn: 260197
|
| |
|
|
|
|
| |
user-defined conversion to T. No functionality change intended.
llvm-svn: 260196
|
| |
|
|
|
|
| |
Change the no_sanitize attribute to use the reserved spelling.
llvm-svn: 260195
|
| |
|
|
|
|
| |
Fixes PR26490
llvm-svn: 260194
|
| |
|
|
|
|
|
|
|
| |
In general, memory restrictions on a called function (e.g. readnone)
cannot be transferred to a CallSite that has operand bundles. It is
possible to make this inference smarter, but lets fix the behavior to be
correct first.
llvm-svn: 260193
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17014
llvm-svn: 260192
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Also added the defaults for whether to generate this load command, which
the cmdline options are able to override.
There was also a difference to ld64 which is fixed here in that ld64 will
generate an empty data in code command if requested.
rdar://problem/24472630
llvm-svn: 260191
|
| |
|
|
|
|
|
|
|
| |
compiler-specific issues. Instead, repeat an 'operator delete' definition in
each derived class that is actually deleted, and give up on the static type
safety of an error when sized delete is accidentally used on a type derived
from TrailingObjects.
llvm-svn: 260190
|
| |
|
|
| |
llvm-svn: 260189
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This load command generates data in the LINKEDIT section which
is a list of ULEB128 delta's to all of the functions in the __text section.
It is then 0 terminated and pointer aligned to pad.
ld64 exposes the -function-starts and no-function-starts cmdline options
to override behaviour from the defaults based on file types.
rdar://problem/24472630
llvm-svn: 260188
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17005
llvm-svn: 260186
|
| |
|
|
|
|
|
|
| |
This was a bug in our handling of these symbols compared to ld64.
Turns out that ld64 always marks these symbols as being not dead stripped.
llvm-svn: 260185
|
| |
|
|
|
|
|
|
|
|
| |
The atom content type enum is used as a tie breaker to sort atoms.
In that case, we want MachHeader to be before typeCode as it really will
be before the code in the final executable.
Test case to follow in the next commit or two.
llvm-svn: 260184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Passes that call `getAnalysisIfAvailable<T>` also need to call
`addUsedIfAvailable<T>` in `getAnalysisUsage` to indicate to the
legacy pass manager that it uses `T`. This contract was being
violated by passes that used `createLegacyPMAAResults`. This change
fixes this by exposing a helper in AliasAnalysis.h,
`addUsedAAAnalyses`, that is complementary to createLegacyPMAAResults
and does the right thing when called from `getAnalysisUsage`.
Reviewers: chandlerc
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D17010
llvm-svn: 260183
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
createLegacyPMAAResults is only called by CGSCC and Module passes, so
the call to getAnalysisIfAvailable<SCEVAAWrapperPass>() never
succeeds (SCEVAAWrapperPass is a function pass).
Reviewers: chandlerc
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D17009
llvm-svn: 260182
|
| |
|
|
|
|
|
| |
being called with the wrong size: convert CGFunctionInfo to use TrailingObjects
and ask TrailingObjects to provide a working 'operator delete' for us.
llvm-svn: 260181
|