The previous one (r240021) regressed:
  enum E Type::f() { .. }

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

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

Base type of attribute((mode)) can actually be a vector type.
The patch is to distinguish between base type and base element type.

This fixes http://llvm.org/PR17453.
Differential Revision: http://reviews.llvm.org/D10058


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

Clang's control flow integrity implementation works by conceptually attaching
"tags" (in the form of bitset entries) to each virtual table, identifying
the names of the classes that the virtual table is compatible with. Under
the Itanium ABI, it is simple to assign tags to virtual tables; they are
simply the address points, which are available via VTableLayout. Because any
overridden methods receive an entry in the derived class's virtual table,
a check for an overridden method call can always be done by checking the
tag of whichever derived class overrode the method call.

The Microsoft ABI is a little different, as it does not directly use address
points, and overrides in a derived class do not cause new virtual table entries
to be added to the derived class; instead, the slot in the base class is
reused, and the compiler needs to adjust the this pointer at the call site
to (generally) the base class that initially defined the method. After the
this pointer has been adjusted, we cannot check for the derived class's tag,
as the virtual table may not be compatible with the derived class. So we
need to determine which base class we have been adjusted to.

Specifically, at each call site, we use ASTRecordLayout to identify the most
derived class whose virtual table is laid out at the "this" pointer offset
we are using to make the call, and check the virtual table for that tag.

Because address point information is unavailable, we "reconstruct" it as
follows: any virtual tables we create for a non-derived class receive a tag
for that class, and virtual tables for a base class inside a derived class
receive a tag for the base class, together with tags for any derived classes
which are laid out at the same position as the derived class (and therefore
have compatible virtual tables).

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

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

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

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

This causes programs compiled with this flag to print a diagnostic when
a control flow integrity check fails instead of aborting. Diagnostics are
printed using UBSan's runtime library.

The main motivation of this feature over -fsanitize=vptr is fidelity with
the -fsanitize=cfi implementation: the diagnostics are printed under exactly
the same conditions as those which would cause -fsanitize=cfi to abort the
program. This means that the same restrictions apply regarding compiling
all translation units with -fsanitize=cfi, cross-DSO virtual calls are
forbidden, etc.

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

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

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

This flag controls whether a given sanitizer traps upon detecting
an error. It currently only supports UBSan. The existing flag
-fsanitize-undefined-trap-on-error has been made an alias of
-fsanitize-trap=undefined.

This change also cleans up some awkward behavior around the combination
of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we
would reject command lines containing the combination of these two flags,
as -fsanitize=vptr is not compatible with trapping. This required the
creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr
(and -fsanitize=function, but this seems like an oversight).

Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap,
and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr
as an "unsupported" flag, which means that we error out if the flag is
specified explicitly, but implicitly disable it if the flag was implied
by -fsanitize=undefined.

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

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

imported definition.


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

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

This fixes buildbot failures introduced by r240038.

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

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

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

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

The most general model has fields for the vbptr offset and the vbindex.
Don't initialize the vbptr offset if the vbindex is 0: we aren't
referencing an entity from a vbase.

Getting this wrong can make member pointer equality fail.

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

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

Reviewers: arsenm

Subscribers: cfe-commits

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

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

provided by an upcoming commit.

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

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

It was a bit too aggressive.

With this patch, we keep on breaking here:
  aaaaaaaaaaaaa(aaaaaaa,
                "aaaaaaa"
                "bbbbbbb");

But don't break in:
  aaaaaaaaaaaaa(aaaaaaa, aaaaaaaa("aaaaaaa"
                                  "bbbbbbb"));

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

Before, this wasn't formatted properly:
  enum ::C f() {
    return a;
  }

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

GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -march option for the AArch64 target.


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

Adds emission of the code for 'proc_bind(master|close|spread)' clause:
call void @__kmpc_push_proc_bind(<loc>, i32 thread_id, i32 4|3|2)



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

Before:
  var func =
      function() {
        doSomething();
      };

After:
  var func =
      function() {
    doSomething();
  };

This is a very narrow special case which fixes most of the discrepency
with what our users do. In the long run, we should try to come up with
a more generic fix for indenting these.

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

Added parsing, sema analysis and codegen for '#pragma omp taskgroup' directive (OpenMP 4.0).
The code for directive is generated the following way:
#pragma omp taskgroup
<body>

void __kmpc_taskgroup(<loc>, thread_id);
<body>
void __kmpc_end_taskgroup(<loc>, thread_id);


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

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

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

Codegen for this directive is a combined codegen for 'omp parallel' region with 'omp for simd' region inside. Clauses are supported.


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

In essence this is meant to consistently indent multiline strings by a
fixed amount of spaces from the start of the line. Don't do this in
cases where it wouldn't help anyway.

Before:
  someFunction(aaaaa,
               "aaaaa"
               "bbbbb");

After:
  someFunction(aaaaa, "aaaaa"
                      "bbbbb");

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

Added codegen for combined 'omp for simd' directives, that is a combination of 'omp for' directive followed by 'omp simd' directive. Includes support for all clauses.


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

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

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

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

An old code caused problems under Windows - additional temporary file was created for clang preprocessor output while the right output file remained empty.

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

making either of them visible makes the merged definition visible.


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

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

This reverts commit r239953, while I'm investigating assertion
failure from http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/9994/

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

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

Summary:
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support (i.e.
set from -fsanitize=undefined-trap).

Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.

This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539)

Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.

Test Plan: regression test suite

Reviewers: pcc

Subscribers: cfe-commits, filcab, eugenis, thakis, kubabrecka, emaste, rsmith

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

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