Re-apply r302108, "IR: Use pointers instead of GUIDs to represent edges in the module summary. NFCI."
with a fix for the clang backend.

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

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

Summary: While its precedence should be higher than multiplicative, LLVM does not have a level for that, so for the time being just treat it as multiplicative.

Reviewers: djasper

Subscribers: cfe-commits, klimek

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

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

delayed diagnostic

This fix avoids an infinite recursion that was uncovered in one of our internal
tests by r301992. The testcase is the most reduced version of that
auto-generated test.

This is an improved version of the reverted commit r302037. The previous fix
actually managed to expose another subtle bug whereby `fatal_too_many_errors`
error was reported twice, with the second report setting the
`FatalErrorOccurred` flag. That prevented the notes that followed the diagnostic
the caused `fatal_too_many_errors` to be emitted. This commit ensures that notes
that follow `fatal_too_many_errors` but that belong to the diagnostic that
caused `fatal_too_many_errors` won't be emitted by setting the
`FatalErrorOccurred` when emitting `fatal_too_many_errors`.

rdar://31962618


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

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

This reverts commit r302108.

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

specializations that 'override' declarations in the base template should use
the 'specializationOf' relation instead of 'specializationOf | overrideOf'.

The indexer relations are meant to be orthogonal, so 'specializationOf' is
better than the combined relation.


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

Implemented the remaining integer data processing intrinsics from
the ARM ACLE v2.1 spec, such as parallel arithemtic and DSP style
multiplications.

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


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

Summary:
Add intel_reqd_sub_group_size attribute support as intel extension  cl_intel_required_subgroup_size from
https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_required_subgroup_size.txt

Reviewers: Anastasia, bader, hfinkel, pxli168

Reviewed By: Anastasia, bader, pxli168

Subscribers: cfe-commits, yaxunl

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

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

When profiling a no-op incremental link of Chromium I found that the functions
computeImportForFunction and computeDeadSymbols were consuming roughly 10% of
the profile. The goal of this change is to improve the performance of those
functions by changing the map lookups that they were previously doing into
pointer dereferences.

This is achieved by changing the ValueInfo data structure to be a pointer to
an element of the global value map owned by ModuleSummaryIndex, and changing
reference lists in the GlobalValueSummary to hold ValueInfos instead of GUIDs.
This means that a ValueInfo will take a client directly to the summary list
for a given GUID.

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

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

These pragmas are intended to simulate the effect of entering or leaving a file
with an associated module. This is not completely implemented yet: declarations
between the pragmas will not be attributed to the correct module, but macro
visibility is already functional.

Modules named by #pragma clang module begin must already be known to clang (in
some module map that's either loaded or on the search path).


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

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

A bot had "-LTO" in its working directory, which matched the regex used in this
test. Since the arg is quoted, we can exploit that instead. Still broken if
there's a path with a quote in, but I think that's pretty niche.

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

Summary:
Do three things to help with that:
- Add AttributeList::FirstArgIndex, which is an enumerator currently set
  to 1. It allows us to change the indexing scheme with fewer changes.
- Add addParamAttr/removeParamAttr. This just shortens addAttribute call
  sites that would otherwise need to spell out FirstArgIndex.
- Remove some attribute-specific getters and setters from Function that
  take attribute list indices.  Most of these were only used from
  BuildLibCalls, and doesNotAlias was only used to test or set if the
  return value is malloc-like.

I'm happy to split the patch, but I think they are probably easier to
review when taken together.

This patch should be NFC, but it sets the stage to change the indexing
scheme to this, which is more convenient when indexing into an array:
  0: func attrs
  1: retattrs
  2...: arg attrs

Reviewers: chandlerc, pete, javed.absar

Subscribers: david2050, llvm-commits

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

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

The commit caused the following two buildbot failures:

    Clang :: Misc/error-limit-multiple-notes.cpp
    Clang :: Misc/error-limit.c


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

delayed diagnostic

This avoids an infinite loop that was uncovered in one of our internal tests
by r301992. The testcase is the most reduced version of that auto-generated
test.

rdar://31962618


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

https://reviews.llvm.org/D32807

This patch allows the map modifier 'always' to be separated by the map type (to, from, tofrom) only by a whitespace, rather than strictly by a comma as in current trunk.




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

In a previous patch, a new generic error diagnostic for inconsistent attributes was added.
In this commit I reuse this diagnostic for ns_returns_retained attribute check.

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


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

It was written as "Memory Error" in most places and as "Memory error" in a few
other places, however it is the latter that is more consistent with
other categories (such as "Logic error").

rdar://problem/31718115

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


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

This produces warnings that I can't explain in a GCC build:

In file included from ../tools/clang/include/clang/Lex/LexDiagnostic.h:13:0,
                 from /usr/local/google/home/djasper/llvm/tools/clang/lib/Lex/PTHLexer.cpp:19:
../tools/clang/include/clang/Basic/Diagnostic.h:219:34: warning: ‘clang::DiagnosticsEngine::DiagState::ExtBehavior’ is too small to hold all values of ‘enum class clang::diag::Severity’ [enabled by default]
     diag::Severity ExtBehavior : 4;     // Map extensions to warnings or errors?
                                  ^

While I don't think this warning makes sense, I'd like to get this back to being
warning-free. This only seems to trigger for "enum class".

Reproducer:
https://godbolt.org/g/P2ekVd

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

These were relying on the attribute group numbering

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

I think this is a false positive in GCC's warning, but nonetheless, we
should try to be warning-free. Smaller reproducer (reproduces with GCC
6.3):
https://godbolt.org/g/cJuO2z

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

This reverts commit because it broke
sanitizer-x86_64-linux-autoconf bot and
clang-ppc64be-linux-multistage  bot.

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

-isysroot is the flag which set the system root directory.
This bug report https://bugs.llvm.org//show_bug.cgi?id=11503
shows that -isysroot is not handled at all on Unix, so fixed this bug.

After this diff, I could get this result https://pastebin.com/TeCmn9mj .

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

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

These were relying on the attribute group numbering

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

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

The intent for an explicit module build is that the diagnostics produced within
the module are those that were configured when the module was built, not those
that are enabled within a user of the module. This includes diagnostics that
don't actually show up until the module is used (for instance, diagnostics
produced during template instantiation and weird cases like -Wpadded).

We serialized and restored the diagnostic state for individual warning groups,
but previously did not track the state for flags like -Werror and -Weverything,
which are implemented as separate bits rather than as part of the diagnostics
mapping information.


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

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

Currently, ubsan emits overflow checks for arithmetic that is known to
be safe at compile-time, e.g:

  1 + 1 => CheckedAdd(1, 1)

This leads to breakage when using the __builtin_prefetch intrinsic. LLVM
expects the arguments to @llvm.prefetch to be constant integers, and
when ubsan inserts unnecessary checks on the operands to the intrinsic,
this contract is broken, leading to verifier failures (see PR32874).

Instead of special-casing __builtin_prefetch for ubsan, this patch fixes
the underlying problem, i.e that clang currently emits unnecessary
overflow checks.

Testing: I ran the check-clang and check-ubsan targets with a stage2,
ubsan-enabled build of clang. I added a regression test for PR32874, and
some extra checking to make sure we don't regress runtime checking for
unsafe arithmetic. The existing ubsan-promoted-arithmetic.cpp test also
provides coverage for this change.

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

This time, I fixed, built, and tested clang.

This reverts r301712.

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

- this is added just for completeness sake (though the general case should be represented by the test added in the revision to that patch:  https://reviews.llvm.org/rL301972 )


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

Fix PR32831 (Try Again): 'this' capture while instantiating generic lambda call operator specialization

When computing the appropriate cv-qualifiers for the 'this' capture, we have to examine each enclosing lambda - but when using the FunctionScopeInfo stack we have to ensure that the lambda below (outer) is the decl-context of the closure-class of the current lambda.

https://bugs.llvm.org/show_bug.cgi?id=32831

This patch was initially committed here: https://reviews.llvm.org/rL301735
Then reverted here: https://reviews.llvm.org/rL301916

The issue with the original patch was a failure to check that the closure type has been created within the LambdaScopeInfo before querying its DeclContext - instead of just assuming it has (silly!).  A reduced example such as this highlights the problem:
  struct X {
     int data;
     auto foo() { return [] { return [] -> decltype(data) { return 0; }; }; }
  };

When 'data' within decltype(data) tries to determine the type of 'this', none of the LambdaScopeInfo's have their closure types created at that point.

 

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

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

Combine the logic doing the ms_abi/sysv_abi checks into one function so
that each check and its logical opposite are near each other. Now we
don't need two Sema entry points for MS va_start and regular va_start.

Refactor the code that checks if the va_start caller is a function,
block, or obj-c method. We do this in three places, and they are all
buggy for variadic lambdas (PR32737). After this change, I have one
place to apply the functional fix.

NFC

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

handling of constexprs with unknown bounds.

This triggers a corner case of the language where it's not yet clear
whether this should be an error:

  struct A {
    static void *const a[];
    static void *const b[];
  };
  constexpr void *A::a[] = {&b[0]};
  constexpr void *A::b[] = {&a[0]};

When discovering the initializer for A::a, the bounds of A::b aren't known yet.
It is unclear whether warning about errors should be deferred until the end of
the translation unit, possibly resolving errors that can be resolved. In
practice, the compiler can know the bounds of all arrays in this example.

Credits for reproducers and explanation go to Richard Smith. Richard, please
add more info in case my explanation is wrong.

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

This reverts commit r300295.

It's no longer true, print_stacktrace=1 is supported on Darwin/Windows
as of r301839.

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

Don't test the optimizer as part of front-end verification.


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

It leads to clang crashing, e.g. on this short code fragment (added to
test/SemaCXX/warn-thread-safety-parsing.cpp):

  class SomeClass {
  public:
    void foo() {
      auto l = [this] { auto l = [] EXCLUSIVE_LOCKS_REQUIRED(mu_) {}; };
    }
    Mutex mu_;
  };

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

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


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

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