[analyzer] Analysis: Silence checkers

Summary:
This patch introduces a new `analyzer-config` configuration:
`-analyzer-config silence-checkers`
which could be used to silence the given checkers.

It

[analyzer] Analysis: Silence checkers

Summary:
This patch introduces a new `analyzer-config` configuration:
`-analyzer-config silence-checkers`
which could be used to silence the given checkers.

It accepts a semicolon separated list, packed into quotation marks, e.g:
`-analyzer-config silence-checkers="core.DivideZero;core.NullDereference"`

It could be used to "disable" core checkers, so they model the analysis as
before, just if some of them are too noisy it prevents to emit reports.

This patch also adds support for that new option to the scan-build.
Passing the option `-disable-checker core.DivideZero` to the scan-build
will be transferred to `-analyzer-config silence-checkers=core.DivideZero`.

Reviewed By: NoQ, Szelethus

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

llvm-svn: 369078

show more ...

cfi-icall: Allow the jump table to be optionally made non-canonical.

The default behavior of Clang's indirect function call checker will replace
the address of each CFI-checked function in the outpu

cfi-icall: Allow the jump table to be optionally made non-canonical.

The default behavior of Clang's indirect function call checker will replace
the address of each CFI-checked function in the output file's symbol table
with the address of a jump table entry which will pass CFI checks. We refer
to this as making the jump table `canonical`. This property allows code that
was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address
of a function, but it comes with a couple of caveats that are especially
relevant for users of cross-DSO CFI:

- There is a performance and code size overhead associated with each
exported function, because each such function must have an associated
jump table entry, which must be emitted even in the common case where the
function is never address-taken anywhere in the program, and must be used
even for direct calls between DSOs, in addition to the PLT overhead.

- There is no good way to take a CFI-valid address of a function written in
assembly or a language not supported by Clang. The reason is that the code
generator would need to insert a jump table in order to form a CFI-valid
address for assembly functions, but there is no way in general for the
code generator to determine the language of the function. This may be
possible with LTO in the intra-DSO case, but in the cross-DSO case the only
information available is the function declaration. One possible solution
is to add a C wrapper for each assembly function, but these wrappers can
present a significant maintenance burden for heavy users of assembly in
addition to adding runtime overhead.

For these reasons, we provide the option of making the jump table non-canonical
with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump
table is made non-canonical, symbol table entries point directly to the
function body. Any instances of a function's address being taken in C will
be replaced with a jump table address.

This scheme does have its own caveats, however. It does end up breaking
function address equality more aggressively than the default behavior,
especially in cross-DSO mode which normally preserves function address
equality entirely.

Furthermore, it is occasionally necessary for code not compiled with
``-fsanitize=cfi-icall`` to take a function address that is valid
for CFI. For example, this is necessary when a function's address
is taken by assembly code and then called by CFI-checking C code. The
``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make
the jump table entry of a specific function canonical so that the external
code will end up taking a address for the function that will pass CFI checks.

Fixes PR41972.

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

llvm-svn: 368495

show more ...

[clang] Add no-warn support for Wa

llvm-svn: 368328

[OPENMP]Set default version to OpenMP 4.5.

Since clang fully supports OpenMP 4.5, set the default version to 4.5
instead of 3.1.

llvm-svn: 368172

Move LangStandard*, InputKind::Language to Basic

This patch is a prerequisite for using LangStandard from Driver in
https://reviews.llvm.org/D64793.

It moves LangStandard* and InputKind::Language t

Move LangStandard*, InputKind::Language to Basic

This patch is a prerequisite for using LangStandard from Driver in
https://reviews.llvm.org/D64793.

It moves LangStandard* and InputKind::Language to Basic. It is mostly
mechanical, with only a few changes of note:

- enum Language has been changed into enum class Language : uint8_t to
avoid a clash between OpenCL in enum Language and OpenCL in enum
LangFeatures and not to increase the size of class InputKind.

- Now that getLangStandardForName, which is currently unused, also checks
both canonical and alias names, I've introduced a helper getLangKind
which factors out a code pattern already used 3 times.

The patch has been tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11,
and x86_64-pc-linux-gnu.

There's a companion patch for lldb which uses LangStandard.h
(https://reviews.llvm.org/D65717).

While polly includes isl which in turn uses InputKind::C, that part of the
code isn't even built inside the llvm tree. I've posted a patch to allow
for both InputKind::C and Language::C upstream
(https://groups.google.com/forum/#!topic/isl-development/6oEvNWOSQFE).

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

llvm-svn: 367864

show more ...

Revert r367649: Improve raw_ostream so that you can "write" colors using operator<<

This reverts commit r367649 in an attempt to unbreak Windows bots.

llvm-svn: 367658

Improve raw_ostream so that you can "write" colors using operator<<

1. raw_ostream supports ANSI colors so that you can write messages to
the termina with colors. Previously, in order to change and

Improve raw_ostream so that you can "write" colors using operator<<

1. raw_ostream supports ANSI colors so that you can write messages to
the termina with colors. Previously, in order to change and reset
color, you had to call `changeColor` and `resetColor` functions,
respectively.

So, if you print out "error: " in red, for example, you had to do
something like this:

OS.changeColor(raw_ostream::RED);
OS << "error: ";
OS.resetColor();

With this patch, you can write the same code as follows:

OS << raw_ostream::RED << "error: " << raw_ostream::RESET;

2. Add a boolean flag to raw_ostream so that you can disable colored
output. If you disable colors, changeColor, operator<<(Color),
resetColor and other color-related functions have no effect.

Most LLVM tools automatically prints out messages using colors, and
you can disable it by passing a flag such as `--disable-colors`.
This new flag makes it easy to write code that works that way.

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

llvm-svn: 367649

show more ...

[OpenCL] Rename lang mode flag for C++ mode

Rename lang mode flag to -cl-std=clc++/-cl-std=CLC++
or -std=clc++/-std=CLC++.

This aligns with OpenCL C conversion and removes ambiguity
with OpenCL C++

[OpenCL] Rename lang mode flag for C++ mode

Rename lang mode flag to -cl-std=clc++/-cl-std=CLC++
or -std=clc++/-std=CLC++.

This aligns with OpenCL C conversion and removes ambiguity
with OpenCL C++.

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

llvm-svn: 367008

show more ...

[Support] Fix `-ftime-trace-granularity` option

Summary:
Move `-ftime-trace-granularity` option to frontend options. Without patch
this option is showed up in the help for any tool that links libSup

[Support] Fix `-ftime-trace-granularity` option

Summary:
Move `-ftime-trace-granularity` option to frontend options. Without patch
this option is showed up in the help for any tool that links libSupport.

Reviewers: sammccall

Subscribers: hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 366911

show more ...

[Clang] Replace cc1 options '-mdisable-fp-elim' and '-momit-leaf-frame-pointer'
with '-mframe-pointer'

After D56351 and D64294, frame pointer handling is migrated to tri-state
(all, non-leaf, none)

[Clang] Replace cc1 options '-mdisable-fp-elim' and '-momit-leaf-frame-pointer'
with '-mframe-pointer'

After D56351 and D64294, frame pointer handling is migrated to tri-state
(all, non-leaf, none) in clang driver and on the function attribute.
This patch makes the frame pointer handling cc1 option tri-state.

Reviewers: chandlerc, rnk, t.p.northover, MaskRay

Reviewed By: MaskRay

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

llvm-svn: 366645

show more ...

[PowerPC] Support -mabi=ieeelongdouble and -mabi=ibmlongdouble

gcc PowerPC supports 3 representations of long double:

* -mlong-double-64

long double has the same representation of double but is

[PowerPC] Support -mabi=ieeelongdouble and -mabi=ibmlongdouble

gcc PowerPC supports 3 representations of long double:

* -mlong-double-64

long double has the same representation of double but is mangled as `e`.
In clang, this is the default on AIX, FreeBSD and Linux musl.

* -mlong-double-128

2 possible 128-bit floating point representations:

+ -mabi=ibmlongdouble
IBM extended double format. Mangled as `g`
In clang, this is the default on Linux glibc.
+ -mabi=ieeelongdouble
IEEE 754 quadruple-precision format. Mangled as `u9__ieee128` (`U10__float128` before gcc 8.2)
This is currently unavailable.

This patch adds -mabi=ibmlongdouble and -mabi=ieeelongdouble, and thus
makes the IEEE 754 quadruple-precision long double available for
languages supported by clang.

Reviewed By: hfinkel

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

llvm-svn: 366044

show more ...

[X86][PowerPC] Support -mlong-double-128

This patch makes the driver option -mlong-double-128 available for X86
and PowerPC. The CC1 option -mlong-double-128 is available on all targets
for users to

[X86][PowerPC] Support -mlong-double-128

This patch makes the driver option -mlong-double-128 available for X86
and PowerPC. The CC1 option -mlong-double-128 is available on all targets
for users to test on unsupported targets.

On PowerPC, -mlong-double-128 uses the IBM extended double format
because we don't support -mabi=ieeelongdouble yet (D64283).

Reviewed By: rnk

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

llvm-svn: 365866

show more ...

[X86][PPC] Support -mlong-double-64

-mlong-double-64 is supported on some ports of gcc (i386, x86_64, and ppc{32,64}).
On many other targets, there will be an error:

error: unrecognized command

[X86][PPC] Support -mlong-double-64

-mlong-double-64 is supported on some ports of gcc (i386, x86_64, and ppc{32,64}).
On many other targets, there will be an error:

error: unrecognized command line option '-mlong-double-64'

This patch makes the driver option -mlong-double-64 available for x86
and ppc. The CC1 option -mlong-double-64 is available on all targets for
users to test on unsupported targets.

LongDoubleSize is added as a VALUE_LANGOPT so that the option can be
shared with -mlong-double-128 when we support it in clang.

Also, make powerpc*-linux-musl default to use 64-bit long double. It is
currently the only supported ABI on musl and is also how people
configure powerpc*-linux-musl-gcc.

Reviewed By: rnk

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

llvm-svn: 365412

show more ...

[analyzer] Add a debug analyzer config to place an event for each tracked condition

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

llvm-svn: 365208

[Driver] Fix style issues of --print-supported-cpus after D63105

Reviewed By: ziangwan

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

llvm-svn: 364704

[Clang] Remove unused -split-dwarf and obsolete -enable-split-dwarf

Summary:
The changes in D59673 made the choice redundant, since we can achieve
single-file split DWARF just by not setting an outp

[Clang] Remove unused -split-dwarf and obsolete -enable-split-dwarf

Summary:
The changes in D59673 made the choice redundant, since we can achieve
single-file split DWARF just by not setting an output file name.
Like llc we can also derive whether to enable Split DWARF from whether
-split-dwarf-file is set, so we don't need the flag at all anymore.

The test CodeGen/split-debug-filename.c distinguished between having set
or not set -enable-split-dwarf with -split-dwarf-file, but we can
probably just always emit the metadata into the IR.

The flag -split-dwarf wasn't used at all anymore.

Reviewers: dblaikie, echristo

Reviewed By: dblaikie

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

llvm-svn: 364479

show more ...

[CC1Option] Add the option to enable the debug entry values

The option enables debug info about parameter's entry values.

The example of using the option:

clang -g -O2 -Xclang -femit-debug-entry-v

[CC1Option] Add the option to enable the debug entry values

The option enables debug info about parameter's entry values.

The example of using the option:

clang -g -O2 -Xclang -femit-debug-entry-values test.c

In addition, when the option is set add the flag all_call_sites
in a subprogram in order to support GNU extension as well.

([3/13] Introduce the debug entry values.)

Co-authored-by: Ananth Sowda <asowda@cisco.com>
Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com>
Co-authored-by: Ivan Baev <ibaev@cisco.com>

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

llvm-svn: 364399

show more ...

[clang-ifs] Clang Interface Stubs, first version (second landing attempt).

This change reverts r363649; effectively re-landing r363626. At this point
clang::Index::CodegenNameGeneratorImpl has been

[clang-ifs] Clang Interface Stubs, first version (second landing attempt).

This change reverts r363649; effectively re-landing r363626. At this point
clang::Index::CodegenNameGeneratorImpl has been refactored into
clang::AST::ASTNameGenerator. This makes it so that the previous circular link
dependency no longer exists, fixing the previous share lib
(-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649.

Clang interface stubs (previously referred to as clang-ifsos) is a new frontend
action in clang that allows the generation of stub files that contain mangled
name info that can be used to produce a stub library. These stub libraries can
be useful for breaking up build dependencies and controlling access to a
library's internal symbols. Generation of these stubs can be invoked by:

clang -fvisibility=<visibility> -emit-interface-stubs \
-interface-stub-version=<interface format>

Notice that -fvisibility (along with use of visibility attributes) can be used
to control what symbols get generated. Currently the interface format is
experimental but there are a wide range of possibilities here.

Currently clang-ifs produces .ifs files that can be thought of as analogous to
object (.o) files, but just for the mangled symbol info. In a subsequent patch
I intend to add support for merging the .ifs files into one .ifs/.ifso file
that can be the input to something like llvm-elfabi to produce something like a
.so file or .dll (but without any of the code, just symbols).

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

llvm-svn: 363948

show more ...

[OpenCL] Split type and macro definitions into opencl-c-base.h

Using the -fdeclare-opencl-builtins option will require a way to
predefine types and macros such as `int4`, `CLK_GLOBAL_MEM_FENCE`,
etc

[OpenCL] Split type and macro definitions into opencl-c-base.h

Using the -fdeclare-opencl-builtins option will require a way to
predefine types and macros such as `int4`, `CLK_GLOBAL_MEM_FENCE`,
etc. Move these out of opencl-c.h into opencl-c-base.h such that the
latter can be shared by -fdeclare-opencl-builtins and
-finclude-default-header.

This changes the behaviour of -finclude-default-header when
-fdeclare-opencl-builtins is specified: instead of including the full
header, it will include the header with only the base definitions.

Differential revision: https://reviews.llvm.org/D63256

llvm-svn: 363794

show more ...

Revert D60974 "[clang-ifs] Clang Interface Stubs, first version."

This reverts commit rC363626.

clangIndex depends on clangFrontend. r363626 adds a dependency from
clangFrontend to clangIndex, whic

Revert D60974 "[clang-ifs] Clang Interface Stubs, first version."

This reverts commit rC363626.

clangIndex depends on clangFrontend. r363626 adds a dependency from
clangFrontend to clangIndex, which creates a circular dependency.

This is disallowed by -DBUILD_SHARED_LIBS=on builds:

CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
"clangFrontend" of type SHARED_LIBRARY
depends on "clangIndex" (weak)
"clangIndex" of type SHARED_LIBRARY
depends on "clangFrontend" (weak)
At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries.

Note, the dependency on clangIndex cannot be removed because
libclangFrontend.so is linked with -Wl,-z,defs: a shared object must
have its full direct dependencies specified on the linker command line.

In -DBUILD_SHARED_LIBS=off builds, this appears to work when linking
`bin/clang-9`. However, it can cause trouble to downstream clang library
users. The llvm build system links libraries this way:

clang main_program_object_file ... lib/libclangIndex.a ... lib/libclangFrontend.a -o exe

libclangIndex.a etc are not wrapped in --start-group.

If the downstream application depends on libclangFrontend.a but not any
other clang libraries that depend on libclangIndex.a, this can cause undefined
reference errors when the linker is ld.bfd or gold.

The proper fix is to not include clangIndex files in clangFrontend.

llvm-svn: 363649

show more ...

[clang-ifs] Clang Interface Stubs, first version.

Clang interface stubs (previously referred to as clang-ifsos) is a new frontend
action in clang that allows the generation of stub files that contai

[clang-ifs] Clang Interface Stubs, first version.

Clang interface stubs (previously referred to as clang-ifsos) is a new frontend
action in clang that allows the generation of stub files that contain mangled
name info that can be used to produce a stub library. These stub libraries can
be useful for breaking up build dependencies and controlling access to a
library's internal symbols. Generation of these stubs can be invoked by:

clang -fvisibility=<visibility> -emit-interface-stubs \
-interface-stub-version=<interface format>

Notice that -fvisibility (along with use of visibility attributes) can be used
to control what symbols get generated. Currently the interface format is
experimental but there are a wide range of possibilities here.

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

llvm-svn: 363626

show more ...

[Remarks] Extend -fsave-optimization-record to specify the format

Use -fsave-optimization-record=<format> to specify a different format
than the default, which is YAML.

For now, only YAML is suppor

[Remarks] Extend -fsave-optimization-record to specify the format

Use -fsave-optimization-record=<format> to specify a different format
than the default, which is YAML.

For now, only YAML is supported.

llvm-svn: 363573

show more ...

[Clang] Harmonize Split DWARF options with llc

Summary:
With Split DWARF the resulting object file (then called skeleton CU)
contains the file name of another ("DWO") file with the debug info.
This

[Clang] Harmonize Split DWARF options with llc

Summary:
With Split DWARF the resulting object file (then called skeleton CU)
contains the file name of another ("DWO") file with the debug info.
This can be a problem for remote compilation, as it will contain the
name of the file on the compilation server, not on the client.

To use Split DWARF with remote compilation, one needs to either

* make sure only relative paths are used, and mirror the build directory
structure of the client on the server,
* inject the desired file name on the client directly.

Since llc already supports the latter solution, we're just copying that
over. We allow setting the actual output filename separately from the
value of the DW_AT_[GNU_]dwo_name attribute in the skeleton CU.

Fixes PR40276.

Reviewers: dblaikie, echristo, tejohnson

Reviewed By: dblaikie

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

llvm-svn: 363496

show more ...

[Clang] Rename -split-dwarf-file to -split-dwarf-output

Summary:
This is the first in a series of changes trying to align clang -cc1
flags for Split DWARF with those of llc. The unfortunate side eff

[Clang] Rename -split-dwarf-file to -split-dwarf-output

Summary:
This is the first in a series of changes trying to align clang -cc1
flags for Split DWARF with those of llc. The unfortunate side effect of
having -split-dwarf-output for single file Split DWARF will disappear
again in a subsequent change.

The change is the result of a discussion in D59673.

Reviewers: dblaikie, echristo

Reviewed By: dblaikie

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

llvm-svn: 363494

show more ...

Add --print-supported-cpus flag for clang.

This patch allows clang users to print out a list of supported CPU models using
clang [--target=<target triple>] --print-supported-cpus

Then, users can se

Add --print-supported-cpus flag for clang.

This patch allows clang users to print out a list of supported CPU models using
clang [--target=<target triple>] --print-supported-cpus

Then, users can select the CPU model to compile to using
clang --target=<triple> -mcpu=<model> a.c

It is a handy feature to help cross compilation.

llvm-svn: 363464

show more ...