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

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

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

These tests were a little bit too flexible in terms of filenames.

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

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

This patch generates some helper variables which used as a private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by default (with the default constructor, if any). In outlined function references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables and implicit barier is set by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables.
Differential Revision: http://reviews.llvm.org/D4752


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

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

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

This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.


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

In environments where PATH was set to point to the VS installation, Clang would
override that by looking in the registry and finding the latest VS installation.

If the environment is set up to point to a VS installation, that should take
precedence.

Reverting this until we can fix it.

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

List the module cache we use for crashdumps as a tempfile. This
simplifies how we pick up this directory when generating the actual
crash diagnostic and removes some duplicate logic.

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

In practice there's only ever one temporary output file when
generating a crashdump, but even if there were many iterating over
each and creating a duplicate run script for each one wouldn't make
very much sense.

This updates the behaviour to only generate the script once, based on
the first filename.

This should make it more reasonable to generate extra output files to
include in the crashdump going forward, so I've also added a FIXME to
look into doing just that with the extra module crashdump files.

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

This just flattens an if block by returning early on the "else"
condition.

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

We currently use a null FailingCommand when generating crash reports
as an indication that the cause is FORCE_CLANG_DIAGNOSTICS_CRASH, the
environment variable that exists to test crash dumps. This means that
our tests don't actually cover real crashes at all, and adds a more
complicated code path that's only used in the tests.

Instead, we can have the driver synthesize that every command failed
and just call generateCompilationDiagnostics normally.

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

Post commit review feedback from Yaron Keren.

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

Typically clang finds Visual Studio by the user explicitly setting
up a Visual Studio environment via vcvarsall.  But we still try to
behave intelligently and fallback to different methods of finding
Visual Studio when this is not done.  This patch improves various
fallback codepaths to make Visual Studio locating more robust.

Specifically, this patch:

* Adds support for searching environment variables for VS 12.0
* Correctly locates include folders for Windows SDK 8.x (this was
  previously broken, and would cause clang to error)
* Prefers locating link.exe in the same location as cl.exe.  This
  is helpful in case another link.exe is in the path earlier than
  Visual Studio (e.g. GnuWin32)
* Minor cleanup in the registry reading code to make it more
  robust in the presence of long pathnames.

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

PR21312: Fix a regression in non-type template parameters of function type that are static member functions.

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

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

Clang supports __restrict__ as a function qualifier, but
DeclaratorChunk::FunctionTypeInfo lacked a field to track the qualifier's
source location (as we do with volatile, etc.). This was the subject of a FIXME
in GetFullTypeForDeclarator (in SemaType.cpp). This should also prove useful as
we add more warnings regarding questionable uses of the restrict qualifier.

There is no significant functional change (except for an improved source range
associated with the err_invalid_qualified_function_type diagnostic fixit
generated by GetFullTypeForDeclarator).

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

Now that we no longer add mappings when there are no local entities,
there is no need to always bump the size of the tables that correspond
to ContinuousRangeMaps.

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

This is a better fix for 'duplicate key' problems in module continuous
range maps (vs what I added in r215810) by not adding any mappings at
all when there are no local entities. Now it also covers selectors,
which were not always being bumped because the record SELECTOR_OFFSET is
not always emitted.  I'll back out most of r215810 in a future commit,
since it should no longer be needed.

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

Before:
  template <class F>
  void Call(F f) {
    f.template operator() <int>();
  }

After:
  template <class F>
  void Call(F f) {
    f.template operator()<int>();
  }

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

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

Before:
  [self aaaaa:MACRO(a, b :, c :)];

After:
  [self aaaaa:MACRO(a, b:, c:)];

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

Before:
  struct {
    int x;
    int y;
  } points[] = {
        {1, 2}, {2, 3},
  };

After:
  struct {
    int x;
    int y;
  } points[] = {
      {1, 2}, {2, 3},
  };

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

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

Callers of DataLayout::RoundUpAlignment should switch to
RoundUpToAlignment.

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

#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.


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

This reverts commit r220169 which reverted r220153.  However, it also
contains additional changes:
- We may need to add padding *after* we've packed the struct.  This
  occurs when the aligned next field offset is greater than the new
  field's offset.  When this occurs, we make the struct packed.
  *However*, once packed the next field offset might be less than the
  new feild's offset.  It is in this case that we might further pad the
  struct.
- We would pad structs which were perfectly sized!  This behavior is
  immensely old.  This behavior came from blindly subtracting
  NextFieldOffsetInChars from RecordSize.  This doesn't take into
  account the fact that the struct might have a greater overall
  alignment than the last field.

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

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

This commit caused two tests in LNT to regress. I'm able to reproduce on
any platform and will send reproduction steps to the original commit
log. This should restore the LNT bots that have been failing.

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

a NaN-test prior to the call to the library function.

This should automatically make fastmath (including just non-NaNs) able to avoid
the expensive libcalls and also open the door to more advanced folding in LLVM
based on the rules for complex math.

Two important notes to remember: first is that this isn't yet a proper
limited range mode, it's still just improving the unlimited range mode.
Also, it isn't really perfecet w.r.t. what an unlimited range mode
should be doing because it isn't quite handling the flags produced by
all the operations in the way desirable for that mode, but then neither
is compiler-rt's libcall. When the compiler-rt libcall is improved to
carefully manage flags, the code emitted here should be improved
correspondingly. And it is still a long-term desirable thing to add
a limited range mode to Clang that would be able to use direct math
without library calls here.

Special thanks to Steve Canon for the careful review on this patch and
teaching me about these issues. =D

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

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

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

[analyzer] Tweak MallocSizeOfChecker to not warn when using sizeof(void*) to allocate a bunch of any pointer type.

This suppresses a common false positive when analyzing libc++.

Along the way, introduce some tests to show this checker actually
works with C++ static_cast<>.

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

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

Before, ConstStructBuilder::AppendBytes would check packed constraints
prior to padding being added before the field's offset.  However, adding
this padding might force our struct to be packed.  Because we wouldn't
check *after* adding padding, ConstStructBuilder would be in an
inconsistent state leading to a crash.

This fixes PR21300.

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

clang tests were breaking, at least when compiling clang only, from an
installed llvm. Make the lit.cfg script deal with the case when we don't
have a host_triple available.

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

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

[libclang] If the code-completion point is inside the preamble, adjust the position at the beginning of the file after the preamble.
    
Otherwise we will not hit the code-completion point.


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

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