summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver
Commit message (Collapse)AuthorAgeFilesLines
* Clean up some Triple usage in clang.Cameron Esfahani2013-09-141-9/+8
| | | | llvm-svn: 190737
* Add support for -ggnu-pubnames matching the llvm support.Eric Christopher2013-09-131-0/+6
| | | | llvm-svn: 190729
* Moving Cortex-R cores to armv7r archRenato Golin2013-09-131-3/+1
| | | | llvm-svn: 190704
* Add more Cortex CPUs and testsRenato Golin2013-09-133-5/+9
| | | | llvm-svn: 190703
* [ARMv8] Change the naming of some options to be more consistent.Joey Gouly2013-09-131-2/+2
| | | | | | Clang side changes for LLVM r190692. llvm-svn: 190693
* Move the execution code from Compilation::ExecuteCommand to Command::ExecuteHans Wennborg2013-09-122-11/+15
| | | | | | | | | | | | | | I think it makes sense that a Command knows how to execute itself. There's no functionality change but i rewrote the code to avoid the manual memory management of Argv. My motivation for this is that I plan to subclass Command to build fall-back functionality into clang-cl. Differential Revision: http://llvm-reviews.chandlerc.com/D1654 llvm-svn: 190621
* Move Compilation::PrintJob and PrintDiagnosticJob into Job::Print.Hans Wennborg2013-09-123-137/+102
| | | | | | | | | | | | | | | | | This moves the code to Job.cpp, which seems like a more natural fit, and replaces the "is this a JobList? is this a Command?" logic with a virtual function call. It also removes the code duplication between PrintJob and PrintDiagnosticJob and simplifies the code a little. There's no functionality change here, except that the Executable is now always printed within quotes, whereas it would previously not be quoted in crash reports, which I think was a bug. Differential Revision: http://llvm-reviews.chandlerc.com/D1653 llvm-svn: 190620
* clang-cl: Warn about overriding /MD with /MT etc.Hans Wennborg2013-09-112-6/+14
| | | | | | | This also bakes the /M options into a separate option group to make them easier to refer to from the code. llvm-svn: 190529
* Fix the ASan dll_thunk pathTimur Iskhodzhanov2013-09-111-2/+1
| | | | llvm-svn: 190516
* Add -fansi-escape-codes optionNico Rieck2013-09-111-0/+3
| | | | | | | | | | | | | Some build systems use pipes for stdin/stderr. On nix-ish platforms colored output can be forced by -fcolor-diagnostics. On Windows this option has no effect in these cases because LLVM uses the console API (which only operates on the console buffer) even if a console wrapper capable of interpreting ANSI escape codes is used. The -fansi-escape-codes option allows switching from the console API to ANSI escape codes. It has no effect on other platforms. llvm-svn: 190464
* clang-cl: Support building DLLs (PR17083)Hans Wennborg2013-09-102-9/+42
| | | | | | | | This adds driver support for building DLLs (the /LD and /LDd flags). It basically does two things: runtime selection and passing -dll and -implib to the linker. llvm-svn: 190428
* clang-cl: use -fdiagnostics-format=msvc by defaultHans Wennborg2013-09-101-0/+5
| | | | | | | This allows for navigating to errors within the MSVC IDE by clicking on the diagnostics. llvm-svn: 190378
* Remove unused method Job::AddCommand.Hans Wennborg2013-09-061-5/+0
| | | | | | | | I was going to update the comment referring to PipedJob, which was removed some time ago, but then it turned out that this method is not actually used at all. llvm-svn: 190171
* clang-cl: Use .obj as extension for unnamed object files (PR17095)Hans Wennborg2013-09-051-1/+1
| | | | | | | | We already use .obj as extension when the user provides a stem file name (via /Fo), but were failing in the most basic case when the file name is based on the input file. llvm-svn: 190071
* Tweak implementation of -Wwrite-strings to better match the behavior of ↵Richard Smith2013-09-041-7/+18
| | | | | | | | | | | | | | | | current GCCs: * In C, as before, if the "warning flag" is enabled, warnings are produced by forcing string literals to have const-qualified types (the produced warnings are *not* -Wwrite-strings warnings). However, more recent GCCs (at least 4.4 onwards) now take -w into account here, so we now do the same. * In C++, this flag is entirely sane: it behaves just like any other warning flag. Stop triggering -fconst-strings here. This is a bit cleaner, but there's no real functionality change except in the case where -Xclang -fno-const-strings is also specified. llvm-svn: 190006
* Remove the -fuse-gold-plugin driver option.Rafael Espindola2013-09-041-5/+2
| | | | | | | | * It was redundant with -flto. * It was confusing since -uAnythingElse is a different option. * GCC uses -fuse-linker-plugin, so it was not even a compatibility option. llvm-svn: 189976
* Use -### instead of -ccc-print-options.Rafael Espindola2013-09-031-26/+2
| | | | | | | Convert the last few tests using -ccc-print-options to -### and remove -ccc-print-options. llvm-svn: 189802
* clang-cl: Pass -incremental:no to linker when using ASanHans Wennborg2013-08-301-0/+1
| | | | llvm-svn: 189664
* Revert r188531: "Windows ToolChain: add VS bin dir to PogramPaths"Hans Wennborg2013-08-301-42/+37
| | | | | | | | | | | | | | | | | | | | | This never really worked. Even if we find and execute link.exe in the VS bin dir this way, link.exe wouldn't find the DLLs it needs, libraries, etc. It also causes trouble when the user has multiple versions of VS installed, one of them is in the path, but this code finds the other one (PR17041). Revert until we can fix this properly. > Windows ToolChain: add VS bin dir to PogramPaths > > We have a lot of fancy logic to find Visual Studio, which is currently used > to set the system header include paths. > > Use the same code to set the ProgramPaths, which is used for finding programs > such as link.exe. Previously, Clang would just search PATH for link.exe, > but now it should find it if it's able to find Visual Studio. llvm-svn: 189661
* use the last passed -munaligned-access / -mno-unaligned-accessRenato Golin2013-08-281-6/+9
| | | | | | | | | | | | | | | Passing inconsistent munaligned-access / mno-unaligned-access flags, intentionally resulted in a warning and the flag no-unaligned-access being used. Gcc does, at least in practice, use the last flag in such a case. This patch updates clang behaviour accordingly; use the last flag or base alignment behaviour on the target (which llvm will do if no flag is explicitly passed) Patch by Jeroen Hofstee. llvm-svn: 189542
* Look for libstdc++ first on the clang install directory.Rafael Espindola2013-08-281-2/+11
| | | | | | | | | | When sysroot is not set, look for libstdc++ first on the clang install directory. Before this change if clang was installed alongside a gcc with the same version as the system one we would select the system libstdc++. Unfortunately this is hard to test as only the non-sysroot case is changed. llvm-svn: 189536
* clang-cl: Pass -debug to the linker when using -fsanitize=addressHans Wennborg2013-08-281-0/+1
| | | | llvm-svn: 189496
* Revert r189440 - Disable loop vectorizer unrolling when no unrolling requestedHal Finkel2013-08-281-11/+1
| | | | | | | | | | | | | | | | | | | | | As Chandler pointed out, we should not be using -backend-option because this will cause crashes for users of the tooling interface, etc. A better way to fix this will be to provide the unrolling pass-manager flag to the loop vectorizer directly. Original commit message: Disable loop vectorizer unrolling when no unrolling requested In addition to the regular loop unrolling transformation, the loop vectorizer can also unroll loops. If no unrolling has specifically been requested (by -fno-unroll-loops), and the loop vectorizer will be used, then add the backend option to (also) prevent the loop vectorizer from unrolling loops. I confirmed with Nadav (off list) that disabling vectorizer loop unrolling when -fno-unroll-loops is provided is the desired behavior. llvm-svn: 189441
* Disable loop vectorizer unrolling when no unrolling requestedHal Finkel2013-08-281-1/+11
| | | | | | | | | | | | In addition to the regular loop unrolling transformation, the loop vectorizer can also unroll loops. If no unrolling has specifically been requested (by -fno-unroll-loops), and the loop vectorizer will be used, then add the backend option to (also) prevent the loop vectorizer from unrolling loops. I confirmed with Nadav (off list) that disabling vectorizer loop unrolling when -fno-unroll-loops is provided is the desired behavior. llvm-svn: 189440
* clang-cl: Support -fsanitize=addressHans Wennborg2013-08-271-0/+8
| | | | | | | | | This exposes the -fsanitize=address option and adds the runtime library to the link command. Differential Revision: http://llvm-reviews.chandlerc.com/D1526 llvm-svn: 189389
* Warn that -O4 is the same as -O3.Rafael Espindola2013-08-271-3/+11
| | | | | | | We error on -O5 and higher. While it is tempting to do the same for -O4, I agree with Jordan Rose: we should warn for a release at least first. llvm-svn: 189369
* Simplify now that -O4 just maps to -O3 and -O is an alias of -O2.Rafael Espindola2013-08-261-11/+5
| | | | llvm-svn: 189218
* Teach the Linux toolchain about more modern Gentoo installations of GCCChandler Carruth2013-08-262-8/+15
| | | | | | | | which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
* Produce an error when trying to link with -emit-llvm.Rafael Espindola2013-08-251-0/+4
| | | | llvm-svn: 189193
* Add gcc ARM flags -munaligned-access / -mno-unaligned-accessRenato Golin2013-08-241-3/+8
| | | | | | | | | | | | | | | | clang already had a mstrict-align which mentiones "Force all memory accesses to be aligned (ARM only)". On gcc arm this is controlled by -munaligned-access / -mno-unaligned-access. Add the gcc versions to the frontend and make -mstrict-align and alias to -mno-unaligned-access and only show it in clang -cc1 -help. Since the default value for unaligned accesses / strict alignment depends on the tripple, both the enable and disable flags are added. If both are set, the no-unaligned-access is used. Patch by Jeroen Hofstee. llvm-svn: 189175
* Add the -ffixed-r9 flag for ARM.Renato Golin2013-08-241-0/+8
| | | | | | | | | | | | This patch adds the -ffixed-r9 flag to clang to instruct llvm to globally preserve the contents of r9. The flag is added to the newly created ARM specific group. While at it, also place marm / mno-thumb in that group. Patch by Jeroen Hofstee. llvm-svn: 189174
* Don't imply -flto with -O4.Rafael Espindola2013-08-231-4/+0
| | | | | | We now saturate at -O3. llvm-svn: 189149
* Driver::IsUsingLTO() no longer return true when seeing -emit-llvm.Shuxin Yang2013-08-231-3/+5
| | | | | | | | | | One step toward differentiating following two commands: clang -O3 -flto a.c -c, and clang -O3 -emit-llvm a.c Thanks many awesome folks for clarifying things. llvm-svn: 189148
* Move -mfpmath handling to -cc1 and implement it for x86.Rafael Espindola2013-08-211-28/+5
| | | | | | | | | | | | | | | | | | | | | | | The original idea was to implement it all on the driver, but to do that the driver needs to know the sse level and to do that it has to know the default features of a cpu. Benjamin Kramer pointed out that if one day we decide to implement support for ' __attribute__ ((__target__ ("arch=core2")))', then the frontend needs to keep its knowledge of default features of a cpu. To avoid duplicating which part of clang handles default cpu features, it is probably better to handle -mfpmath in the frontend. For ARM this patch is just a small improvement. Instead of a cpu list, we check if neon is enabled, which allows us to reject things like -mcpu=cortex-a9 -mfpu=vfp -mfpmath=neon For X86, since LLVM doesn't support an independent ssefp feature, we just make sure the selected -mfpmath matches the sse level. llvm-svn: 188939
* Move the logic for selecting the last feature in the command line to the driver.Rafael Espindola2013-08-211-4/+19
| | | | | | | This is a partial revert of r188817 now that the driver handles -target-feature in a single place. llvm-svn: 188910
* Centralize the handling of -target-feature.Rafael Espindola2013-08-212-186/+178
| | | | | | | No functionality change other than changing the order of -target-feature relative to other -cc1 command line arguments. llvm-svn: 188906
* Centralize the handling of -target-cpu (-cc1, -cc1as) and -mcpu (gold plugin).Rafael Espindola2013-08-202-105/+87
| | | | llvm-svn: 188837
* Centralize the logic for handling -m* options and fix pr16943.Rafael Espindola2013-08-201-19/+2
| | | | | | | | | This moves the logic for handling -mfoo -mno-foo from the driver to -cc1. It also changes -cc1 to apply the options in order, fixing pr16943. The handling of -mno-mmx -msse is now an explicit special case. llvm-svn: 188817
* ARM: default to arm1176jzf-s for hard-float platforms.Tim Northover2013-08-201-2/+10
| | | | | | | | | | | | It makes no sense to try and compile for arm7tdmi when we're targeting something like gnueabihf. Although not strictly the most basic hardware conceivable, I believe arm1176jzf-s is a reasonable compromise (that can always be overridden explicitly if needed) since it's still in reasonably common use unlike earlier cores. Patch by Stephen Kelly. llvm-svn: 188796
* Re-apply r188666Alexey Samsonov2013-08-192-3/+14
| | | | llvm-svn: 188675
* clang/Driver: [PR12920] Don't forward any -W arguments to gcc-as and gcc-ld.NAKAMURA Takumi2013-08-191-0/+5
| | | | | | | | AFAIK, there are no -W options for gcc-as and gcc-ld. It caused failure to build clang with gcc-4.7 on cygwin. FIXME: Could we recategorize Options for gcc-as and gcc-ld? llvm-svn: 188668
* Revert r188666: it breaks the buildbotsAlexey Samsonov2013-08-191-13/+3
| | | | llvm-svn: 188667
* Fix PR16768: properly report malformed sanitizer blacklist file contentsAlexey Samsonov2013-08-191-3/+13
| | | | llvm-svn: 188666
* Move SanitizerArgs to the clang DriverAlexey Samsonov2013-08-197-147/+22
| | | | | | | | | | | | | | | | Summary: This change turns SanitizerArgs into high-level options stored in the Driver, which are parsed lazily. This fixes an issue of multiple copies of the same diagnostic message produced by sanitizer arguments parser. Reviewers: rsmith Reviewed By: rsmith CC: chandlerc, eugenis, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1341 llvm-svn: 188660
* Windows ToolChain: add VS bin dir to PogramPathsHans Wennborg2013-08-161-37/+42
| | | | | | | | | | | | | We have a lot of fancy logic to find Visual Studio, which is currently used to set the system header include paths. Use the same code to set the ProgramPaths, which is used for finding programs such as link.exe. Previously, Clang would just search PATH for link.exe, but now it should find it if it's able to find Visual Studio. Differential Revision: http://llvm-reviews.chandlerc.com/D1417 llvm-svn: 188531
* make arm-use-movt available for all ARMRenato Golin2013-08-151-1/+1
| | | | | | | | | | | | This updates clang according to a pending patch for llvm to rename of the -arm-darwin-use-movt to arm-use-movt to make it available for all of ARM. note: please apply this close to the llvm change. Patch by Jeroen Hofstee. llvm-svn: 188488
* Build unwind tables by default on NetBSD.Joerg Sonnenberger2013-08-151-0/+3
| | | | llvm-svn: 188463
* Use the integrated assembler on NetBSD/powerpc by default.Joerg Sonnenberger2013-08-151-0/+5
| | | | llvm-svn: 188462
* Add support for -fsanitize-blacklist and default blacklists for DFSan.Peter Collingbourne2013-08-141-0/+3
| | | | | | | | Also add some documentation. Differential Revision: http://llvm-reviews.chandlerc.com/D1346 llvm-svn: 188403
* Enhance the clang -v gcc debug printing to skip obviously bad and duplicate ↵Benjamin Kramer2013-08-142-4/+6
| | | | | | | | | | | | | | | paths. Otherwise it lists all files (e.g. shared libraries) that happen to be in the same paths the GCC installations usually reside in. On a x86_64 Debian 7 system with i386 multilibs. before: clang -v 2>&1|wc -l 3059 after: clang -v 2>&1|wc -l 10 llvm-svn: 188400
OpenPOWER on IntegriCloud