This reverts commit r293004 because it broke the buildbots with "unknown CPU"
errors. I tried to fix it in r293026, but that broke on Green Dragon with this
kind of error:
error: expected string not found in input
// CHECK: l{{ +}}df{{ +}}*ABS*{{ +}}{{0+}}{{.+}}preprocessed-input.c{{$}}
^
<stdin>:2:1: note: scanning from here
/Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64
^
<stdin>:2:67: note: possible intended match here
/Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64
I suppose this means that llvm-objdump doesn't support Mach-O, so the test
should indeed check for linux (but not for x86). I'll leave it to someone that
knows better.
llvm-svn: 293032
This test broke on a lot of non-x86 buildbots with "unknowm CPU" errors. I don't
see anything platform-specific about this test, and it seems to work fine on ARM
if we just remove the -triple i686 flags from the run line.
llvm-svn: 293026
Summary:
Clang appears to always use name as specified on the command
line, whereas gcc uses the name as specified in the linemarker at the
first line when compiling a preprocessed source. This results mismatch
between two compilers in FILE symbol table entry. This patch makes clang
to resemble gcc's behavior in finding the original source file name and
use it as an input file name.
Even with this patch, values of FILE symbol table entry may still be
different because clang uses dirname+basename for the entry whlie gcc
uses basename only. I'll write a patch for that once this patch is
committed.
Reviewers: dblaikie, inglorion
Reviewed By: inglorion
Subscribers: inglorion, aprantl, bruno
Differential Revision: https://reviews.llvm.org/D28796
llvm-svn: 293004
Summary:
This patch enables the following
1. AMD family 17h architecture using "znver1" tune flag (-march, -mcpu).
2. ISAs that are enabled for "znver1" architecture.
3. Checks ADX isa from cpuid to identify "znver1" flag when -march=native is used.
4. ISAs FMA4, XOP are disabled as they are dropped from amdfam17.
5. For the time being, it uses the btver2 scheduler model.
6. Test file is updated to check this flag.
This is linked to llvm review item https://reviews.llvm.org/D28017
Patch by Ganesh Gopalasubramanian. Additional test cases added by Craig Topper.
Reviewers: RKSimon, craig.topper
Subscribers: cfe-commits, RKSimon, ashutosh.nema, llvm-commits
Differential Revision: https://reviews.llvm.org/D28018
llvm-svn: 291544
removed as a duplicate header search path
The commit r126167 started passing the First index into RemoveDuplicates, but
forgot to update 0 to First in the loop that looks for the duplicate. This
resulted in a bug where an -iquoted search path was incorrectly removed if you
passed in the same path into -iquote and more than one time into -isystem.
rdar://23991350
Differential Revision: https://reviews.llvm.org/D27298
llvm-svn: 288491
Other AST consumers can deserialize interesting decls that we might
codegen, but they won't make it to the final object file and can trigger
assertions in debug information generation after finalization.
llvm-svn: 288221
This commit adds a new predefined macro named __OBJC_BOOL_IS_BOOL that describes
the Objective-C boolean type: its value is zero if the Objective-C boolean uses
the signed character type, otherwise its value is one as the Objective-C boolean
uses the builtin boolean type.
rdar://21170440
Differential Revision: https://reviews.llvm.org/D26234
llvm-svn: 287529
This option behaves in a similar spirit as -save-temps and writes
internal llvm statistics in json format to a file.
Differential Revision: https://reviews.llvm.org/D24820
llvm-svn: 282426
Original commit message:
Add -fdiagnostics-show-hotness
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281293
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281276
Since some profiling tools, such as gprof, ftrace, and uftrace, use
-pg option to generate a mcount function call at the entry of each
function. Function invocation can be detected by this hook function.
But mcount insertion is done before function inlining phase in clang,
sometime a function that already has a mcount call can be inlined in the
middle of another function.
This patch adds an attribute "counting-function" to each function
rather than emitting the mcount call directly in frontend so that this
attribute can be processed in backend. Then the mcount calls can be
properly inserted in backend after all the other optimizations are
completed.
Link: https://llvm.org/bugs/show_bug.cgi?id=28660
Reviewers: hans, rjmccall, hfinkel, rengolin, compnerd
Subscribers: shenhan, cfe-commits
Differential Revision: https://reviews.llvm.org/D22666
llvm-svn: 280355
rL275318 added the test Frontend/opencl.cl test, but that test was never actually run because Frontend/lit.local.cfg doesn't contain the '.cl' file suffix.
Once the test is activated, it fails with (unintended) compile errors in the newly added CHECK_INVALID_OPENCL_VERSION checks.
This patch adds the '.cl' file suffix to Frontend/lit.local.cfg to activate the test and fixes the test bug by adding '-fblocks' to the relevant command lines.
Patch by Martin Böhme!
Differential Revision: http://reviews.llvm.org/D22349
llvm-svn: 275405
Also fixes strict-aliasing option to only be allowed when OpenCL Version 1.0. Added testcase in test/Frontend/opencl-blocks.cl.
Patch by Aaron En Ye Shi.
Differential Revision: http://reviews.llvm.org/D22170
llvm-svn: 275318
Fix a regression which forbids using -std=cl|CL1.1|CL1.2|CL2.0 in driver.
Allow -std and -cl-std={cl|CL}{|1.1|1.2|2.0}.
Differential Revision: http://reviews.llvm.org/D20630
llvm-svn: 273015
Getting accurate locations for loops is important, because those locations are
used by the frontend to generate optimization remarks. Currently, optimization
remarks for loops often appear on the wrong line, often the first line of the
loop body instead of the loop itself. This is confusing because that line might
itself be another loop, or might be somewhere else completely if the body was
an inlined function call. This happens because of the way we find the loop's
starting location. First, we look for a preheader, and if we find one, and its
terminator has a debug location, then we use that. Otherwise, we look for a
location on an instruction in the loop header.
The fallback heuristic is not bad, but will almost always find the beginning of
the body, and not the loop statement itself. The preheader location search
often fails because there's often not a preheader, and even when there is a
preheader, depending on how it was formed, it sometimes carries the location of
some preceeding code.
I don't see any good theoretical way to fix this problem. On the other hand,
this seems like a straightforward solution: Put the debug location in the
loop's llvm.loop metadata. When emitting debug information, this commit causes
us to add the debug location as an operand to each loop's llvm.loop metadata.
Thus, we now generate this metadata for all loops (not just loops with
optimization hints) when we're otherwise generating debug information.
The remark test case changes depend on the companion LLVM commit r270771.
llvm-svn: 270772
Embedded bitcode should have private linkage instead of appending or external.
Otherwise, it will cause link failure due to duplicated symbols.
Also add llvm.embedded.module and llvm.cmdline to llvm.compiler.used so they
don't get optimized out.
rdar://problem/21555860
llvm-svn: 269679
Summary:
Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file. Using -fembed-bitcode-marker will only introduce a
marker in both sections.
Depends on D17390
Reviewers: rsmith
Subscribers: yaron.keren, vsk, cfe-commits
Differential Revision: http://reviews.llvm.org/D17392
llvm-svn: 269202
It makes compiler-rt tests fail if the gold plugin is enabled.
Revert "Rework interface for bitset-using features to use a notion of LTO visibility."
Revert "Driver: only produce CFI -fvisibility= error when compiling."
Revert "clang/test/CodeGenCXX/cfi-blacklist.cpp: Exclude ms targets. They would be non-cfi."
llvm-svn: 267871
Bitsets, and the compiler features they rely on (vtable opt, CFI),
only have visibility within the LTO'd part of the linkage unit. Therefore,
only enable these features for classes with hidden LTO visibility. This
notion is based on object file visibility or (on Windows)
dllimport/dllexport attributes.
We provide the [[clang::lto_visibility_public]] attribute to override the
compiler's LTO visibility inference in cases where the class is defined
in the non-LTO'd part of the linkage unit, or where the ABI supports
calling classes derived from abstract base classes with hidden visibility
in other linkage units (e.g. COM on Windows).
If the cross-DSO CFI mode is enabled, bitset checks are emitted even for
classes with public LTO visibility, as that mode uses a separate mechanism
to cause bitsets to be exported.
This mechanism replaces the whole-program-vtables blacklist, so remove the
-fwhole-program-vtables-blacklist flag.
Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the
support for the special attr:uuid blacklist entry is removed.
Differential Revision: http://reviews.llvm.org/D18635
llvm-svn: 267784
OpenCL spec requires __OPENCL_C_VERSION__ to be defined based on -cl-std option. This patch implements that.
The patch also defines __FAST_RELAXED_MATH__ based on -cl-fast-relaxed-math option.
Also fixed a test using -std=c99 for OpenCL program. Limit allowed language standard of OpenCL to be OpenCL standards.
Differential Revision: http://reviews.llvm.org/D19071
llvm-svn: 267590
Clang should pass -backend-option to LLVM even though there is no target machine, since LLVM passes are used when emitting LLVM IR.
Differential Revision: http://reviews.llvm.org/D17552
llvm-svn: 266117
The GNU profiling support indicates that the interface is `_mcount` rather than
`mcount`. Conditionalise the behaviour according to the `-meabi gnu` flag.
Resolves PR27311
llvm-svn: 266039
It seems that there was a miscommunication between Renato and I, and the
original behaviour of AArch64 was to be preserved and not to mirror the new
behaviour. Restore the original behaviour for AArch64. Addresses post-commit
review comments from Renato Golin.
llvm-svn: 265899
This adds support to optionally support using `__gnu_mcount_nc` as the mcount
interface rather than `mcount` for Linux and EABI. The other targets do not
provide an implementation for `__gnu_mcount_nc`. This can be activated via the
`-meabi gnu` flag.
Resolves PR23969.
llvm-svn: 265888
profiling and optimization remarks and indicate that no debug info shall
be emitted for these compile units.
http://reviews.llvm.org/D18808
<rdar://problem/25427165>
llvm-svn: 265862
This allows plugins which add AST passes to also define pragmas to do things
like only enable certain behaviour of the AST pass in files where a certain
pragma is used.
Differential Revision: http://reviews.llvm.org/D18319
llvm-svn: 265295
-H in gcc mode doesn't print -include headers, but they are included in
depfiles written by MMD and friends. Since /showIncludes is what's used instead
of depfiles, printing /FI there seems important (and matches cl.exe).
Instead of giving HeaderIncludeGen more options, just switch on ShowAllHeaders
in clang-cl mode and let clang::InitializePreprocessor() not put -include flags
in the <command line> block. This changes the behavior of -E slightly, and it
removes the <command line> flag from the output triggered by setting the
obscure CC_PRINT_HEADERS=1 env var to true while running clang. Both of these
seem ok to change.
http://reviews.llvm.org/D18401
llvm-svn: 264174
Currently when an AST plugin is loaded it must then be enabled by passing
-plugin pluginname or -add-plugin pluginname to the -cc1 command line. This
patch adds a method to PluginASTAction which allows it to declare that the
action happens before, instead of, or after the main AST action, plus the
relevant changes to make the plugin action happen at that time automatically.
Differential Revision: http://reviews.llvm.org/D17959
llvm-svn: 263546
Re-commit of r258950 after fixing layering violation.
The related LLVM patch adds a backend diagnostic type for reporting
unsupported features, this adds a printer for them to clang.
In the case where debug location information is not available, I've
changed the printer to report the location as the first line of the
function, rather than the closing brace, as the latter does not give the
user any information. This also affects optimisation remarks.
llvm-svn: 259499
Re-commit of r258950 after fixing layering violation.
Add backend dignostic printer for unsupported features
The related LLVM patch adds a backend diagnostic type for reporting
unsupported features, this adds a printer for them to clang.
In the case where debug location information is not available, I've
changed the printer to report the location as the first line of the
function, rather than the closing brace, as the latter does not give the
user any information. This also affects optimisation remarks.
Differential Revision: http://reviews.llvm.org/D16591
llvm-svn: 259036
The related LLVM patch adds a backend diagnostic type for reporting
unsupported features, this adds a printer for them to clang.
In the case where debug location information is not available, I've
changed the printer to report the location as the first line of the
function, rather than the closing brace, as the latter does not give the
user any information. This also affects optimisation remarks.
Differential Revision: http://reviews.llvm.org/D16591
llvm-svn: 258950
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
llvm-svn: 249655
Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).
This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247494
Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).
This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247465
Summary:
Do not include default sanitizer blacklists into -M/-MM/-MD/-MMD output.
Introduce a frontend option -fdepfile-entry, and only insert them
for the user-defined sanitizer blacklists. In frontend, grab ExtraDeps
from -fdepfile-entry, instead of -fsanitize-blacklist.
Reviewers: rsmith, pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12544
llvm-svn: 246700
The LLVM patch changes the analysis diagnostics produced when loops with
floating-point recurrences or memory operations are identified. The new messages
say "cannot prove it is safe to reorder * operations; allow reordering by
specifying #pragma clang loop vectorize(enable)". Depending on the type of
diagnostic the message will include additional options such as ffast-math or
__restrict__.
llvm-svn: 246189
Summary:
The default blacklists may vary across different architectures and
configurations. It was not wise to include into http://reviews.llvm.org/D11968
Reviewers: chapuni, pcc
Subscribers: cfe-commits, pcc
Differential Revision: http://reviews.llvm.org/D12021
llvm-svn: 244985
Summary:
Clang sanitizers, such as AddressSanitizer, ThreadSanitizer, MemorySanitizer,
Control Flow Integrity and others, use blacklists to specify which types / functions
should not be instrumented to avoid false positives or suppress known failures.
This change adds the blacklist filenames to the list of dependencies of the rules,
generated with -M/-MM/-MD/-MMD. This lets CMake/Ninja recognize that certain
C/C++/ObjC files need to be recompiled (if a blacklist is updated).
Reviewers: pcc
Subscribers: rsmith, honggyu.kim, pcc, cfe-commits
Differential Revision: http://reviews.llvm.org/D11968
llvm-svn: 244867
This patche and a related llvm patch solve the problem of having to explicitly enable analysis when specifying a loop hint pragma to get the diagnostics. Passing AlwasyPrint as the pass name (see below) causes the front-end to print the diagnostic if the user has specified '-Rpass-analysis' without an '=<target-pass>’. Users of loop hints can pass that compiler option without having to specify the pass and they will get diagnostics for only those loops with loop hints.
llvm-svn: 244556
Following one of the appended options will allow the loop to be vectorized. We do not include a command line option for modifying the pointer checking threshold because there is no clang-level interface for this currently.
llvm-svn: 244526
With this patch clang appends the command line options that would allow vectorization when floating-point commutativity is required. Specifically those are enabling fast-math or specifying a loop hint.
llvm-svn: 244492
This patch adds ObjectFilePCHContainerOperations uses the LLVM backend
to put the contents of a PCH into a __clangast section inside a COFF, ELF,
or Mach-O object file container.
This is done to facilitate module debugging by makeing it possible to
store the debug info for the types defined by a module alongside the AST.
rdar://problem/20091852
llvm-svn: 241620
Summary:
The goal of this patch is to make `-verify` easier to use when testing libc++. The `notes` attached to compile error diagnostics are numerous and relatively unstable when they reference libc++ header internals. This patch allows libc++ to write stable compilation failure tests by allowing unexpected diagnostic messages to be ignored where they are not relevant.
This patch adds a new CC1 flag called `-verify-ignore-unexpected`. `-verify-ignore-unexpected` tells `VerifyDiagnosticsConsumer` to ignore *all* unexpected diagnostic messages. `-verify-ignore-unexpected=<LevelList>` can be used to only ignore certain diagnostic levels. `<LevelList>` is a comma separated list of diagnostic levels to ignore. The supported levels are `note`, `remark`, `warning` and `error`.
Reviewers: bogner, grosser, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10138
llvm-svn: 239665
The test passing was dependent upon your source tree being checked out
in a directory with a long enough path, to cause the diagnostics to
wrap at the expected locations.
Use stdin instead, so that the error messages consistently use
<stdin> as the filename, and get wrapped consistently.
llvm-svn: 239009
In -fdelayed-template-parsing mode, templates that aren't used are not parsed
at all. For some diagnostic plugins, this is a problem since they want to
analyse the contents of the template function body. What has been suggested
on cfe-dev [1] is to explicitly parse interesting templates in
HandleTranslationUnit(); IWYU does this for example [2].
This is workable, but since the delayed parsing doesn't run below a call to
ParseTopLevelDecl(), no DestroyTemplateIdAnnotationsRAIIObj object is on the
stack to clean up TemplateIds that are created during parsing. To fix this,
let ~Parser() clean them up in delayed template parsing mode instead of
leaking (or asserting in +Assert builds).
(r219810, relanded in r220400, fixed the same problem in incremental processing
mode; the review thread of r219810 has a good discussion of the problem.)
To test this, give the PrintFunctionNames plugin a flag to force parsing
of a template and add a test that uses it in -fdelayed-template-parsing mode.
Without the Parser.cpp change, that test asserts.
1: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-August/038415.html
2: https://code.google.com/p/include-what-you-use/source/detail?r=566
llvm-svn: 237531
Backslash followed by # in a filename should have both characters
escaped, if you do it the way GNU Make wants. GCC doesn't, so we do
it the way GCC does rather than the way GNU Make wants.
llvm-svn: 237304
Previously we were setting LangOptions::GNUInline (which controls whether we
use traditional GNU inline semantics) if the language did not have the C99
feature flag set. The trouble with this is that C++ family languages also
do not have that flag set, so we ended up setting this flag in C++ modes
(and working around it in a few places downstream by also checking CPlusPlus).
The fix is to check whether the C89 flag is set for the target language,
rather than whether the C99 flag is cleared. This also lets us remove most
CPlusPlus checks. We continue to test CPlusPlus when deciding whether to
pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC.
There is a change in semantics in two other places
where we weren't checking both CPlusPlus and GNUInline
(FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and
FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to
put us back into line with GCC's semantics (test case: test/CodeGen/inline.c).
While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it,
it didn't have any effect before, and supporting it just makes things more
complicated.
Differential Revision: http://reviews.llvm.org/D9333
llvm-svn: 237299
When writing a dependency (.d) file, if space or # is immediately
preceded by one or more backslashes, escape the backslashes as well as
the space or # character. Otherwise leave backslash alone.
This straddles the fence between BSD Make (which does no escaping at
all, and does not support space or # in filespecs) and GNU Make (which
does support escaping, but will fall back to the filespec as-written
if the escaping doesn't match an existing file).
Differential Revision: http://reviews.llvm.org/D9208
llvm-svn: 237296
NMake is a Make-like builder that comes with Microsoft Visual Studio.
Jom (https://wiki.qt.io/Jom) is an NMake-compatible build tool.
Dependency files for NMake/Jom need to use double-quotes to wrap
filespecs containing special characters, instead of the backslash
escapes that GNU Make wants.
Adds the -MV option, which specifies to use double-quotes as needed
instead of backslash escapes when writing the dependency file.
Differential Revision: http://reviews.llvm.org/D9260
llvm-svn: 235903
Modules and Tooling tests in particular tend to want to change the cwd,
so we were missing test coverage in this area on Windows. It should now
be easier to write such portable tests.
llvm-svn: 231029
The test wants to provoke a failure when opening the output file.
Using chmod 0 on the output file does not work reliably on all
filesystems or when running the test as root.
Change the test to use a nonexistant directory instead.
Differential Revision: http://reviews.llvm.org/D7620
llvm-svn: 231009
Currently -fms-extensions controls this behavior, which doesn't make
much sense. It means we can't identify what is and isn't a system header
when compiling our own preprocessed output, because #line doesn't
represent this information.
If someone is feeding Clang's preprocessed output to another compiler,
they can use this flag.
Fixes PR20553.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D5217
llvm-svn: 230587
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
This reapplies r230044 with a fixed configure+make build and updated
dependencies and testcase requirements. Over the last iteration this
version adds
- missing target requirements for testcases that specify an x86 triple,
- a missing clangCodeGen.a dependency to libClang.a in the make build.
rdar://problem/19104245
llvm-svn: 230423
Previously the test did not have a RUN: prefix for the clang command.
In addition it was leaving behind a tmp file with no permissions causing issues when
deleting the build directory on Windows.
Differential Revision: http://reviews.llvm.org/D7534
llvm-svn: 228919
Summary:
Now that the darwin-version tests in Driver and Frontend are
testing different parts of the version encoding instead of doing
duplicated work
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D7134
llvm-svn: 228159
If there are some non-ascii character in the input source code, the
column index might be smallar than the byte index. This will result
in two possible assertion failures. This CL fixes the computation of
the column index and byte index.
1. The assertion in startOfNextColumn() and startOfPreviousColumn()
should not be raised when the byte index is greater than the column
index since the non-ascii characters may use more than one bytes to
store a character in a column.
2. The length of the caret line should be equal to the number of columns
of source line, instead of the length of the source line. Otherwise,
the assertion in selectInterestingSourceRegion will be raised because
the removed columns plus the kept columns are not greater than the max
column, which means that we should not remove any column at all.
llvm-svn: 225442
-trigraphs is now an alias for -ftrigraphs. -fno-trigraphs makes it possible
to explicitly disable trigraphs, which couldn't be done before.
clang -std=c++11 -fno-trigraphs
now builds without GNU extensions, but with trigraphs disabled. Previously,
trigraphs were only disabled in GNU modes or with -std=c++1z.
Make the new -f flags the cc1 interface too. This requires changing -trigraphs
to -ftrigraphs in a few cc1 tests.
Related to PR21974.
llvm-svn: 224790
The default value of Opts.Trigraphs now no longer depends solely on the
language input kind, so move the code out of setLangDefaults(). Also make
sure that Opts.MSVCCompat is set before the Trigraph code runs.
Related to PR21974.
llvm-svn: 224719
Add a comment and a test to ~DiagnosticEngine about the ordering
requirements on the teardown of DiagnosticConsumer. This could also be
accomplished by rearranging the fields of ~DiagnosticEngine, but I felt
that this was a better, more explicit solution.
This fixes PR21911, an issue that occurred after the unique_ptr
migration in r222193.
llvm-svn: 224454
Eric Christopher