produce a note for that diagnostic either with a different DiagnosticEngine or
after calling DiagnosticEngine::Reset(). That didn't make any sense, and did the
wrong thing if the original diagnostic was suppressed.
llvm-svn: 170636
paths
- Inherit from Linux rather than ToolChain
- Override AddClangSystemIncludeArgs and AddClangCXXStdlibIncludeArgs
to properly set include paths.
llvm-svn: 169495
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
diagnostics script.
This addresses the FIXME pertaining to quoted arguments. We also delineate
between those flags that have an argument (e.g., -D macro, -MF file) and
those that do not (e.g., -M, -MM, -MG). Finally, we add the -dwarf-debug-flags
to the list of flags to be removed.
rdar://12329974
llvm-svn: 167152
is not a directory, Driver::GetProgramPath() routine does not try to append
the program name as a "path component" to it. It just joins the "prefix" with
the program name and checks the resulting path existence.
The patch reviewed by Rafael Espindola.
llvm-svn: 167114
we had the -ccc-clang-cxx and -ccc-no-clang-cxx options to force them
on or off for testing.
Clang c++ support is now production quality and these options are dead.
llvm-svn: 166986
Each option has a set of prefixes. When matching an argument such as
-funroll-loops. First the leading - is removed as it is a prefix. Then
a lower_bound search for "funroll-loops" is done against the option table by
option name. From there each option prefix + option name combination is tested
against the argument.
This allows us to support Microsoft style options where both / and - are valid
prefixes. It also simplifies the cases we already have where options come in
both - and -- forms. Almost every option for gnu-ld happens to have this form.
llvm-svn: 166444
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
llvm-svn: 165545
This parameter is useless because nowhere used explicitly and always
gets its default value - "false".
The patch reviewed by Rafael Espindola.
llvm-svn: 165149
'clang-cpp'.
For now, the test uses "REQUIRES: shell" to determine if the host system
supports "ln -s", which it uses to create a 'clang-cpp' symlink. This is a bit
hacky and should likely be directly supported by lit.cfg.
llvm-svn: 161317
- lib/Driver/Driver.cpp, tools/driver/driver.cpp: Exit status should not be propagated, although clang driver should catch exceptions.
- test/Driver/crash-report.c: Add REQUIRES:shell for now.
FIXME: setenv should work also on Lit.InternalShellRunner.
- test/Driver/crash-report.c: Remove XFAIL.
Thanks to Chad, To point out the issue.
llvm-svn: 160343
Now that we're only using -frewrite-includes rather than full preprocessing
when producing repro source files, we should also include command line macro
definitions in the repro script.
I don't have a test case for this because I'm not sure if/how I can open the
crash report file when the name is only known by scraping the crash report
output. Suggestions welcome if anyone thinks it'd be helpful.
llvm-svn: 159592
In future changes we should:
* use __builtin_trap rather than derefing 'random' volatile pointers.
* avoid dumping temporary files into /tmp when running tests, instead
preferring a location that is properly cleaned up by lit.
Review by Chandler Carruth.
llvm-svn: 159469
architecture; this was happening for tools such as lipo and dsymutil.
Also, if no -arch option has been specified, set the architecture based
on the TC default.
rdar://11329656
llvm-svn: 155730
overwriting the input file. For example,
clang -c foo.s -o foo.o -save-temps
Unfortunately, the original patch didn't compare the paths of the input and
output files. Thus, something like the following would fail to create foo.s.
cd /tmp/obj
clang -c ../src/foo.s -o foo.o -save-temps
rdar://11252615
llvm-svn: 155224
flags. We have preprocessed source, so we don't need these.
No test case as it's fairly difficult to make the compiler crash on demand. I'll
patiently wait for Ben to tell me how to do this in 2 lines of code. :)
rdar://11283560
llvm-svn: 155180
However, the '-x' option has special handling and wasn't following this
paradigm. Fix it to do so by claiming the arg as we parse the '-x' option.
rdar://11203340
llvm-svn: 154231
the new Objective-C NSArray/NSDictionary/NSNumber literal syntax.
This introduces a new library, libEdit, which provides a new way to support
migration of code that improves on the original ARC migrator. We now believe
that most of its functionality can be refactored into the existing libraries,
and thus this new library may shortly disappear.
llvm-svn: 152141
by -target and similar options. As discussed in PR 12026, the change
broke support for target-prefixed tools, i.e. calling x86_64--linux-ld
when compiling for x86_64--linux. Improve the test cases added
originally in r149083 to not require execution, just executable files.
Document the hack with appropiate FIXME comments.
llvm-svn: 151185
world on Solaris 11 for both x86 and x86-64 using the built-in assembler and
Solaris (not GNU) ld, however it currently relies on a hard-coded GCC location
to find crtbegin.o and crtend.o, as well as libgcc and libgcc_eh.
llvm-svn: 150580
And remove HAVE_CLANG_CONFIG_H, now that the header is generated
in the autoconf build, too.
Reverts r149571/restores r149504, now that config.h is generated
correctly by LLVM's configure in all build configurations.
llvm-svn: 150487
This was from way-back-when (r82583) when Clang's C++ support wasn't prime-time
yet. Production quality C++ was tested experimentally from r100119 and turned
on by default in r141063.
Patch by Justin Bogner.
llvm-svn: 150148
And remove HAVE_CLANG_CONFIG_H, now that the header is generated
in the autoconf build, too. (clang r149497 / llvm r149498)
Also include the config.h header after all other headers, per
the LLVM coding standards.
It also turns out WindowsToolChain.cpp wasn't using the config
header at all, so that include's just deleted now.
llvm-svn: 149504
driver based on discussions with Doug Gregor. There are several issues:
1) The patch was not reviewed prior to commit and there were review comments.
2) The design of the functionality (triple-prefixed tool invocation)
isn't the design we want for Clang going forward: it focuses on the
"user triple" rather than on the "toolchain triple", and forces that
bit of state into the API of every single toolchain instead of
handling it automatically in the common base classes.
3) The tests provided are not stable. They fail on a few Linux variants
(Gentoo among them) and on mingw32 and some other environments.
I *am* interested in the Clang driver being able to invoke
triple-prefixed tools, but we need to design that feature the right way.
This patch just extends the previous hack without fixing the underlying
problems with it. I'm working on a new design for this that I will mail
for review by tomorrow.
I am aware that this removes functionality that NetBSD relies on, but
this is ToT, not a release. This functionality hasn't been properly
designed, implemented, and tested yet. We can't "regress" until we get
something that really works, both with the immediate use cases and with
long term maintenance of the Clang driver.
For reference, the original commit log:
Keep track of the original target the user specified before
normalization. This used to be captured in DefaultTargetTriple and is
used for the (optional) $triple-$tool lookup for cross-compilation.
Do this properly by making it an attribute of the toolchain and use it
in combination with the computed triple as index for the toolchain
lookup.
llvm-svn: 149337
normalization. This used to be captured in DefaultTargetTriple and is
used for the (optional) $triple-$tool lookup for cross-compilation.
Do this properly by making it an attribute of the toolchain and use it
in combination with the computed triple as index for the toolchain
lookup.
llvm-svn: 149083
Linux toolchain selection -- sorry folks. =] This should fix the Hexagon
toolchain.
However, I would point out that I see why my testing didn't catch this
-- we have no tests for Hexagon. ;]
llvm-svn: 148977
gross hack to provide it from my previous patch removing HostInfo. This
was enshrining (and hiding from my searches) the concept of storing and
diff-ing the host and target triples. We don't have the host triple
reliably available, so we need to merely inspect the target system. I've
changed the logic in selecting library search paths for NetBSD to match
what I provided for FreeBSD -- we include both search paths, but put the
32-bit-on-64-bit-host path first so it trumps.
NetBSD maintainers, you may want to tweak this, or feel free to ask me
to tweak it. I've left a FIXME here about the challeng I see in fixing
this properly.
llvm-svn: 148952
did anything. The two big pieces of functionality it tried to provide
was to cache the ToolChain objects for each target, and to figure out
the exact target based on the flag set coming in to an invocation.
However, it had a lot of flaws even with those goals:
- Neither of these have anything to do with the host, or its info.
- The HostInfo class was setup as a full blown class *hierarchy* with
a separate implementation for each "host" OS. This required
dispatching just to create the objects in the first place.
- The hierarchy claimed to represent the host, when in fact it was
based on the target OS.
- Each leaf in the hierarchy was responsible for implementing the flag
processing and caching, resulting in a *lot* of copy-paste code and
quite a few bugs.
- The caching was consistently done based on architecture alone, even
though *any* aspect of the targeted triple might change the behavior
of the configured toolchain.
- Flag processing was already being done in the Driver proper,
separating the flag handling even more than it already is.
Instead of this, we can simply have the dispatch logic in the Driver
which previously created a HostInfo object create the ToolChain objects.
Adding caching in the Driver layer is a tiny amount of code. Finally,
pulling the flag processing into the Driver puts it where it belongs and
consolidates it in one location.
The result is that two functions, and maybe 100 lines of new code
replace over 10 classes and 800 lines of code. Woot.
This also paves the way to introduce more detailed ToolChain objects for
various OSes without threading through a new HostInfo type as well, and
the accompanying boiler plate. That, of course, was the yak I started to
shave that began this entire refactoring escapade. Wheee!
llvm-svn: 148950
helped stage the refactoring of things a bit, but really isn't the right
place for it. The driver may be responsible for compilations with many
different targets. In those cases, having a target triple in the driver
is actively misleading because for many of those compilations that is
not actually the triple being targeted.
This moves the last remaining users of the Driver's target triple to
instead use the ToolChain's target triple. The toolchain has a single,
concrete target it operates over, making this a more stable and natural
home for it.
llvm-svn: 148942
function. The logic for this, and I want to emphasize that this is the
logic for computing the *target* triple, is currently scattered
throughout various different HostInfo classes ToolChain factoring
functions. Best part, it is largely *duplicated* there. The goal is to
hoist all of that up to here where we can deal with it once, and in
a consistent manner.
Unfortunately, this uncovers more fun problems: the ToolChains assume
that the *actual* target triple is the one passed into them by these
factory functions, while the *host* triple is the one in the driver.
This already was a lie, and a damn lie, when the '-target' flag was
specified. It only really worked when the difference stemmed from '-m32'
and '-m64' flags. I'll have to fix that (and remove all the FIXMEs I've
introduced here to document the problem) before I can finish hoisting
the target-calculation logic.
It's bugs all the way down today it seems...
llvm-svn: 148839
inside the innards of the Driver implementation, and only ever
implemented to return 'true' for the Darwin OSes. Instead use a more
direct query on the target triple and a comment to document why the
target matters here.
If anyone is worried about this predicate getting wider use or improper
use, I can make it a local or private predicate in the driver.
llvm-svn: 148797
The Driver has a fixed target, whether we like it or not, the
DefaultTargetTriple is not a default. This at least makes things more
honest. I'll eventually get rid of most (if not all) of
DefaultTargetTriple with this proper triple object. Bit of a WIP.
llvm-svn: 148796
clang/lib/Driver/Driver.cpp: Don't pass through negative exit status, or parent would be confused.
llvm::sys::Program::Wait(): Suppose 0x8000XXXX and 0xC000XXXX as abnormal exit code and pass it as negative value.
Win32 Exception Handler: Exit with ExceptionCode on an unhandle exception.
llvm-svn: 145389
output files that are valid regardless of whether the compilation
succeeded or failed (but not if we crash). Add depfiles to the
failure result file list.
llvm-svn: 145018
- With the current implementation of sys::Program this always printed "2".
- The command execution code will output the right number anyway (including the signal name).
llvm-svn: 144993
There are now separate Triple::MacOSX and Triple::IOS values for the OS
so comparing against Triple::Darwin will fail to match those. Note that
I changed the expected output for the Driver/rewrite-objc.m test, which had
previously not been passing Darwin-specific options with the macosx triple.
llvm-svn: 141944
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.
llvm-svn: 140409
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.
llvm-svn: 139127
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>
llvm-svn: 138662
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
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
llvm-svn: 136702
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
llvm-svn: 136294
including the fully preprocessed source file(s) and command line arguments. The
developer is asked to attach this diagnostic information to a bug report.
llvm-svn: 135614
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.
llvm-svn: 132047
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.
llvm-svn: 129212
Eric Christopher