regardless of the architecture).
- This is a good default for development & testing; for example without this
any tests using 'clang' in the test suite will fail on PowerPC, since the
driver will avoid using clang.
- We don't want to actually ship something built this way, but that should be
handled via some sort of configuration file.
llvm-svn: 76886
using -traditional and -traditional-cpp with clang an error because
it's unsupported in clang and causes a significant change in the
semantics of the language.
llvm-svn: 75690
with a particular system root directory and can be used with a different
system root directory when the headers it depends on have been installed.
Relocatable precompiled headers rewrite the file names of the headers used
when generating the PCH file into the corresponding file names of the
headers available when using the PCH file.
Addresses <rdar://problem/7001604>.
llvm-svn: 74885
- Not all tools give good error messages, and sometimes the tool can fail w/o
any error (for example, when signalled).
- We suppress this message when the failing command is the compiler and it
failed normally (exit code == 1), under the assumption that it gave a good
diagnostic.
For example, for a linker failure we now get:
--
ddunbar@lordcrumb:tmp$ clang a.c b.c
ld: duplicate symbol _x in /var/folders/cl/clrOX6SaG+moCeRKEI4PtU+++TI/-Tmp-/cc-bXYITq.o and /var/folders/cl/clrOX6SaG+moCeRKEI4PtU+++TI/-Tmp-/cc-6uK4jD.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--
For a compiler crash we get:
--
ddunbar@lordcrumb:tmp$ clang t.i
Assertion failed: (CGT.getTargetData().getTypeAllocSizeInBits(STy) == RL.getSize()), function layoutStructFields, file CodeGenTypes.cpp, line 573.
0 clang-cc 0x0000000100f1f1f1 PrintStackTrace(void*) + 38
... stack trace and virtual stack trace follow ...
clang: error: compiler command failed due to signal 6 (use -v to see invocation)
--
But for a regular compilation failure we get the usual:
--
ddunbar@lordcrumb:tmp$ clang c.c
c.c:1:6: error: invalid token after top level declarator
int x
^
1 diagnostic generated.
--
- No test case, not amenable to non-executable testing. :/
- <rdar://problem/6945613>
llvm-svn: 74629
function attributes. There are predefined macros that are defined when stack
protectors are used: __SSP__=1 with -fstack-protector and __SSP_ALL__=2 with
-fstack-protector-all.
llvm-svn: 74405
compiled with -fobjc-sender-dependent-dispatch. This is used in AOP, COP, implementing object
planes, and a few other things.
Patch by David Chisnall.
llvm-svn: 72275
- We could just warn about -fno-unit-at-a-time, but in practice people using it
probably aren't going to get what they want out of clang.
Also, use "clang" specified error for unsupported things instead of driver
unsupported error.
llvm-svn: 72272
- This commit has some messy stuff in it to extend string lifetimes, but that
will go away once we switch to using the enum'd Triple interfaces.
llvm-svn: 72243
- Default to yonah on Darwin (to get SSE3).
- Default to Pentium4 (32-bit) and x86-64 (64-bit) on
non-Darwin. Welcome to the 21st century.
llvm-svn: 71069
- This is a WIP...
- This adds -march= handling to the driver, and fixes the defaulting
of -mcpu on Darwin (which was using the wrong test).
Instead of handling -m{sse, ...} in the driver, pass them to clang-cc as
-target-feature [+-]name
In clang-cc, communicate with the (clang) target to discover the legal
features of a target, and the features which are enabled based on
-mcpu. This is currently hardcoded just enough to not be a feature
regression, we need to get this information from the backend's
TableGen information somehow.
This is used to construct the full list of features which are being
used, which is in turn used to initialize the predefines.
llvm-svn: 71061
- Currently just an alias for --analyze, eventually we want to refit
--analyze so that it is less automatic (i.e., does not force plist
output and does not hard code the list of checks).
llvm-svn: 71056
- This implements gcc style Objective-C interface layout (I
think). Currently it is always off, there is no functionality
change unless this is passed.
For the curious, the deal is that gcc lays out the fields of a
subclass as if they were part of the superclass. That is, the
subclass fields immediately follow the super class fields instead
of being padded to the alignment of the superclass structure.
- Currently gcc uses the tight layout in 32-bit and 64-bit modes, and
llvm-gcc uses it in 32-bit only, for reasons which aren't clear
yet. We probably want to switch to matching gcc, once this makes it
through testing... my hope is that we can also fix llvm-gcc in
order to maintain compatibility between the compilers.
llvm-svn: 70827
Also, put a line of whitespace between the diagnostic and the source
code/caret line when the start of the actual source code text lines up
(or nearly lines up) with the most recent line of the diagnostic. For
example, here it's okay for the last line of the diagnostic to be
(vertically) next to the source line, because there is horizontal
whitespace to separate them:
decl-expr-ambiguity.cpp:12:16: error: function-style cast to a builtin
type can only take one argument
typeof(int)(a,5)<<a;
However, here is a case where we need the vertical separation (since
there is no horizontal separation):
message-length.c:10:46: warning: incompatible pointer types initializing 'void
(int, float, char, float)', expected 'int (*)(int, float, short,
float)'
int (*fp1)(int, float, short, float) = f;
This is part one of <rdar://problem/6711348>.
llvm-svn: 70578
Ted Kremenek