Age | Commit message (Collapse) | Author |
|
This fixes the FIXMEs in ParseAnalyzeArgs. (Also a
precursor to moving the analyzer into an AST plugin.)
For consistency, do the same with AssemblerInvocation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147218 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control the maximum number of notes so
produced (default 10). Fix APValue printing to be able to pretty-print all
APValue types, and move the testing for this functionality from a unittest to
a -verify test now that it's visible in clang's output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146749 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
free function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146530 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146441 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146413 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-ffinite-math-only.
- No test case yet, I don't know how to construct a situation where this
matters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146297 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
realignment, even with locals with alignment exceeding the ABI guarantee.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145909 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
backend options are gone.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145868 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145444 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145396 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and linux.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145142 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LangOpts.AddressSanitizer instead of CodeGenOpts.AddressSanitizer
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145054 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145045 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144973 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144930 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144800 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
interface. This is currently limited to modules with umbrella
headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
building modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144680 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143917 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143801 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143798 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
structs. Original behavior can be restored using -fno-limit-debug-info.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143733 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Ahmed Charles!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143569 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<rdar://problem/10374763>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143527 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143503 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-mlink-bitcode-file flag), and more generally llvm::Modules, before
running optimisations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143314 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142797 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
closer to what GCC does, except that GCC also checks that the inodes for $PWD
and '.' match.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142633 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142418 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
r142300 but not this patch, clang -S may emit .s files that assemblers other
than llvm-mc can't parse.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142301 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
as part of the hash rather than ignoring them. This means we'll end up
building more module variants (overall), but it allows configuration
macros such as NDEBUG to work so long as they're specified via command
line. More to come in this space.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142187 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
paths). The -nostdinc behavior is now -nostdsysteminc + -nobuiltininc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141691 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141577 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141516 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This frontend-only flag is used by the IR generator to determine
whether to filter CUDA declarations for the host or for the device.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141301 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
line options.
- <rdar://problem/10120602>, PR9631
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141211 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
|
|
remove -analyzer-purge=none. (Small refactor as well: move the work of constructing AnalysisManager from the callers to the class itself.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140838 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140478 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140367 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
|
|
OpenCL is different from AltiVec in the way it supports vector literals. OpenCL
is strict with regards to semantic checks. For example, implicit conversions
and explicit casts between vectors of different types are disallowed.
Fixes PR10975. Submitted by: Anton Lokhmotov <Anton.lokhmotov@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140270 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
header files have the same name as clang's builtins, this creates clash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140009 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139987 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
compiler switch: -fms-compatility.
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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139827 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139696 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
target triple to separate modules built under different
conditions. The hash is used to create a subdirectory in the module
cache path where other invocations of the compiler (with the same
version, language options, etc.) can find the precompiled modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139662 91177308-0d34-0410-b5e6-96231b3b80d8
|