to read and tell that it is a SWO -- we now descend through the
components and return a result at the first inequal component.
Also comment it a bit better and make it a total ordering by sorting on
the text of the suffix if necessary.
None of this should really be a visible change.
llvm-svn: 171219
Without this patch comparing two equal versions without patch numbers (4.7 for
example) will result in A < B and B < A.
Patch by Simon Atanasyan.
llvm-svn: 170705
produce a note for that diagnostic either with a different DiagnosticEngine or
after calling DiagnosticEngine::Reset(). That didn't make any sense, and did the
wrong thing if the original diagnostic was suppressed.
llvm-svn: 170636
This also requires adding support to -cc1as for passing the detecting
PWD down through LLVM's debug info (which in turn required the LLVM
change in r170371).
The test case is weak (we only test the driver behavior) because there
is currently to infrastructure for running cc1as in the test suite. So
those four lines are untested (much like all other lines in that file),
but we have a test for the same pattern using llvm-mc in the LLVM
repository.
llvm-svn: 170373
Add -fslp-vectorize (with -ftree-slp-vectorize as an alias for gcc compatibility)
to provide a way to enable the basic-block vectorization pass. This uses the same
acronym as gcc, superword-level parallelism (SLP), also common in the literature,
to refer to basic-block vectorization.
Nadav suggested this as a follow-up to the adding of -fvectorize.
llvm-svn: 169909
* Look for i686-linux-android under <sysroot>/lib/gcc.
* This patch also slightly enhance the test suite for
Android GCC toolchain detection.
llvm-svn: 169557
ToolChains.cpp
This is in anticipation of forthcoming library path changes.
Also ...
- Fixes some inconsistencies in how the arch is passed to tools.
- Add test cases for various forms of arch flags
llvm-svn: 169505
paths
- Inherit from Linux rather than ToolChain
- Override AddClangSystemIncludeArgs and AddClangCXXStdlibIncludeArgs
to properly set include paths.
llvm-svn: 169495
This ensures that even though it comes first, we pick up its .o files.
Note that if we can use this (or something similar / equivalent) on
other platforms, we could potentially remove
ReplaceOperatorsNewAndDelete from the ASan runtimes.
We should probably do something similar for TSan and MSan as well.
llvm-svn: 169328
the link command. This all works fine when the driver is also responsible for
adding -lstdc++ to the link command. But, if -lstdc++ (or libstdc++.a, etc) is
passed explicitly to the driver, the ASan runtime will appear in the link
command after the standard library, leading to multiple-definition errors for
the global 'operator new' and 'operator delete'. Fix this in a painfully
simple way, by inserting libclang_rt.asan.a at the start of the link command
instead of the end.
If we need to do something more clever, we can walk the link command looking
for something that resembles libstdc++ and insert libclang_rt.asan.a as late
as possible, but the simple solution works for now.
llvm-svn: 169310
Shuffling order causes the wrong one to win.
CMake didn't exhibit this problem because Clang's has *no* guards.
I'll fix this properly tomorrow when Eric and I can check both build
systems and get them to DTRT, but for now unbreak some bots by hoisting
this header.
llvm-svn: 169260
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
1) init-order sanitizer: initialization-order checker.
Status: usable, but may produce false positives w/o proper blacklisting.
2) use-after-return sanitizer
Status: implemented, but heavily understed.
Should be optional, as it significanlty slows program down.
3) use-after-scope sanitizer
Status: in progress.
llvm-svn: 168950
