installations. This first selects a set of prefixes and a set of
compatible triples for the current architecture. Once selected, we drive
the search with a single piece of code.
This code isn't particularly efficient as it stands, but its only
executed once. I'm hoping as I clean up the users of this information,
it will also slowly become both cleaner and more efficient.
This also changes the behavior slightly. Previously, we had an ad-hoc
list of prefixes and triples, and we only looked for some triples
beneath specific prefixes and vice versa. This has led to lots of
one-off patches to support triple X, or support lib dir Y. Even without
going to a fully universal driver, we can do better here. This patch
makes us always look first in either 'lib32' or 'lib64' on 32- or 64-bit
hosts (resp.). However, we *always* look in 'lib'.
Currently I have one lingering problem with this strategy. We might find
a newer or better GCC version under a different (but equally compatible)
triple. Fundamentally, this loop needs to be fused with the one below.
That's my next patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141056 91177308-0d34-0410-b5e6-96231b3b80d8
is designed to allow the detection to record more rich information about
the installation than just a single path.
Mostly, the functionality remains the same. This is primarily
a factoring change. However, the new factoring immediately fixes one
issue where on ubuntu we didn't walk up enough layers to reach the
parent lib path. I'll have a test tree for that once I finish making the
Ubuntu tree work reasonably.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141011 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140999 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140995 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140990 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140981 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140957 91177308-0d34-0410-b5e6-96231b3b80d8
This patch may do what it describes, it may not. It's hard to tell as
its completely unclear what this is supposed to do. There are also no
test cases. More importantly, this seems to have broken lots of linker
invocations on multilib Linux systems.
The manual pages for 'ld' on Linux mention translating a '=' at the
beginning of the path into a *configure time* sysroot prefix (this is,
I believe, distinct from the --sysroot flag which 'ld' also can
support). I tested this with a normal binutils 'ld', a binutils 'ld'
with the sysroot flag enabled, and gold with the sysroot flag enabled,
and all of them try to open the path '=/lib/../lib32', No translation
occurs.
I think at the very least inserting an '=' needs to be conditioned on
some indication that it is supported and desired. I'm also curious to
see what toolchain and whan environment cause it to actually make
a difference.
I'm going to add a test case for basic sanity of Linux 'ld' invocations
from Clang in a follow-up commit that would have caught this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140908 91177308-0d34-0410-b5e6-96231b3b80d8
to operate "as if" in a certain working directory.
- For now, we just implement this by changing the actual working directory, but
eventually we would want to handle this transparently. This is useful to
avoid an extra exec() pair in some situations, and will be something we would
want to support for more flexibility in using the Clang libraries.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140409 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140341 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces the hack to read UNAME_RELEASE from the environment when
identifying the OS version on Darwin, and it's more flexible. It's also
horribly ugly, but at least this consolidates the ugliness to touch less of
the code so that it will be easier to rip out later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140187 91177308-0d34-0410-b5e6-96231b3b80d8
Microsoft specific tweaking will now fall into 2 categories:
- fms-extension: Microsoft specific extensions that should never change the meaning of an otherwise well formed code. Currently map to LangOptions::Microsoft. (To be clearer, I am planning to change the name to LangOptions::MicrosoftExt).
- fms-compatibility: Really a MSVC emulation mode. Map to LangOptions::MicrosoftMode. Can change the meaning of an otherwise standard conformant program.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139978 91177308-0d34-0410-b5e6-96231b3b80d8
#include or #import direcctives of framework headers into module
imports of the corresponding framework module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139860 91177308-0d34-0410-b5e6-96231b3b80d8
feature akin to the ARC runtime checks. Removes a terrible hack where
IR gen needed to find the declarations of those symbols in the translation
unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139404 91177308-0d34-0410-b5e6-96231b3b80d8
as well as the search path printed by -print-search-dirs.
The main purpose of this change is to cause -print-file-name=include
to print the path to the include directory under Clang's resource
directory, instead of the system compiler's include directory, whose
header files Clang may not be able to parse. Some build scripts will
do something like:
$(CC) -nostdinc -I`$(CC) -print-file-name=include`
to exclude all header paths except the compiler's.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139127 91177308-0d34-0410-b5e6-96231b3b80d8
I had to force -fno-delayed-template-parsing on some Index tests because delayed template parsing will change the output of some tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138942 91177308-0d34-0410-b5e6-96231b3b80d8
and doing a simple search. Before we would manually check for the linker
before the -B options were searched.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138941 91177308-0d34-0410-b5e6-96231b3b80d8
synthesis. This new feature is currently placed under
-fobjc-default-synthesize-properties option
and is off by default pending further testing.
It will become the default feature soon.
// rdar://8843851
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138913 91177308-0d34-0410-b5e6-96231b3b80d8
cases we want the prefix to be the original file name less the suffix. For an
input such as test.c to named temporary would be something like test-3O4Clq.o
Part of <rdar://problem/8314451>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138662 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138343 91177308-0d34-0410-b5e6-96231b3b80d8
from stdin. This allows Eli and the like to continue with their debugging
trickery without loss of limb (or car) on my part. :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137906 91177308-0d34-0410-b5e6-96231b3b80d8
automatically invoking llvm-gcc's cc1plus, which doesn't support all options
supported by Clang. Therefore, filter out unsupported options.
rdar://9964354
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137842 91177308-0d34-0410-b5e6-96231b3b80d8
Outside the driver, they were already treated that way, but the driver was not
giving them the same special treatment as -fapple-kext, e.g., falling back to
llvm-gcc for i386/Darwin kexts. Radar 9868422.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137639 91177308-0d34-0410-b5e6-96231b3b80d8
Since -mkernel implies -fapple-kext, this just extends the current behavior
for -fapple-kext to apply for -mkernel as well. Radar 9933387.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137566 91177308-0d34-0410-b5e6-96231b3b80d8
information including the fully preprocessed source file(s) and command line
arguments. The developer is asked to attach this diagnostic information to a
bug report.
rdar://9575623
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136702 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately, llvmgcc doesn't always work when writing temporary output to
/dev/null. Therefore, create a temp file that is later deleted.
rdar://9837692
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136644 91177308-0d34-0410-b5e6-96231b3b80d8
for quoted header lookup when dealing with not-yet-installed
frameworks. Fixes <rdar://problem/9824020>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136331 91177308-0d34-0410-b5e6-96231b3b80d8
use in KEXTs. However, users/Xcode still need to tweak the linker flags to do
the right thing, and end up using -Xlinker, for example. Instead, have the
driver "do the right thing" when linking when -fapple-kext is present on the
command line, and we should have Xcode use -fapple-kext instead of setting other
flags like -Xlinker -kext or -nodefaultlibs.
rdar://7809940
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136294 91177308-0d34-0410-b5e6-96231b3b80d8
when using ccache and libtool.m4 assumes that the compiler cannot print
warnings about options it knows about.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135723 91177308-0d34-0410-b5e6-96231b3b80d8
including the fully preprocessed source file(s) and command line arguments. The
developer is asked to attach this diagnostic information to a bug report.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135614 91177308-0d34-0410-b5e6-96231b3b80d8
x86_64-pc-win32-macho is used in conjunction with -no-integrated-as go ahead and
use the Darwin system assembler.
rdar://9785470
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135604 91177308-0d34-0410-b5e6-96231b3b80d8
clang namespace. There are a number of LLVM types that are used pervasively
and it doesn't make sense to keep qualifying them. Start with casting
operators.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135574 91177308-0d34-0410-b5e6-96231b3b80d8
-arcmt-migrate-emit-errors : Emits the pre-migration ARC errors but it doesn't affect anything else
-arcmt-migrate-report-output : Writes out the pre-migration ARC errors to the provided plist file
rdar://9791454
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135491 91177308-0d34-0410-b5e6-96231b3b80d8
This is a new mode of migration, where we avoid modifying the original files but
we emit temporary files instead.
<path> will be used to keep migration process metadata. Currently the temporary files
that are produced are put in the system's temp directory but we can put them
in the <path> if is necessary.
Also introduce new ARC migration functions in libclang whose only purpose,
currently, is to accept <path> and provide pairs of original file/transformed file
to map from the originals to the files after transformations are applied.
Finally introduce the c-arcmt-test utility that exercises the new libclang functions,
update arcmt-test, and add tests for the whole process.
rdar://9735086.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134844 91177308-0d34-0410-b5e6-96231b3b80d8
exception in Objective-C; in Objective-C++ we still use std::terminate().
This is only available in very recent runtimes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134456 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134453 91177308-0d34-0410-b5e6-96231b3b80d8
Sorry! This commit worked in CMake, but
CXX_INCLUDE_ROOT is defined in a different
config.h for autoconf.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133715 91177308-0d34-0410-b5e6-96231b3b80d8
The -cxx-isystem path is not prefixed with the sysroot directory, so it's
not a good way for the driver to set the system default C++ search path.
Instead, add -stdlib as a cc1 option and teach the frontend how to find the
headers. The driver can then just pass -stdlib through to "cc1".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133547 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133543 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133489 91177308-0d34-0410-b5e6-96231b3b80d8
AFAIK, RHEL5 (and its clones) provides g++44 as the package "gcc44-c++".
By default, g++-4.1.1 is available, though, its libstdc++ would not be suitable to clang++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133156 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132868 91177308-0d34-0410-b5e6-96231b3b80d8
common C++ pattern of using the same name for the constructor argument as you
do for the member. Noticed by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132626 91177308-0d34-0410-b5e6-96231b3b80d8
we look in /usr/lib to find crt1.o, and that depends only on where libc
is installed.
This fixes the case of using a different gcc installation in a distro
without multilib.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132551 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch we would still link with the system libstdc++. It worked
fine most of the time, but would break if the used headers were a lot newer
than the system libraries.
This patch changes the driver to use the libraries corresponding to the
headers the user selected.
This fixes, for example, using 4.5 headers in a system with gcc 4.1.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132497 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Matthieu Monrocq with tweaks by me to avoid StringRefs in the static
diagnostic data structures, which resulted in a huge global-var-init function.
Depends on llvm commit r132046.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132047 91177308-0d34-0410-b5e6-96231b3b80d8
prints the file, line, and column of a diagnostic. We currently
support Clang's normal format, MSVC, and Vi formats.
Note that we no longer change the diagnostic format based on
-fms-extensions.
Patch by Andrew Fish!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131794 91177308-0d34-0410-b5e6-96231b3b80d8
Preserve the original triple in the NetBSD toolchain when using -m32 or
-m64 and the resulting effective target is different from the triple it
started with. This allows -m32 to use the same assembler/linking in
cross-compiling mode and avoids confusion about passing down target
specific flags in that case like --32.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131404 91177308-0d34-0410-b5e6-96231b3b80d8
function. Extend the logic to check if the input was compiled.
Use -relax-all as default only if -O0 is used for compilation.
Fixes bug 9290.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130983 91177308-0d34-0410-b5e6-96231b3b80d8
that library has never been in the SDK. Fortunately, it shouldn't be necessary,
since that library was also removed in 10.6.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130595 91177308-0d34-0410-b5e6-96231b3b80d8
to the linker.
- Only do this explicitly with the argument for now, the linker will need to
explicitly add support for this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130594 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130055 91177308-0d34-0410-b5e6-96231b3b80d8
-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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130051 91177308-0d34-0410-b5e6-96231b3b80d8
Using this flag is necessary for compatibility with Microsoft template code.
This also provides some parsing speed improvement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130022 91177308-0d34-0410-b5e6-96231b3b80d8
compile time) and .gcda emission (at runtime). --coverage enables both.
This does not yet add the profile_rt library to the link step if -fprofile-arcs
is enabled when linking.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129956 91177308-0d34-0410-b5e6-96231b3b80d8
Put the logic for deciding the default name for gcc/g++
in the only place that actually cares about it.
This also pushes an ifdef out of the generic driver code
to a little further down, when the target is actually known.
Hopefully it can be changed into just a runtime check
in the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129212 91177308-0d34-0410-b5e6-96231b3b80d8
existing CC_PRINT_OPTIONS and CC_PRINT_HEADERS, which can be used to
transparently capture the compiler diagnostics from a build.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129082 91177308-0d34-0410-b5e6-96231b3b80d8
These stacks are often less important than those on primary diagnostics.
As the number of notes grows, this becomes increasingly important. The
include stack printing is clever and doesn't print stacks for adjacent
diagnostics from the same file, but when a note is in between a sequence
of errors in a header file, and the notes all refer to some other file,
we end up getting a worst-case ping-pong of include stacks that take up
a great deal of vertical space.
Still, for now, the default behavior isn't changed. We can evaluate user
feedback with the flag.
Patch by Richard Trieu, a couple of style tweaks from me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128371 91177308-0d34-0410-b5e6-96231b3b80d8
default for -fwrapv if that flag isn't specified explicitly. We always
prefer an explict setting of -fwrapv when present. Also adds support for
-fno-wrapv to allow disabling -fwrapv even when -fno-strict-overflow is
passed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128353 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128087 91177308-0d34-0410-b5e6-96231b3b80d8
program and fallback to plain version otherwise. Use this for the NetBSD
target to make it try e.g. i486--netbsdelf-as and -ld for target
i486--netbsdelf.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127996 91177308-0d34-0410-b5e6-96231b3b80d8
Drop program paths on NetBSD (unused). Only include lib dir, if
-nostdlib is absent. Use = to allow --sysroot to work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127995 91177308-0d34-0410-b5e6-96231b3b80d8
- We don't really support the majority of the horrible -traditional-cpp
behavior, but it is unlikely that we ever will either. This allows us to
start trying to use clang as a /usr/bin/cpp replacement and see what pieces
of -traditional-cpp mode people actually care about.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127911 91177308-0d34-0410-b5e6-96231b3b80d8
Issue this as an IR-gen error; it's not really worthwhile doing this
"right", i.e. in Sema, because IR gen knows a lot of tricks beyond
what the constant evaluator knows.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127854 91177308-0d34-0410-b5e6-96231b3b80d8
Chandler Carruth
Chad Rosier
John McCall
Daniel Dunbar
David Chisnall
Peter Collingbourne
Benjamin Kramer
Akira Hatanaka
David Blaikie
Bob Wilson
Francois Pichet
Douglas Gregor
Eli Friedman
Fariborz Jahanian
Rafael Espindola
Hans Wennborg
Eric Christopher
Nico Weber
NAKAMURA Takumi
Chris Lattner
Argyrios Kyrtzidis
Joerg Sonnenberger
Bill Wendling
Dylan Noblesmith
Nick Lewycky
Roman Divacky
Jim Grosbach
Ted Kremenek
Evan Cheng