| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 168436
|
|
|
|
|
|
| |
they are not found in resource directory. Add test checking sanitizer linker flags on Darwin.
llvm-svn: 168428
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
it was intended to fix.
llvm-svn: 168217
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
ubsan on OS X in 'make' build system. Patch by Jean-Daniel Dupas.
llvm-svn: 168168
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 168041
|
|
|
|
|
|
| |
can't handle the input file type. This resulted in PR14338.
llvm-svn: 168024
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
4.6 in cases where both -fPIC and -fPIE is used.
- 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
|
|
|
|
|
|
|
| |
the driver (the options defined in CC1Options.td) and exclude their help from
"clang --help".
llvm-svn: 167638
|
|
|
|
|
|
| |
us from having to make any backend changes.
llvm-svn: 167623
|
|
|
|
|
|
| |
rdar://12340498
llvm-svn: 167619
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
triple.
- Translate the special case of powerpc to its expected -arch name.
llvm-svn: 167571
|
|
|
|
| |
llvm-svn: 167567
|
|
|
|
|
|
| |
More cleanups to follow in separate commits....
llvm-svn: 167566
|
|
|
|
| |
llvm-svn: 167559
|
|
|
|
| |
llvm-svn: 167494
|
|
|
|
|
|
| |
header file and use it on Darwin toolchain.
llvm-svn: 167460
|
|
|
|
|
|
|
|
|
| |
-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
|
|
|
|
|
|
|
|
| |
* -Bsymbolic must be added for x86 as well.
* Default CPU name also set to 'core2' for x86 android.
Patch by Edwin Vane.
llvm-svn: 167307
|
|
|
|
|
|
| |
libclang-rt.ubsan pull in sanitizer_common, which in turn depends on pthreads.
llvm-svn: 167305
|
|
|
|
| |
llvm-svn: 167211
|
|
|
|
|
|
|
| |
matching works correctly.
Part of rdar://12329974
llvm-svn: 167173
|
|
|
|
|
|
|
| |
that matching works correctly.
Part of rdar://12329974
llvm-svn: 167161
|
|
|
|
|
|
| |
I will remove it from llvm in the next commit.
llvm-svn: 167156
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 167118
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 167093
|
|
|
|
| |
llvm-svn: 167062
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 166983
|
|
|
|
| |
llvm-svn: 166871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Feature:
OpenMP support in CLANG:
Sub-Feature:
Support for option -fopenmp
Files Changed/Added:
* include/clang/Driver/Options.td (C)
* include/clang/Basic/LangOptions.def (C)
* lib/Driver/Tools.cpp (C)
* lib/Frontend/CompilerInvocation.cpp (C)
Test Cases Changed/Added:
* test/Driver/clang_fopenmp_opt.c (A)
-------------------------------------------------
llvm-svn: 166868
|
|
|
|
|
|
| |
is absolute.
llvm-svn: 166808
|
|
|
|
| |
llvm-svn: 166801
|
|
|
|
|
|
| |
CodeGen side.
llvm-svn: 166661
|
|
|
|
|
|
| |
Patch by David Hill.
llvm-svn: 166483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|