Add frontend flags to enable bitcode verifier pass.

llvm-svn: 146441

Hexagon backend support

llvm-svn: 146413

Driver: Handle -f{no-}honor-infinities, -f{no-}honor-nans, and
-ffinite-math-only.
- No test case yet, I don't know how to construct a situation where this
matters.

llvm-svn: 146297

Stack realignment is a tristate. Add -mno-stackrealign to turn off all stack
realignment, even with locals with alignment exceeding the ABI guarantee.

llvm-svn: 145909

Add -mstack-alignment=X and fix -mstackrealign handling now that the
backend options are gone.

llvm-svn: 145868

Eliminate the -emit-module option, which emitted a module by parsing a
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.

llvm-svn:

Eliminate the -emit-module option, which emitted a module by parsing a
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.

llvm-svn: 145444

show more ...

Silence GCC warnings, RefCountedBase is meant to be default-initialized here.

llvm-svn: 145396

Set __OPTIMIZE_SIZE__ on -Os and -Oz. This matches gcc's behaviour on both OS X
and linux.

llvm-svn: 145142

implement __has_feature(address_sanitizer); also use LangOpts.AddressSanitizer instead of CodeGenOpts.AddressSanitizer

llvm-svn: 145054

Add driver arguments -ftemplate-depth=N and -fconstexpr-depth=N, with the same
semantics and defaults as the corresponding g++ arguments. The historical g++
argument -ftemplate-depth-N is kept for co

Add driver arguments -ftemplate-depth=N and -fconstexpr-depth=N, with the same
semantics and defaults as the corresponding g++ arguments. The historical g++
argument -ftemplate-depth-N is kept for compatibility, but modern g++ versions
no longer document that option.

Add -cc1 argument -fconstexpr-depth N to implement the corresponding
functionality.

The -ftemplate-depth=N part of this fixes PR9890.

llvm-svn: 145045

show more ...

Refine placement of LangOptions object in CompilerInvocation by adding a new baseclass CompilerInvocationBase with a custom copy constructor. This ensures that whenever the CompilerInvocation object

Refine placement of LangOptions object in CompilerInvocation by adding a new baseclass CompilerInvocationBase with a custom copy constructor. This ensures that whenever the CompilerInvocation object's copy constructor is used we always clone the LangOptions object.

llvm-svn: 144973

show more ...

Make 'LangOptions' in CompilerInvocation a heap-allocated, reference counted object. I discovered that llvm::RefCountedBase<T> has
a bug where the reference count is copied in the copy constructor,

Make 'LangOptions' in CompilerInvocation a heap-allocated, reference counted object. I discovered that llvm::RefCountedBase<T> has
a bug where the reference count is copied in the copy constructor, which means that there were cases when the CompilerInvocation
objects created by ASTUnit were actually leaked. When I fixed that bug locally, it showed that a whole bunch of code assumed
that the LangOptions object that was part of CompilerInvocation was still alive. By making it heap-allocated and reference counted,
we can keep it around after the CompilerInvocation object goes away.

As part of this change, change CompilerInvocation:getLangOptions() to return a pointer, acting as another clue that this
object may outlive the CompilerInvocation object.

This commit doesn't fix the CompilerInvocation leak itself. That will come when I commit the fix to llvm::RefCountedBase<T> to
mainline LLVM.

llvm-svn: 144930

show more ...

Add -f[no-]address-sanitizer flag

llvm-svn: 144800

Add support for building a module from a module map to the -cc1
interface. This is currently limited to modules with umbrella
headers.

llvm-svn: 144736

Add a -cc1-level option -fmodule-name=<name>, which will be used when
building modules.

llvm-svn: 144680

Rip out one of the features I added for the driver-include-management.
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is no

Rip out one of the features I added for the driver-include-management.
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.

llvm-svn: 143917

show more ...

Fix a significant oversight in my move of MSVC includes to the driver:
actually manage the builtin header file includes as well as the system
ones.

This one is actually debatable whether it belongs

Fix a significant oversight in my move of MSVC includes to the driver:
actually manage the builtin header file includes as well as the system
ones.

This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.

Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.

Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.

llvm-svn: 143801

show more ...

Add two flags to the CC1 layer that I was hoping to avoid. We need to
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-use

Add two flags to the CC1 layer that I was hoping to avoid. We need to
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.

There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.

Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.

llvm-svn: 143798

show more ...

Enable -flimit-debug-info by default. Now, clang lazily emits debug info for structs. Original behavior can be restored using -fno-limit-debug-info.

llvm-svn: 143733

Fix various minor issues find via unreachable code warnings, from
Ahmed Charles!

llvm-svn: 143569

Add an option to emulate the strange Apple gcc behavior of #pragma pack.

<rdar://problem/10374763>

llvm-svn: 143527

rename getHostTriple into getDefaultTargetTriple in clang

llvm-svn: 143503

Add support for lazily linking bitcode files (using a new
-mlink-bitcode-file flag), and more generally llvm::Modules, before
running optimisations.

llvm-svn: 143314

Start work on SerializedDiagnosticPrinter, a new DiagnosticConsumer that serializes out the diagnostics for a given translation unit to a bit code file. This is a WIP.

The motivation for this new D

Start work on SerializedDiagnosticPrinter, a new DiagnosticConsumer that serializes out the diagnostics for a given translation unit to a bit code file. This is a WIP.

The motivation for this new DiagnosticConsumer is to provide a way for tools invoking the compiler
to get its diagnostics via a libclang interface, rather than textually parsing the compiler output.
This gives us flexibility to change the compiler's textual output, but have a structured data format
for clients to use to get the diagnostics via a stable API.

I have no tests for this, but llvm-bcanalyzer so far shows that the emitted file is well-formed.

More work to follow.

llvm-svn: 143259

show more ...

Make -fms-compatibility imply -fms-extensions. Fixes PR11204.

llvm-svn: 142797