- This disables the system include directories, but not the compiler builtin
directories. Useful for projects that want to use things like the intrinsic
headers, but are otherwise freestanding.
- I'm willing to reconsider the option naming, I also considered providing an
explicit -builtinc (which would match -nobuiltininc), but this is more
consistent with existing options.
llvm-svn: 141692
this saga. Teach the driver to detect a GCC installed along side Clang
using the existing InstalledDir support in the Clang driver. This makes
a lot of Clang's behavior more automatic when it is installed along side
GCC.
Also include the first test cases (more to come, honest) which test both
the install directory behavior, and the version sorting behavior to show
that we're actually searching for the best candidate GCC installation
now.
llvm-svn: 141145
configuration, although the test still stubs out more directories than
are necessary or common in order to exercise all of the lookup paths
observed with upstream GCC.
This finishes testing the distribution-independent and
GCC-installation-independent parts of the library path search logic.
More testing is still needed for the triple detection, GCC-installation
detection, and handling distributions with unusual configurations.
llvm-svn: 141000
enabled for debian hosts, which is quite odd. I think all restriction on
when Clang attempts to use a multilib installation should go away. Clang
is fundamentally a cross compiler. It behaves more like GCC when built
as a cross compiler, and so it should just use multilib installs when
they are present on the system. However, there is a very specific
exemption for Exherbo, which I can't test on, so I'm leaving that in
place.
With this, check in a generic test tree for multilib on a 32-bit host.
This stubs out many directories that most distributions don't use but
that uptsream GCC supports. This is intended to be an agnostic test that
the driver behaves properly compared with the GCC driver it aims for
compatibility with.
Also, fix a bug in the driver that this testing exposed (see!) where it
was incorrectly testing the target architecture rather than the host
architecture.
If anyone is having trouble with the tree-structure stubs I'm creating
to test this, let me know and I can revisit the design. I chose this
over (for example) a tar-ball in order to make tests run faster at the
small, hopefully amortized VCS cost.
llvm-svn: 140999
include *any* path on crtbegin.o unless we actually find such a file via
one of the search paths. We still strictly check the search paths right
after this, so we'll catch any issues there.
The reason for this is that the driver does some normalization of the
path on the actual object file, and this changes the textual format of
the string on Windows. It no longer matches the textual format of the
sysroot flag.
llvm-svn: 140998
This requires fixing a latent bug -- if we used the default host triple
instead of an autodetected triple to locate GCC's installation, we
didn't go back and fix the GCC triple. Correct that with a pile of
hacks. This entire routine needs a major refactoring which I'm saving
for a subsequent commit. Essentially, the detection of the GCC triple
should be hoisted into the same routine as we locate the GCC
installation: the first is intrinsically tied to the latter. Then the
routine will just return the triple and base directory.
Also start to bring the rest of the library search path logic under
test, including locating crtbegin.o. Still need to test the multilib and
other behaviors, but there are also bugs in the way of that.
llvm-svn: 140995
This is still very much a WIP, but sysroot was completely broken before
this so we are moving closer to correctness.
The crux of this is that 'ld' (on Linux, the only place I'm touching
here) doesn't apply the sysroot to any flags given to it. Instead, the
driver must translate all the paths it adds to the link step with the
system root. This is easily observed by building a GCC that supports
sysroot, and checking its driver output.
This patch just fixes the non-multilib library search paths. We should
also use this in many other places, but first things first.
This also allows us to make the Linux 'ld' test independent of the host
system. This in turn will allow me to check in test tree configurations
based on various different distro's configuration. Again, WIP.
llvm-svn: 140990
precisely match the pattern and logic used by the GCC driver on Linux as
of a recent SVN checkout.
This happens to follow a *much* more principled approach. There is
a strict hierarchy of paths examined, first with multilib-suffixing,
second without such suffixing. Any and all of these directories which
exist will be added to the library search path when using GCC.
There were many places where Clang followed different paths, omitted
critical entries, and worst of all (in terms of challenges to debugging)
got the entries in a subtly wrong order.
If this breaks Clang on a distro you use, please let me know, and I'll
work with you to figure out what is needed to work on that distro. I've
checked the behavior of the latest release of Ubuntu, OpenSUSE, Fedora,
and Gentoo. I'll be testing it on those as well as Debian stable and
unstable and ArchLinux. I may even dig out a Slackware install.
No real regression tests yet, those will follow once I add enough
support for sysroot to simulate various distro layouts in the testsuite.
llvm-svn: 140981
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
llvm-svn: 140957
Make the suffixes optional everywhere, and just make sure they have the
right value. The suffixes aren't the interesting part of this test
anyways.
Sorry for the churn as I let the bots try out various patterns.
llvm-svn: 140927
This moves the existing code for CPATH into the driver and adds the environment lookup and path splitting there.
The paths are then passed down to cc1 with -I options (CPATH), added after the normal user-specified include dirs.
Language specific paths are passed via -LANG-isystem and the actual filtering is performed in the frontend.
I tried to match GCC's behavior as close as possible
Fixes PR8971.
llvm-svn: 140341
- wrong alignment for double (it was 4, but 8 is desired),
- added checks for _REENTRANT define,
- fixed the issue that defines were not tested (because the check for inside #ifdef).
llvm-svn: 138775
output on darwin so is hard coded there.
As a note this will need a little bit of refactoring in the class
hierarchy to separate it out for different verifiers based on input type.
Fixes rdar://8256258.
llvm-svn: 138343
automatically invoking llvm-gcc's cc1plus, which doesn't support all options
supported by Clang. Therefore, filter out unsupported options.
rdar://9964354
llvm-svn: 137842
Since -mkernel implies -fapple-kext, this just extends the current behavior
for -fapple-kext to apply for -mkernel as well. Radar 9933387.
llvm-svn: 137566
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
llvm-svn: 134453
that the linker has a place to put the temporary object file and can leave it
around (for the driver to clean up). This is important so that the object file
references in the debug info are preserved for possible use by dsymutil.
- <rdar://problem/8294279> executable has no debug symbols when compiled with LTO
llvm-svn: 133543
an assembly file it worked correctly, while for a .c file it would given an
error about how --noexecstack is not a supported argument to -Wa.
llvm-svn: 133489
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
matches GCC behavior which libstdc++ uses to limit #warning-based
messages about deprecation.
The machinery involves threading this through a new '-fdeprecated-macro'
flag for CC1. The flag defaults to "on", similarly to -Wdeprecated. We
turn the flag off in the driver when the warning is turned off (modulo
matching some GCC bugs). We record this as a language option, and key
the preprocessor on the option when introducing the define.
A separate flag rather than a '-D' flag allows us to properly represent
the difference between C and C++ builds (only C++ receives the define),
and it allows the specific behavior of following -Wdeprecated without
potentially impacting the set of user-provided macro flags.
llvm-svn: 130055
-Wwrite-strings. First and foremost, once the positive form of the flag
was passed, it could never be disabled by passing -Wno-write-strings.
Also, the diagnostic engine couldn't in turn use -Wwrite-strings to
control diagnostics (as GCC does) because it was essentially hijacked to
drive the language semantics.
Fix this by giving CC1 a clean '-fconst-strings' flag to enable
const-qualified strings in C and ObjC compilations. Corresponding
'-fno-const-strings' is also added. Then the driver is taught to
introduce '-fconst-strings' in the CC1 command when '-Wwrite-strings'
dominates.
This entire flag is basically GCC-bug-compatibility driven, so we also
match GCC's bug where '-w' doesn't actually disable -Wwrite-strings. I'm
open to changing this though as it seems insane.
llvm-svn: 130051
line options, instead of leveraging the blanket -mllvm option.
- This allows using the frontend itself without requiring the backend have
those options available (i.e., if the target wasn't built).
llvm-svn: 128087
MSYS substitutes path (that begins with "/") to de-mounted Windows path, even if it were nonexistent.
"/foo/bar" might be substituted to "C:/msysgit/foo/bar".
llvm-svn: 127861
MSYS substitutes path (that begins with "/") to de-mounted Windows path.
"/tmp" might be substituted as "C:/DOCUME~1/chapuni/LOCALS~1/Temp".
llvm-svn: 127860
*) Try to detect as much as possible from the system itself, not the distro.
This should make it easier to port to a new distro and more likely to
work on a unknown one.
*) The distro enum now doesn't include the arch. Just use the existing
host detection support in LLVM.
*) Correctly handle --sysroot.
A small regression is that now clang will pass bitcode file to the linker.
This is necessary for the gold plugin support to work.
It might be better to detect this at configure/cmake time, but doing it in
c++ first is a lot easier.
llvm-svn: 118382
- We actually pretend that we have two separate types for LLVM assembly/bitcode because we need to use the standard suffixes with LTO ('clang -O4 -c t.c' should generate 't.o').
It is now possible to do something like:
$ clang -emit-llvm -S t.c -o t.ll ... assorted other compile flags ...
$ clang -c t.ll -o t.o ... assorted other compile flags ...
and expect that the output will be almost* identical to:
$ clang -c t.c -o t.o ... assorted other compile flags ...
because all the target settings (default CPU, target features, etc.) will all be initialized properly by the driver/frontend.
*: This isn't perfect yet, because in practice we will end up running the optimization passes twice. It's possible to get something equivalent out with a well placed -mllvm -disable-llvm-optzns, but I'm still thinking about the cleanest way to solve this problem more generally.
llvm-svn: 105584
added as the last output step, instead of just hacking it into the link step.
- Among other things, this fixes dSYM generation when using multiple -arch options.
llvm-svn: 105475
'-fasm' and explicitly map from that flag to -fgnu-keywords in the driver. Turn
off the driver in the lexer test for this madness and add a test to the driver
that the translation actually works.
llvm-svn: 104428
means it isn't really possible to write the test case for this code, but this is
the kind of thing that really requires testing against the installed compiler
anyway.
llvm-svn: 100935
Clang is installed. This is designed to match gcc, and is important when
installed in a non-standard location.
- This is gross, but no worse than ever. It will die when we finally move to
the compiler-rt based toolchain, any day now.
llvm-svn: 100915
to compile a translation unit into the debug info for that file.
- Used by parts of Darwin build process to check compiler flags, etc.
- <rdar://problem/7256886> clang does not emit AT_APPLE_flags
llvm-svn: 91661
- We still need support for detecting the target features, since the name
doesn't actually do a good job of decribing what the CPU supports (for LLVM).
llvm-svn: 88819
Richard Smith