Truncation happens regularly when find_first_not_of returns npos,
strings long enough to trigger bug here are implausible.
No functionality change intended (ignoring absurd string lengths).
llvm-svn: 172127
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
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
According to Android ABI, we have to link with
libdl.so, if we are linking with non-static libgcc.
Besides, this also fixes MIPS link error of
undefined references to `_Unwind_Find_FDE' and
`dl_iterate_phdr'.
llvm-svn: 168310
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
This was causing different behavior when using -x objective-c++-cpp-output as
compared to -x objc++-cpp-output. Specifically, the driver was not adding the
-fcxx-exceptions flag in the latter case.
rdar://12680312
llvm-svn: 168212
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
llvm-svn: 168063
- Separately check if -fPIE was specified in the command line and define both __PIC__ and __PIE__ when -fPIE is used. We need to check this separately because -fPIE will infer -fPIC even if its not explicitly used.
- Fixed existing tests.
- Added new tests for cases where both -fPIC and -fPIE is used.
Author: Tareq A. Siraj <tareq.a.siraj@intel.com>
Fixes: PR13221
Review: http://llvm-reviews.chandlerc.com/D94
llvm-svn: 167846
LTO doesn't generate correct accelerator tables. This is due to the general lack
correct of debug info for LTO. Disable it when using LTO.
<rdar://problem/12401423>
llvm-svn: 167799
-fno-address-sanitizer, -fthread-sanitizer, -fno-thread-sanitizer, and
-fcatch-undefined-behavior as deprecated: produce a warning if they are used
pointing to the corresponding -fsanitize= option. In passing add the missing
'-' to some diagnostics.
llvm-svn: 167429
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
llvm-svn: 167413
-fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the
various UBSan checks to be enabled and disabled separately. Right now, the
different modes can't be combined, but the intention is that combining UBSan
and the other sanitizers will be permitted in the near future.
Currently, the UBSan checks will all be enabled if any of them is; that will be
fixed by the next patch.
llvm-svn: 167411
diagnostics script.
This addresses the FIXME pertaining to quoted arguments. We also delineate
between those flags that have an argument (e.g., -D macro, -MF file) and
those that do not (e.g., -M, -MM, -MG). Finally, we add the -dwarf-debug-flags
to the list of flags to be removed.
rdar://12329974
llvm-svn: 167152
is not a directory, Driver::GetProgramPath() routine does not try to append
the program name as a "path component" to it. It just joins the "prefix" with
the program name and checks the resulting path existence.
The patch reviewed by Rafael Espindola.
llvm-svn: 167114
later, '-L <dir>' is allowed, but rewrite these in the driver as '-L<dir>' to
maintain backward compatibility. The same is true for the -I option.
rdar://12366753
llvm-svn: 167054
we had the -ccc-clang-cxx and -ccc-no-clang-cxx options to force them
on or off for testing.
Clang c++ support is now production quality and these options are dead.
llvm-svn: 166986
Each option has a set of prefixes. When matching an argument such as
-funroll-loops. First the leading - is removed as it is a prefix. Then
a lower_bound search for "funroll-loops" is done against the option table by
option name. From there each option prefix + option name combination is tested
against the argument.
This allows us to support Microsoft style options where both / and - are valid
prefixes. It also simplifies the cases we already have where options come in
both - and -- forms. Almost every option for gnu-ld happens to have this form.
llvm-svn: 166444
- This is an assumption that is currently hardwired into the backend, we need
to do this in order for the frontend and backend to agree.
llvm-svn: 166428
are no known current users of column info. Robustify and fix up
a few tests in the process. Reduces the size of debug information
by a small amount.
Part of PR14106
llvm-svn: 166236
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
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
llvm-svn: 165545
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
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
crtfastmath.o contains routines to set the floating point flags to a faster,
unsafe mode. Linking it in speeds up code dealing with denormals significantly
(PR14024).
For now this is only enabled on linux where I can test it and crtfastmath.o is
widely available. We may want to provide a similar file with compiler-rt
eventually and/or enable it on other platforms too.
llvm-svn: 165240
This parameter is useless because nowhere used explicitly and always
gets its default value - "false".
The patch reviewed by Rafael Espindola.
llvm-svn: 165149
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
clang specifying a temporary file that it later cleans up so that it can survive
the linking stage. However, when we compile object files during LTO we don't
call 'dsymutil'. That's done at a different stage (if at all). We rely upon the
linker to specify a unique name for the temporary file it generates.
<rdar://problem/12401423>
llvm-svn: 165028
Will Dietz