One way to currently test the reproducers is to setup
"FORCE_CLANG_DIAGNOSTICS_CRASH=1" before invoking clang. This simulates
a crash and produces the same contents needed by the reproducers.  The
reproducers are specially useful when triaging Modules issues, not only
on crashes, but also for reproducing misleading warnings, errors, etc.

Add a '-gen-reproducer' driver option to clang (or any similar name) and
give users a flag option.

Note that clang already has a -fno-crash-diagnostics, which disables the
crash reproducers. I've decided not to propose "-fcrash-diagnostics"
since it doesn't convey the ideia of reproduction despite a crash.

rdar://problem/24114619

Differential Revision: https://reviews.llvm.org/D27604

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300109 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295433 91177308-0d34-0410-b5e6-96231b3b80d8

Added description of a new feature that allows to specify
vendor extension in flexible way using compiler pragma instead
of modifying source code directly (committed in clang@r289979).

Review: D29829



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295313 91177308-0d34-0410-b5e6-96231b3b80d8

Added "-fdebug-macro" flag (and "-fno-debug-macro" flag) to enable (and to disable) emitting macro debug info.
Added CC1 "-debug-info-macro" flag that enables emitting macro debug info.

Differential Revision: https://reviews.llvm.org/D16135

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294637 91177308-0d34-0410-b5e6-96231b3b80d8

NFC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293877 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292265 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292115 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Add missing flag to UsersManual
It would be good to merge it to 4.0 branch.

Reviewers: hans

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D28727

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292112 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292015 91177308-0d34-0410-b5e6-96231b3b80d8

This time, make ignored options, such as /utf-8, show up as well if they
have help text.

Also, since we're now exposing -fdelayed-template-parsing, add help text
to the -fno version so that shows up as well.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291798 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291783 91177308-0d34-0410-b5e6-96231b3b80d8

Updated index and UsersManual with OpenCL description.

Review: https://reviews.llvm.org/D28080 



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291780 91177308-0d34-0410-b5e6-96231b3b80d8

This was accidentally removed in r260506, even though we only support
non-allocatable global register variables. The general (allocatable) case
is explicitly not supported.

Differential Revision: https://reviews.llvm.org/D27473


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289455 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285341 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281293 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r281276.

Many bots are failing.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281279 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281276 91177308-0d34-0410-b5e6-96231b3b80d8

remark flags. For now I'm checking in a copy of the built documentation, but we
can replace this with a placeholder (as we do for the attributes reference
documentation) once we enable building this server-side.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281192 91177308-0d34-0410-b5e6-96231b3b80d8

to CC1, which are translated to function attributes and can e.g. be mapped on
build attributes FP_exceptions and FP_denormal. Setting these build attributes
allows better selection of floating point libraries.

Differential Revision: https://reviews.llvm.org/D23840


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280064 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278710 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276891 91177308-0d34-0410-b5e6-96231b3b80d8

This patch enables raw profile merging for this option which is the
new intended behavior.




git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276484 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: http://reviews.llvm.org/D22593




git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276207 91177308-0d34-0410-b5e6-96231b3b80d8

The flags:
Enable IR-level instrumentation -fprofile-generate or -fprofile-generate=
When applying profile data: -fprofile-use=/path/to/profdata

Patch by Jake VanAdrighem!

Differential Revision: https://reviews.llvm.org/D21823

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275668 91177308-0d34-0410-b5e6-96231b3b80d8

Removing a few more :option: tags that we do not have corresponding .. option directives for; these are causing the sphinx bot to fail (http://lab.llvm.org:8011/builders/clang-sphinx-docs/builds/15214/steps/docs-clang-html/logs/stdio).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275560 91177308-0d34-0410-b5e6-96231b3b80d8

Removing a few more :option: tags that we do not have corresponding .. option directives for; these are causing the sphinx bot to fail (http://lab.llvm.org:8011/builders/clang-sphinx-docs/builds/15213/steps/docs-clang-html/logs/stdio).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275558 91177308-0d34-0410-b5e6-96231b3b80d8

Despite there being an option, it seems that Sphinx has decided that "=123" is part of the option directive name, and so having "=0" in the option tag is problematic. Since the option tag is part of the option directive definition, it's superfluous, and so I've removed it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275440 91177308-0d34-0410-b5e6-96231b3b80d8

A number of warnings still remain, but these were the last of the
"unlexable code"-related ones (AFAICT).

I changed a few examples in docs/UsersManual.rst to showcase
-Wextra-tokens because it's already documented (-Wmultichar isn't), and
the sphinx C lexer apparently can't handle char literals like 'ab'. It
seemed like a better overall approach than just marking the code blocks
as none or console.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273232 91177308-0d34-0410-b5e6-96231b3b80d8

This patch adds the commandline option -mcompact-branches={never,optimal,always),
which controls how LLVM generates compact branches for MIPSR6 targets. By default,
the compact branch policy is 'optimal' where LLVM will generate the most
appropriate branch for any situation. The 'never' and 'always' policy will disable
or always generate compact branches wherever possible respectfully.

Reviewers: dsanders, vkalintiris, atanasyan

Differential Revision: http://reviews.llvm.org/D20729


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271000 91177308-0d34-0410-b5e6-96231b3b80d8

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D20457

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270279 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268541 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268540 91177308-0d34-0410-b5e6-96231b3b80d8

I have updated the compiler-rt tests.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267903 91177308-0d34-0410-b5e6-96231b3b80d8

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."

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267871 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267784 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264651 91177308-0d34-0410-b5e6-96231b3b80d8

This patch introduces the -fwhole-program-vtables flag, which enables the
whole-program vtable optimization feature (D16795) in Clang.

Differential Revision: http://reviews.llvm.org/D16821

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261767 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260637 91177308-0d34-0410-b5e6-96231b3b80d8

After some experiments I discovered that clang doesn't support static
initialization of flexible array members in full, so restored this paragraph in
"GCC extensions not implemented yet" list.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260519 91177308-0d34-0410-b5e6-96231b3b80d8

#pragma weak, global register variables and static initialization of flexible
array members are supported now, so they are removed from "GCC extensions not
implemented yet" list.

Differential Revision: http://reviews.llvm.org/D16851


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260506 91177308-0d34-0410-b5e6-96231b3b80d8