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
basic microarchitecture names, and add support (with tests) for parsing
all of the masic microarchitecture names for CPUs documented to be
accepted by GCC with -march. I didn't go back through the 32-bit-only
old microarchitectures, but this at least brings the recent architecture
names up to speed. This is essentially the follow-up to the LLVM commit
r223769 which did similar cleanups for the LLVM CPUs.
One particular benefit is that you can now use -march=westmere in Clang
and get the LLVM westmere processor which is a different ISA variant (!)
and so quite significant.
Much like with r223769, I would appreciate the Intel folks carefully
thinking about the macros defined, names used, etc for the atom chips
and newest primary x86 chips. The current patterns seem quite strange to
me, especially here in Clang.
Note that I haven't replicated the per-microarchitecture macro defines
provided by GCC. I'm really opposed to source code using these rather
than using ISA feature macros.
llvm-svn: 223776
Summary:
When using a profile, we used to require the use -gmlt so that we could
get access to the line locations. This is used to match line numbers in
the input profile to the line numbers in the function's IR.
But this is actually not necessary. The driver can provide source
location tracking without the emission of debug information. In these
cases, the annotation 'llvm.dbg.cu' is missing from the IR, but the
actual line location annotations are still present.
This patch tells the driver to only emit source location tracking
when -fprofile-sample-use is present in the command line.
Reviewers: echristo, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5888
llvm-svn: 220383
According to the gcc docs, -include uses the current working directory
for the lookup instead of the main source file.
This patch gets rid of NormalizeIncludePath (which relied on an
implementation detail of FileManager / FileEntry for the include path
logic to work), and instead hands the correct lookup information down to
LookupFile.
This will allow us to change the FileEntry's behavior regarding its Name
caching.
llvm-svn: 215433
The previous encoding only allowed a single digit for the minor version
number. This changes it to use 2 digits for both the minor version and the
revision number.
llvm-svn: 215245
intent when we added remark support, but was never implemented in the general
case, because the first -R flags didn't need it. (-Rpass= had special handling
to accomodate its argument.)
-Rno-foo, -Reverything, and -Rno-everything can be used to turn off a remark,
or to turn on or off all remarks. Per discussion on cfe-commits, -Weverything
does not affect remarks, and -Reverything does not affect warnings or errors.
The only "real" -R flag we have right now is -Rmodule-build; that flag is
effectively renamed from -Wmodule-build to -Rmodule-build by this change.
-Wpass and -Wno-pass (and their friends) are also renamed to -Rpass and
-Rno-pass by this change; it's not completely clear whether we intended to have
a -Rpass (with no =pattern), but that is unchanged by this commit, other than
the flag name. The default pattern is effectively one which matches no passes.
In future, we may want to make the default pattern be .*, so that -Reverything
works for -Rpass properly.
llvm-svn: 215046
We've decided to make the core rewriter class and PP rewriters mandatory.
They're only a few hundred lines of code in total and not worth supporting as a
distinct build configuration, especially since doing so disables key compiler
features.
This reverts commit r213150.
Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter."
This reverts commit r213148.
Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/"
This reverts commit r213146.
llvm-svn: 213159
We don't have a style guide for diagnostic messages, but convention strongly
favours the forms:
'attribute is not supported', 'unsupported attribute'
We generally avoid:
'attribute is unsupported', 'non-supported attribute'
llvm-svn: 212972
Allow diagnostic checks that originate in included files to be matched without necessarily determining the line number that the diagnostic occurs on. The new syntax replaces the line number with '*'. This extension is limited to diagnostics in included files and may be used where the include file is not part of the test-suite itself.
Expected uses are for diagnostics originating in system headers, or for users who use -verify in testing 3rd-party library code where the location of diagnostics in header files may change from revision to revision and their precise location is not important to the success of the test-case.
llvm-svn: 212735
At least this answers the question of whether .bc/.ll input processed by the
frontend produces identical output to the original compilation.
llvm-svn: 211853
Test that we can consume LLVM bitcode and additionally check that it produces
the same output as a direct compilation.
The feature is crashy and has gone untested until now, but we might as well
provide some coverage as long as it remains in tree.
Also test LL source input in the same way because the existing tests for that
don't look convincing.
llvm-svn: 211844
With LocTrackingOnly there's no longer a user-facing distinction so the NDEBUG
checks can go away. (Except maybe column info, but -verify only checks line
numbers anyway.)
Also add a RUN line to validate the traditional !LocTrackingOnly case.
llvm-svn: 211622
Summary:
This new debug emission kind supports emitting line location
information in all instructions, but stops code generation
from emitting debug info to the final output.
This mode is useful when the backend wants to track source
locations during code generation, but it does not want to
produce debug info. This is currently used by optimization
remarks (-Rpass, -Rpass-missed and -Rpass-analysis).
When one of the -Rpass flags is used, the front end will enable
location tracking, only if no other debug option is enabled.
To prevent debug information from being generated, a new debug
info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to
not emit the llvm.dbg.cu annotation. This blocks final code generation
from generating debug info in the back end.
Depends on D4234.
Reviewers: echristo, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4235
llvm-svn: 211610
It turns out the trailing '=' really is part of the option name spelling and
treating it as such gets us compatible with GCC's -Werror= and pragmas.
(GCC doesn't appear to support any -Wno- form for this diagnostic but we do.)
llvm-svn: 210503
A leftover -S was generating unwanted output in the source tree overriding
-only flags that normally disable output.
This reverts commit r210323 and implements the proper fix.
Reported by Timur Iskhodzhanov!
llvm-svn: 210326
Instead of disembodied diagnostics when debug info is disabled it's now
possible to identify the associated function's location in order to provide
some amount of of context.
We use the definition's body right brace location to differentiate the fallback
from diagnostics that genuinely relate to the function declaration itself (a
convention also used by gcc).
llvm-svn: 210294
Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning.
This is the first GCC-compatible backend diagnostic built around LLVM's
reporting feature.
This commit adds infrastructure to perform reverse lookup from mangled names
emitted after LLVM IR generation. We use that to resolve precise locations and
originating AST functions, lambdas or block declarations to produce seamless
codegen-guided diagnostics.
An associated change, StringMap now maintains unique mangled name strings
instead of allocating copies. This is a net memory saving in C++ and a small
hit for C where we no longer reuse IdentifierInfo storage, pending further
optimisation.
llvm-svn: 210293
Summary:
These two flags are in the same family as -Rpass, but are used in
different situations.
-Rpass-missed is used by optimizers to inform the user when they tried
to apply an optimization but couldn't (or wouldn't).
-Rpass-analysis is used by optimizers to report analysis results back
to the user (e.g., why the transformation could not be applied).
Depends on D3682.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3683
llvm-svn: 209839
With -Weverything, the backend remarks are enabled. This was
causing spurious diagnostics for remarks that we don't yet
handle (cf http://reviews.llvm.org/D3683).
This will stop being a problem once http://reviews.llvm.org/D3683
is committed.
llvm-svn: 209823
Summary:
When using #line directives, FileManager::getFile() will return a nil
entry. This triggers an assert in translateFileLineCol().
This patch handles nil FileEntry instances by emitting a note that the
location could not be translated back to a SourceLocation. I don't
really like this solution, but we are translating presumed locations,
so some information has already been lost.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3625
llvm-svn: 208315
Enclosing the original #include directive inside #if 0 adds lines,
so warning/errors messages would have the line number off in
"In file included from <file>:<line>:", so add line marker to fix this.
llvm-svn: 207795
"1" means entering a new file (from a different one), but the main
file is not included from anything (and this would e.g. confuse -Wunused-macros
to not report unused macros in the main file, see pr15610, or also see pr18948).
The line marker is still useful e.g. if the resulting file is renamed or used
via a pipe.
llvm-svn: 207764
There's nothing wrong with the change itself, but
test/Frontend/rewrite-includes-messages.c fails without another
not-yet-committed fix.
llvm-svn: 207762
Enclosing the original #include directive inside #if 0 adds lines,
so warning/errors messages would have the line number off in
"In file included from <file>:<line>:", so add line marker to fix this.
llvm-svn: 207756
crash with an assertion failure when 'nul' is passed in input.
Modified clang/test/lit.py to add feature 'system-windows' if
`platform.system()` returns 'Windows'.
llvm-svn: 207576
Summary:
This allows callers of Diags.Report() to append a value to the name of
the flag associated with the diagnostic. This is useful in cases like
the -Rpass flag, where we want the diagnostic to show the name of the
pass that matched the pattern. Instead of showing "... [-Rpass]", this
allows us to show "... [-Rpass=passname]".
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D3441
llvm-svn: 206826
Summary:
This patch adds a new flag -Rpass=. The flag indicates the name
of the optimization pass that should emit remarks stating when it
made a transformation to the code.
This implements the design I proposed in:
https://docs.google.com/document/d/1FYUatSjZZO-zmFBxjOiuOzAy9mhHA8hqdvklZv68WuQ/edit?usp=sharing
Other changes:
- Add DiagnosticIDs::isRemark(). Use it in printDiagnosticOptions to
print "-R" instead of "-W" in the diagnostic message.
- In BackendConsumer::OptimizationRemarkHandler, get a SourceLocation
object out of the file name, line and column number. Use that location
in the call to Diags.Report().
- When -Rpass is used without debug info a note is emitted alerting
the user that they need to use -gline-tables-only -gcolumn-info to
get this information.
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3226
llvm-svn: 206401
Summary:
This allows them to be used without -cc1 the same way as -I and -isystem.
Renamed the options to --system-header-prefix=/--no-system-header-prefix to avoid interference with -isystem and make the intent of the option cleaner.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3185
llvm-svn: 204775
Summary:
AsmPrinter::EmitInlineAsm() will no longer use the EmitRawText() call for
targets with mature MC support. Such targets will always parse the inline
assembly (even when emitting assembly). Targets without mature MC support
continue to use EmitRawText() for assembly output.
The hasRawTextSupport() check in AsmPrinter::EmitInlineAsm() has been replaced
with MCAsmInfo::UseIntegratedAs which when true, causes the integrated assembler
to parse inline assembly (even when emitting assembly output). UseIntegratedAs
is set to true for targets that consider any failure to parse valid assembly
to be a bug. Target specific subclasses generally enable the integrated
assembler in their constructor. The default value can be overridden with
-no-integrated-as.
All tests that rely on inline assembly supporting invalid assembly (for example,
those that use mnemonics such as 'foo' or 'hello world') have been updated to
disable the integrated assembler.
Changes since review (and last commit attempt):
- Fixed test failures that were missed due to configuration of local build.
(fixes crash.ll and a couple others).
- Fixed tests that happened to pass because the local build was on X86
(should fix 2007-12-17-InvokeAsm.ll)
- mature-mc-support.ll's should no longer require all targets to be compiled.
(should fix ARM and PPC buildbots)
- Object output (-filetype=obj and similar) now forces the integrated assembler
to be enabled regardless of default setting or -no-integrated-as.
(should fix SystemZ buildbots)
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2686
llvm-svn: 201333
e.g. thumbv7m-apple-ios3.0.0-eabi, then it should mean it's an iOS target. For
embedded targets, the OS should be unknown, e.g. thumbv7m-apple-unknown-macho.
Since Tim has recently fixed the triple, r195149 is no longer needed.
rdar://15911035
llvm-svn: 200164
Somehow the entire plugin infrastructure went wholly untested until now.
The only plugins available for use in testing are the examples, so plugin tests
will only be run if CLANG_BUILD_EXAMPLES is enabled in the build.
(The examples should really be enabled by default, not just to aid testing but
also to prevent bitrot in some key user-facing code. I'll propose that
shortly.)
Requires supporting changes in LLVM r198746.
llvm-svn: 198747
This matches llc's behavior.
Before this patch clang would create a TargetInfo base on -triple but a llvm
CodeGen based on the triple in the module.
llvm-svn: 197837
'not' on Windows tries and fails to convert the argument to UTF-16 and back for
some reason:
Error: Unable to convert command-line to UTF-16
Let's try replacing it with !.
(There was no obvious way to do these with FileCheck)
llvm-svn: 195907
1) Use %clang_cc1 instead of the driver
2) Validate that the input contains a BOM
3) Validate that the BOM has been stripped from the output
llvm-svn: 195886
After r195009, the test would write a .o file to the test dir. Send that to
/dev/null instead. Also fix the typo in test/Frontend/invalid-o-level.c.
llvm-svn: 195047
Summary:
Currently with clang:
$ clang -O20 foo.c
error: invalid value '20' in '-O20'
With the patch:
$ clang -O20 foo.c
warning: optimization level '-O20' is unsupported; using '-O3' instead.
1 warning generated.
This matches the gcc behavior (with a warning added)
Pass all tests:
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 94.14s
Expected Passes : 6721
Expected Failures : 20
Unsupported Tests : 17
(which was not the case of http://llvm-reviews.chandlerc.com/D2125)
Differential Revision: http://llvm-reviews.chandlerc.com/D2212
llvm-svn: 195009
clang -cc1 skips the driver so it never made sense to include these with the
Driver tests.
Basic type tests and flag tests generally both go in Frontend.
Now that the final -cc1 tests have been moved out of test/Driver, add a
local substitution to enforce and detect future mistakes.
These miscategorized tests were probably the source of confusion in r194817.
llvm-svn: 194919
By adding a default config.excludes pattern we can avoid individual
suppressions in subdirectories.
This matches LLVM's lit.cfg which also excludes a few other common non-test
filenames for consistency.
llvm-svn: 194814
The original idea was to implement it all on the driver, but to do that the
driver needs to know the sse level and to do that it has to know the default
features of a cpu.
Benjamin Kramer pointed out that if one day we decide to implement support for
' __attribute__ ((__target__ ("arch=core2")))', then the frontend needs to
keep its knowledge of default features of a cpu.
To avoid duplicating which part of clang handles default cpu features,
it is probably better to handle -mfpmath in the frontend.
For ARM this patch is just a small improvement. Instead of a cpu list, we
check if neon is enabled, which allows us to reject things like
-mcpu=cortex-a9 -mfpu=vfp -mfpmath=neon
For X86, since LLVM doesn't support an independent ssefp feature, we just
make sure the selected -mfpmath matches the sse level.
llvm-svn: 188939
This option prints information about #included files to stderr. Clang could
already do it, this patch just teaches the existing code about the /showIncludes
style and adds the flag.
Differential Revision: http://llvm-reviews.chandlerc.com/D1333
llvm-svn: 188037
Every #include is surrounded by #if 0 in order to comment it out, which adds
lines. That is fixed up right after, but that all can be inside #if part
that is not processed, so fix up also after every end of a conditional part.
llvm-svn: 186763
* Use a single stat to find out if the file exists and if it is a regular file.
* Use early returns when possible.
* Add comments explaining why we have each check.
llvm-svn: 185091
VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same source file. Common practice was
to create directives that referenced other files but only by line number,
and this led to problems such as when the file containing the directive
didn't have enough lines to match the location of the diagnostic in the
other file, leading to bizarre file formatting and other oddities.
This patch causes VerifyDiagnosticConsumer to match source files as well as
line numbers. Therefore, a new syntax is made available for directives, for
example:
// expected-error@file:line {{diagnostic message}}
This extends the @line feature where "file" is the file where the diagnostic
is generated. The @line syntax is still available and uses the current file
for the diagnostic. "file" can be specified either as a relative or absolute
path - although the latter has less usefulness, I think! The #include search
paths will be used to locate the file and if it is not found an error will be
generated.
The new check is not optional: if the directive is in a different file to the
diagnostic, the file must be specified. Therefore, a number of test-cases
have been updated with regard to this.
This closes out PR15613.
llvm-svn: 179677
This broke e.g. compiling a crash report from a glibc system on Darwin. Sadly,
the implementation had to game the lexer a lot as we're not using a real
preprocessor here. It also doesn't handle special cases like arbitrary macros in
__has_include, but since this macro isn't common outside of clang's headers we
can get away with that.
Fixes PR14422.
Differential Revision: http://llvm-reviews.chandlerc.com/D594
llvm-svn: 179616
warning options to setup diagnostic state, but should not be emitting warnings as these would be
rudndant with what the frontend emits.
rdar://13001556
llvm-svn: 172497
will be represented in the IR as a plain "i32" type. This causes the
tests to spuriously fail on platforms where int is not a 32-bit type,
or where the ABI requires attributes like "signext" or "zeroext" to
be used.
This patch adds -triple or -target parameters to force those tests
to use the i386-unknown-unknown target.
llvm-svn: 166551
This change was initially proposed as a solution to the problem highlighted by check-in r164677, i.e. that -verify will not cause a test-case failure where the compile command does not actually reference the file.
Patch reviewed by David Blaikie.
llvm-svn: 166281
The old behavior was to re-scan any files (like modules) where we may have
directives but won't actually be parsing during the -verify invocation.
Now, we keep the old behavior in Debug builds as a sanity check (though
modules are a known entity), and expect all legitimate directives to come
from comments seen by the preprocessor.
This also affects the ARC migration tool, which captures diagnostics in
order to filter some out. This change adds an explicit cleanup to
CaptureDiagnosticsConsumer in order to let its sub-consumer handle the
real end of diagnostics.
This was originally split into four patches, but the tests do not run
cleanly without all four, so I've combined them into one commit.
Patches by Andy Gibbs, with slight modifications from me.
llvm-svn: 161650
This is accomplished by making VerifyDiagnosticsConsumer a CommentHandler,
which then only reads the -verify directives that are actually in live
blocks of code. It also makes it simpler to handle -verify directives that
appear in header files, though we still have to manually reparse some files
depending on how they are generated.
This requires some test changes. In particular, all PCH tests now have their
-verify directives outside the "header" portion of the file, using the @line
syntax added in r159978. Other tests have been modified mostly to make it
clear what is being tested, and to prevent polluting the expected output with
the directives themselves.
Patch by Andy Gibbs! (with slight modifications)
The new Frontend/verify-* tests exercise the functionality of this commit,
as well as r159978, r159979, and r160053 (Andy's other -verify enhancements).
llvm-svn: 160068
override whether headers are system headers by checking for prefixes of the
header name specified in the #include directive.
This allows warnings to be disabled for third-party code which is found in
specific subdirectories of include paths.
llvm-svn: 158418
% is a common character in IR so we'd crash on almost any malformed IR. The
diagnostic formatter expects a formatting directive when it sees an unescaped %.
llvm-svn: 152956
This option was added in r129614 and doesn't have any use case that I'm aware
of. It's possible that external tools are using these names - and if that's
the case we can certainly reassess the functionality, but for now it lets us
shave out a few unneeded bits from clang.
Move the "StaticDiagNameIndex" table into the only remaining consumer, diagtool.
This removes the actual diagnostic name strings from clang entirely.
Reviewed by Chris Lattner & Ted Kremenek.
llvm-svn: 150612
the command line options (at least according to GCC's documentation). GCC 4.2
didn't appear to actually do this, but it seems like that has been fixed in
later release, so we will follow the docs.
llvm-svn: 141119
- This fixes a host of obscure bugs with regards to how warning mapping options composed with one another, and I believe makes the code substantially easier to read and reason about.
llvm-svn: 140770
- The TextDiagnosticPrinter code is still fragile as it is just "reverse engineering" what the diagnostic engine is doing. Not my current priority to fix though.
llvm-svn: 140752
Adrian Prantl