The main change is that now we generate TBAA info before
constructing the resulting lvalue instead of constructing lvalue
with some default TBAA info and fixing it as necessary
afterwards. We also keep the TBAA info close to lvalue base info,
which is supposed to simplify their future merging.

This patch should not bring in any functional changes.

This is part of D38126 reworked to be a separate patch to
simplify review.

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


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

This patch addresses the rest of the cases where we pass lvalue
base info, but do not provide corresponding TBAA info.

This patch should not bring in any functional changes.

This is part of D38126 reworked to be a separate patch to make
reviewing easier.

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


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

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


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

A trailing deferred region isn't necessary in a function that ends with
this pattern:

  ...
  else {
    ...
    return;
  }

Special-case this pattern so that the closing curly brace of the
function isn't marked as uncovered. This issue came up in PR34962.

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

This makes it possible to view sub-line region counts for the l.h.s of
&& and || expressions in coverage reports.

It also fixes PR33465, which shows an example of incorrect coverage
output for an assignment statement containing '||'.

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

The nan family of math routines do not rely on global state.  They do
however depend on their parameter.  This fits the description of pure:
  Functions which have no effects except the return value and their
  return value depends only on the parameters and/or global variables.
Mark the family as `readonly`.

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

Summary:
This patch allows checking the availability of cursors through libclang and clang.cindex (Python).
This e.g. allows to check whether a C++ member function has been marked as deleted.

Reviewers: arphaman, jbcoe

Reviewed By: jbcoe

Subscribers: cfe-commits

Tags: #clang

Patch by jklaehn (Johann Klähn)

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

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

Summary: Previously, `VisitAttributes` was not called for function and class templates and thus their attributes were not accessible using libclang.

Reviewers: bkramer, arphaman, rsmith, jbcoe

Reviewed By: jbcoe

Subscribers: cfe-commits

Tags: #clang

Patch by jklaehn (Johann Klähn)

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

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

Record::getValueAsString returns a stringref to an interned
string (apparently had been changed since most of tablegen was
written). In this patch, I audited the usage of getValueAsString
to find places where we can trivially stop storing 'std::string' and instead
keep the stringref.

There was one instance where an unnecessary 'stringstream' was being used,
so that has been removed as well to unblock the stringref replacing string fix.

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


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

This comes up when pre-processing standalone .s files containing
hash-prefixed comments. The pre-processor should skip the unknown
directive and not emit an extra newline as we were doing.

Fixes PR34950

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

GCC ignore qualifiers on array types. Since we seem to have this
function primarily for GCC compatibility, we should try to match that
behavior.

This also adds a few more test-cases __builtin_types_compatible_p,
which were inspired by GCC's documentation on the builtin.


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

Typically we don't use the stringstream, so instead use
raw_string_stream.  Additionally, the dependent function
changed to use raw_ostream.


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

This documentation was copied directly from the GCC
documentaiton in r257867.  Reverting and alterting
the original author so that it can be rewritten in
copyright-safe language.


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

Attributes in the docs were previously sorted (apparently)
by the attribute name, so AnyX86Interrupt ended up being the
first one, rather than in a meaningful place. This resulted in the
4 'interrupt' titled sections being all in different places.

This replaces it with a naive alphabetical sort (case sensitive, underscore
and special characters first, etc).

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


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

All 4 of the 'interrupt' headers were automatically named
'interrupt'. This patch gives them unique names.


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

This commit allows the refactoring library to use its own set of
refactoring-specific diagnostics to reports things like initiation errors.

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


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

As suggested by David Blaikie!


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

Summary:
The OS provides cross-dso CFI support starting with Android O.
Trapping mode does not require any runtime at all, and diagnostic mode
requires just ubsan-standalone.

Reviewers: pcc

Subscribers: srhines, cfe-commits

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

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

The fixed commit ensures that ParsedSourceRange works correctly
with Windows paths.

Original message:

This commit actually brings clang-refactor to a usable state as it can now
apply the refactoring changes to source files.
The -selection option is now also fully supported.

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


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

Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default.

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


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

If the user passes -nocudalib, we can live without it being present.
Simplify the code by just checking whether LibDeviceMap is empty.

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

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

Summary:
Also contain a fix:

* Fix a false positive of renaming a using shadow function declaration.

Reviewers: ioeric

Reviewed By: ioeric

Subscribers: klimek, mgorny, cfe-commits

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

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

Summary:
This patch enables `BreakableToken` to manage the formatting of non-trailing
block comments. It is a refinement of https://reviews.llvm.org/D37007.
We discovered that the optimizer outsmarts us on cases where breaking the comment
costs considerably less than breaking after the comment. This patch addresses
this by ensuring that a newline is inserted between a block comment and the next
token.

Reviewers: djasper

Reviewed By: djasper

Subscribers: cfe-commits, klimek

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

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

The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.

Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak

Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565

Reviewers: rjmccall, rsmith, aaron.ballman

Reviewed By: rsmith

Subscribers: rtrieu, jroelofs, cfe-commits

Tags: #clang

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

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

Summary:
Convert clang::LangAS to a strongly typed enum

Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.

I found the following errors while writing this patch:

- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
  space to  TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
  clang AST address space instead of the target address space.
  However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
  LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
  TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
  to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
  llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
  space. As this is exposed to C I have kept the current behaviour and
  added a comment stating that it is probably not correct.

Other than this the patch should not cause any functional changes.

Reviewers: yaxunl, pcc, bader

Reviewed By: yaxunl, bader

Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits

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

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

The patch should have been checking against STDCXX17 not STDCXX14.

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

When using lld on macOS the current level of detection between ld and
ld64 forces us to rename lld to ld.

For ELF targets we have the ld.lld alias so for MACHO we should have
ld64.lld so we can use lld without replacing the system compiler.

This also solves the additional issue of cross compiling for MACHO
where renaming lld to ld with only target ELF.

This is the clang driver component change to use this new alias.

Reviewers: ruiu, rnk

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

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

Patch by: daxpedda

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

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

Add -f[no-]double-square-bracket-attributes as new driver options to control use of [[]] attributes in all language modes. This is the initial implementation of WG14 N2165, which is a proposal to add [[]] attributes to C2x, but also allows you to enable these attributes in C++98, or disable them in C++11 or later.

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

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

[c++2a] Fix failing regression test related to not adding the extension warning to a diagnostic group (in r315840)

In passing also complete a comment that I left uncompleted.

For ease of reference, here's the parent commit: https://reviews.llvm.org/rL315840





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

This patch implements an extension to the preprocessor:

__VA_OPT__(contents) --> which expands into its contents if variadic arguments are supplied to the parent macro, or behaves as an empty token if none.

  - Currently this feature is only enabled for C++2a (this could be enabled, with some careful tweaks, for other dialects with the appropriate extension or compatibility warnings)

  - The patch was reviewed here: https://reviews.llvm.org/D35782 and asides from the above (and moving some of the definition and expansion recognition logic into the corresponding state machines), I believe I incorporated all of Richard's suggestions.

A few technicalities (most of which were clarified through private correspondence between rsmith, hubert and thomas) are worth mentioning.  Given:

    #define F(a,...) a #__VA_OPT__(a ## a)  a ## __VA_OPT__(__VA_ARGS__)

    - The call F(,) Does not supply any tokens for the variadic arguments and hence VA_OPT behaves as a placeholder.
    - When expanding VA_OPT (for e.g. F(,1) token pasting occurs eagerly within its contents if the contents need to be stringified.
    - A hash or a hashhash prior to VA_OPT does not inhibit expansion of arguments if they are the first token within VA_OPT.
    - When a variadic argument is supplied, argument substitution occurs within the contents as does stringification - and these resulting tokens are inserted back into the macro expansions token stream just prior to the entire stream being rescanned and concatenated.

See wg21.link/P0306 for further details on the feature.


Acknowledgment: This patch would have been poorer if not for Richard Smith's usual thoughtful analysis and feedback.


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

Test is fixed in r315830


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

This is causing:
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/43381

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

The warnings in libc++ tests were fixed in the meantime.

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

check-libcxx dislikes it.

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

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

In OpenCL the kernel function and non-kernel function has different calling conventions.
For certain targets they have different argument ABIs. Also kernels have special function
attributes and metadata for runtime to launch them.

The blocks passed to enqueue_kernel is supposed to be executed as kernels. As such,
the block invoke function should be emitted as kernel with proper calling convention and
argument ABI.

This patch emits enqueued block as kernel. If a block is both called directly and passed
to enqueue_kernel, separate functions will be generated.

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


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

If the variable construction can be constant evaluated it doesn't have
side effects, so removing it is always safe. We only try to evaluate
variables that are unused, there should be no impact on compile time.

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

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

The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (constructor
calls, calls through thunks, etc. all use a separate code path). Don't
emit function signatures for functions that won't be checked.

Apart from cutting down on code size, this should fix a regression on
Linux caused by r313096. For context, see the mailing list discussion:

r313096 - [ubsan] Function Sanitizer: Don't require writable text segments

Testing: check-clang, check-ubsan

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

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