up adding them twice when running with -no-integrated-cpp or
-save-temps.
- <rdar://problem/6766636> -save-temps falls over with prefix headers
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68660 91177308-0d34-0410-b5e6-96231b3b80d8
incorrectly. I'm blanking on the smartest way to write this search,
but we should just do the right thing when we move to TableGen.
- <rdar://problem/6761194> [driver] -Wextra-tokens isn't parsed
correctly
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68525 91177308-0d34-0410-b5e6-96231b3b80d8
preceeded by a linker input flag.
- <rdar://problem/6757236> clang should make a dSYM when going
straight from source to binary
- This still matches gcc, but the right way to solve this would be to
detect the situation we care about (we are compiling from source
and linking in one step), instead of looking at the suffix of the
input file. The Tool doesn't quite have enough information to do
this yet, however.
- Also, find the suffix correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68417 91177308-0d34-0410-b5e6-96231b3b80d8
- <rdar://problem/6741594> [pth] don't abuse -x to drive pth
generation
- Simpler, and fixes PR3915.
Cleanup test cases for PTH:
- Update to use -emit-pth
- Removed PTH test of carbon.c and cocoa.mm; these didn't actually
verify anything, and since PTH is token based the extra coverage
(over cocoa.m) isn't particularly helpful.
- Split PTH tests in cocoa.m to cocoa-pth.m, solely to increase
available parallelism when running tests.
Ted, could you update the PTH test cases (include-pth.c and
cocoa-pth.m) to have some sort of positive check that the PTH is
getting used? "# of PTH cache hits" or "tokens read from PTH cache"
statistics would work great. :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68189 91177308-0d34-0410-b5e6-96231b3b80d8
- Always pass -triple to clang-cc (-arch will be removed).
- clang-cc doesn't play guess work with the target triple anymore.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68119 91177308-0d34-0410-b5e6-96231b3b80d8
- -emit-llvm no longer changes what compilation steps are done.
- -emit-llvm and -emit-llvm -S write output files with .o and .s
suffixes, respectively.
- <rdar://problem/6714125> clang-driver should support -O4 and -flto,
like llvm-gcc
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67645 91177308-0d34-0410-b5e6-96231b3b80d8
- Don't default to using clang for C++ (use -ccc-clang-cxx to
override).
- Default to only using clang on i386 and x86_64 (use
-ccc-clang-archs "" to override).
- <rdar://problem/6712350> [driver] clang should not be used on
powerpc by default
- <rdar://problem/6705767> driver should default to -ccc-no-clang-cxx
I plan to add a warning that we are not using the clang compiler for
the given compilation so that users do not think clang is being used
in situations it isn't.
This change is motivated by the desire to be able to drop clang into a
build and have things "just work", even if it happens to get used to
compile C++ code or code for an architecture we don't support yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67640 91177308-0d34-0410-b5e6-96231b3b80d8
- <rdar://problem/6669441> ccc doesn't handle assembler-with-cpp
semantics correctly (but clang supports it)
- This is sad, because it requires a fairly useless target
hook. C'est la vie.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67418 91177308-0d34-0410-b5e6-96231b3b80d8
with a raw lexer instead of a PP lexer. This means that -verify doesn't scan
#include'd headers for expected-error/warning strings, and it also means that it
doesn't ignore them in #if 0.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59774 91177308-0d34-0410-b5e6-96231b3b80d8