| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
get the wrong answer. Wasn't caught by my implementation sadly...
llvm-svn: 171222
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 170890
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
rdar://12282267
llvm-svn: 170611
|
| |
|
|
|
|
| |
Patch by Martin Nowack.
llvm-svn: 170147
|
| |
|
|
|
|
| |
Patch by Andrew Turner.
llvm-svn: 170096
|
| |
|
|
|
|
|
|
| |
i386-redhat-linux6E).
Thanks to Bruce Stephens.
llvm-svn: 169610
|
| |
|
|
|
|
| |
and will break the build on buildbot.
llvm-svn: 169562
|
| |
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
|
| |
linker directly
Rather than calling gcc.
llvm-svn: 169512
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
*last*, or llvm/Config/llvm-config.h could not be read in header files.
llvm-svn: 169268
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Unlike my previous attempt at this, this patch leaves intact the check for
whether clang can handle the input file type, and for non-Darwin toolchains it
will invoke gcc for things it cannot handle. For Darwin toolchains, the
behavior reported in pr14338 still occurs with this patch, but that is a
definite improvement from what happens currently, where it just crashes with
an assertion failure.
llvm-svn: 168505
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, this flag to CC1 was never exposed at the clang driver
layer, and if you happened to enable it (by being on Android or GCC 4.7
platform), you couldn't *disable* it, because there was no 'no' variant.
The whole thing was confusingly implemented.
Now, the target-specific flag processing gets the driver arg list, and
we use standard hasFlag with a default based on the GCC version and/or
Android platform. The user can still pass the 'no-' variant to forcibly
disable the flag, or pass the positive variant to clang itself to enable
the flag.
The test has also been substantially cleaned up and extended to cover
these use cases.
llvm-svn: 168473
|
| |
|
|
|
|
| |
they are not found in resource directory. Add test checking sanitizer linker flags on Darwin.
llvm-svn: 168428
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The dynamic linker of Android does not support .ctors/.dtors.
We should emit .init_array and .fini_array regardless the
gcc version.
NOTE: This patch does not affect the ARM backend, because
it is required to generate .init_array and .fini_array
for program targeting ARM AAPCS and AEABI.
llvm-svn: 168309
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
have been fixed in trunk GCC, and this fixes Clang as well. Notably,
the logic was always intended to be last-match-wins like any other
flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
It also allowed the use of this flag on non-Darwin platforms where it
has no actual meaning. Now this option is handled directly based on
tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
of dynamic-no-pic leaking through them. They also had the
implementation details of the LLVM relocation model flag names
leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
many cases. For example, Darwin *always* uses PIC level 2 if it uses
in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
the flags specified, including -fPIE. Darwin never compiles in PIE
mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
a supported mode at all and may have caused some fallout in builds
with complex PIC and PIE interactions.
The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.
Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.
llvm-svn: 168297
|
| |
|
|
|
|
| |
ubsan on OS X in 'make' build system. Patch by Jean-Daniel Dupas.
llvm-svn: 168168
|
| |
|
|
|
|
| |
can't handle the input file type. This resulted in PR14338.
llvm-svn: 168024
|
| |
|
|
|
|
|
| |
We can now rely on the -mios-simulator-version-min command line option
and remove the awful hack. <rdar://problem/10304510>
llvm-svn: 167603
|
| |
|
|
| |
llvm-svn: 167598
|
| |
|
|
| |
llvm-svn: 167567
|
| |
|
|
|
|
| |
More cleanups to follow in separate commits....
llvm-svn: 167566
|
| |
|
|
|
|
| |
header file and use it on Darwin toolchain.
llvm-svn: 167460
|
| |
|
|
| |
llvm-svn: 167211
|
| |
|
|
|
|
| |
I will remove it from llvm in the next commit.
llvm-svn: 167156
|
| |
|
|
|
|
|
|
| |
library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option.
The patch reviewed by Rafael Espindola.
llvm-svn: 166389
|
| |
|
|
| |
llvm-svn: 166348
|
| |
|
|
| |
llvm-svn: 166347
|
| |
|
|
|
|
| |
This seems to have introduced assertion hit when building compiler-rt.
llvm-svn: 166245
|
| |
|
|
| |
llvm-svn: 166230
|
| |
|
|
| |
llvm-svn: 166223
|
| |
|
|
| |
llvm-svn: 165988
|
| |
|
|
|
|
| |
See PR14013.
llvm-svn: 165962
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Author: Michael J. Spencer <bigcheesegs@gmail.com>
Date: Wed Oct 10 21:48:26 2012 +0000
[Options] make Option a value type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165663 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 0464fd5e4ce2193e786e5adcab6b828f9366dae3.
llvm-svn: 165667
|
| |
|
|
| |
llvm-svn: 165663
|
| |
|
|
|
|
|
|
|
| |
With this patch Bitrig can use a different c++ library without pain and
within the normal commandline parameters.
Original patch by David Hill, with lots of fixes and cleanup by me.
llvm-svn: 165430
|
| |
|
|
| |
llvm-svn: 165370
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The darwin change should be a nop since Triple::getArchTypeForDarwinArchName
doesn't know about amd64.
If things like amd64-mingw32 are to be rejected, we should print a error
earlier on instead of silently using the wrong abi.
Remove old comment that looks out of place, this is "in clang".
llvm-svn: 165368
|
| |
|
|
|
|
|
|
|
|
| |
1. Add mipsel-linux-android to the list of valid MIPS target triples.
2. Add <gcc install path>/mips-r2 to the list of toolchain specific path
prefixes if target is mipsel-linux-android.
The patch reviewed by Logan Chien.
llvm-svn: 165131
|
| |
|
|
| |
llvm-svn: 164907
|
| |
|
|
| |
llvm-svn: 164905
|
| |
|
|
| |
llvm-svn: 164473
|
| |
|
|
| |
llvm-svn: 164470
|
| |
|
|
|
|
| |
using getArch, but I will try to fix them one at time to add tests.
llvm-svn: 164460
|
| |
|
|
|
|
|
|
|
| |
The Freescale SDK is based on OpenEmbedded, and this might be useful
for other OpenEmbedded-based configurations as well.
With minor modifications, patch by Tobias von Koch!
llvm-svn: 164177
|