llvm-svn: 339109

It turns out that the AVX bots have different alignment for their vectors, and my test mistakenly assumed a particular vector alignent on the stack. Instead, capture the alignment and test for it in subsequent operations.

llvm-svn: 339093

I was using it for testing, r339089 shouldn't have contained it.

llvm-svn: 339090

Summary:
r337887 started using memset for automatic variable initialization where sensible. A follow-up discussion leads me to believe that we should better test automatic variable initialization, and that there are probably follow-up patches in clang and LLVM to improve codegen. It’ll be important to measure -O0 compile time, and figure out which transforms should be in the frontend versus the backend.

This patch is just a test of the current behavior, no questions asked. Follow-up patches will tune the code generation.

<rdar://problem/42981573>

Subscribers: dexonsmith, cfe-commits

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

llvm-svn: 339089

It now actually produces a signed APSInt when the QualType passed into it is
signed, which is what any caller would expect.

Fixes a couple of crashes.

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

llvm-svn: 339088

The change in the AST in r338135 caused us to accidentally support
inlining constructors of operator implicit arguments. Previously they were
hard to support because they were treated as arguments in expressions
but not in declarations, but now they can be transparently treated as
simple temporaries.

Add tests and comments to explain how it now works.

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

llvm-svn: 339087

-This line, and those below, will be ignored--

M    TemplateBase.h

llvm-svn: 339085

Summary: Changed the structure of the generated IR to make it easier to vectorize

Reviewers: morehouse, kcc

Reviewed By: morehouse

Subscribers: cfe-commits, llvm-commits

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

llvm-svn: 339080

Some checkers require ASTContext. Having it in the constructor saves a
lot of boilerplate of having to pass it around.

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

llvm-svn: 339079

Summary:
The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes.

This is a companion change to: https://reviews.llvm.org/D50206

Reviewers: asmith, zturner

Subscribers: cfe-commits

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

llvm-svn: 339074

For InnerPointerChecker to function properly, both the checker itself
and parts of MallocChecker that handle relevant use-after-free problems
need to be turned on. So far, the latter part has been developed within
MallocChecker's NewDelete sub-checker, often causing warnings to appear
under that name. This patch defines a new CheckKind within MallocChecker
for the inner pointer checking functionality, so that the correct name
is displayed in warnings and in the ExplodedGraph.

Tested on clang-tidy.

Differential Review: https://reviews.llvm.org/D50211

llvm-svn: 339067

Summary:
InMemoryFileSystem::status behaves differently than
RealFileSystem::status.  The Name contained in the Status returned by
RealFileSystem::status will be the path as requested by the caller,
whereas InMemoryFileSystem::status returns the normalized path.

For example, when requested the status for "../src/first.h",
RealFileSystem returns a Status with "../src/first.h" as the Name.
InMemoryFileSystem returns "/absolute/path/to/src/first.h".

The reason for this change is that I want to make a unit test in the
clangd testsuite (where we use an InMemoryFileSystem) to reproduce a
bug I get with the clangd program (where a RealFileSystem is used).
This difference in behavior "hides" the bug in the unit test version.

An indirect impact of this change is that a -Wnonportable-include-path
warning is now emitted in test PCH/case-insensitive-include.c.  This is
because the real path of the included file (with the wrong case) was not
available previously, whereas it is now.

Reviewers: malaperle, ilya-biryukov, bkramer

Reviewed By: ilya-biryukov

Subscribers: eric_niebler, malaperle, omtcyfz, hokein, bkramer, ilya-biryukov, ioeric, cfe-commits

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

llvm-svn: 339063

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

llvm-svn: 339048

std::abs.

llvm-svn: 339044

llvm-svn: 339039

in once I figure out why this doesn't work on windows.

llvm-svn: 339038

left shift on a negative value.

llvm-svn: 339037

The Fuchsia driver relies on lld so invoke clang with
-fuse-ld=lld. This gets the test passing when the clang default linker
is something other than lld.

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

llvm-svn: 339036

lib/Basic cannot depend on lib/AST.

llvm-svn: 339031

DeclarationNameTable currently hold 3 "void *" to
FoldingSet<CXXSpecialName>, FoldingSet<CXXLiteralOperatorIdName>
and FoldingSet<CXXDeductionGuideNameExtra>.

CXXSpecialName, CXXLiteralOperatorIdName and
CXXDeductionGuideNameExtra are private classes holding extra
information about a "special" declaration name and are in
AST/DeclarationName.cpp. The original intent seems to have
been to keep these classes private and only expose
DeclarationNameExtra and DeclarationName (the code dates from
2008 and has not been significantly changed since).

However this make the code less straightforward than necessary
because of the need to have "void *" in DeclarationNameTable
(with 1 of 3 comments wrong) and to manually allocate/deallocate
the FoldingSets.

Moreover removing the extra indirections reduce the run-time of
an fsyntax-only on all of Boost by 2.3% which is not totally
unexpected given how frequently this data structure is used
(especially for C++).

A concern raised by erichkeane during the review was that
including Type.h would increase the compile time unreasonably.
However test builds (both clean and incremental) showed that
this patch did not result in any compile time increase.

Reviewed By: erichkeane

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

llvm-svn: 339030

This patch proposes an abstract type that represents fixed point numbers, similar to APInt or APSInt that was discussed in https://reviews.llvm.org/D48456#inline-425585. This type holds a value, scale, and saturation and is meant to perform intermediate calculations on constant fixed point values.

Currently this class is used as a way for handling the conversions between fixed point numbers with different sizes and radixes. For example, if I'm casting from a signed _Accum to a saturated unsigned short _Accum, I will need to check the value of the signed _Accum to see if it fits into the short _Accum which involves getting and comparing against the max/min values of the short _Accum. The FixedPointNumber class currently handles the radix shifting and extension when converting to a signed _Accum.

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

llvm-svn: 339028

- Print negative numbers correctly
- Handle APInts of different sizes
- Add formal unit tests for FixedPointValueToString
- Add tests for checking correct printing when padding is set
- Restrict to printing in radix 10 since that's all we need for now

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

llvm-svn: 339026

This mirrors what is done for Decls and Stmts in the -print-stats
output, ie instead of printing "57426 LValueReference types"
we print "57426 LValueReference types, 40 each (2297040 bytes)".

llvm-svn: 339024

Summary: The previous code which avoided infinite recursion (because of reparsing declarations in function parameter lists) contained SourceRange dependent code which had some problems when parameter types were coming from macros. The new solution is not using macros and therefore much safer. A couple of importer problems are fixed in redis and tmux by this fix. Various unittests are included.

Reviewers: a.sidorin, r.stahl, a_sidorin

Reviewed By: a_sidorin

Subscribers: cfe-commits, dkrupp, balazske, martong

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

Patch by Zoltan Gera!

llvm-svn: 339018

Move the enum { ObjCMethodFamilyBitWidth = 4 } to the top of
the class. For some dark reason having the enum between the
bitfields breaks the packing with gcc version 7.3-win32 20180312.

Reported by: Abramo Bagnara (by email)

llvm-svn: 339017

Summary:
The code defines __FLOAT_H and then includes the next <float.h>, which is
guarded on __FLOAT_H so it gets skipped entirely. This commit uses the header
guard __CLANG_FLOAT_H, like other headers (such as limits.h) do.

Reviewers: jfb

Subscribers: dexonsmith, cfe-commits

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

llvm-svn: 339016

llvm-svn: 339008

Summary:
This patch makes the clang-rename.py script useable for vim with only python3
support. It uses the print-function and adjust the doc slightly to mention
the correct python3 command for the letter mapping in vim.

Reviewers: arphaman, klimek, aaron.ballman, hokein

Reviewed By: hokein

Subscribers: cfe-commits

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

llvm-svn: 338996

Build failed in
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/27258

In lib/CodeGen/LiveDebugVariables.cpp:589, it uses std::prev(MBBI) to
get DebugValue's SlotIndex. however, the previous instruction may be
also a debug instruction.

llvm-svn: 338992

Generate DILabel metadata and call llvm.dbg.label after label
statement to associate the metadata with the label.

After fixing PR37395.

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

llvm-svn: 338989

After refactoring DbgInfoIntrinsic class hierarchy, we use
DbgVariableIntrinsic as the base class of variable debug info.

In resolveTopLevelMetadata() in CGVTables.cpp, we only care about
dbg.value, so we try to cast the instructions to DbgVariableIntrinsic
before resolving variables.

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

llvm-svn: 338985

errors on) and clean up the formattting.

This isn't actualy assembly anyways, so dropping the highlighting is
probably for the best.

llvm-svn: 338979

Summary:
Optimization remark format is slightly changed by LLVM patch D49412.
Two tests are fixed with expected messages changed.
Frankly speaking I have not tested this change yet. I will test when manage to setup the project.

Reviewers: xbolva00

Reviewed By: xbolva00

Subscribers: mehdi_amini, eraman, steven_wu, dexonsmith

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

llvm-svn: 338971

These forward declarations for various classes in the Type
hierarchy are not needed since they are all forward declared
systematically a few lines below.

llvm-svn: 338966

Looks like the only reason we use a unique_ptr here is so that we can
conditionally construct a LogicalErrorHandler. It's a small type, and
Optional can do the same thing with 100% fewer heap allocations.

llvm-svn: 338962

llvm-svn: 338946

When a non-extended temporary object is created in a conditional branch, the
lifetime of that temporary ends outside the conditional (at the end of the
full-expression). If we're inserting lifetime markers, this means we could end
up generating

  if (some_cond) {
    lifetime.start(&tmp);
    Tmp::Tmp(&tmp);
  }
  // ...
  if (some_cond) {
    lifetime.end(&tmp);
  }

... for a full-expression containing a subexpression of the form `some_cond ?
Tmp().x : 0`. This patch moves the lifetime start for such a temporary out of
the conditional branch so that we don't need to generate an additional basic
block to hold the lifetime end marker.

This is disabled if we want precise lifetime markers (for asan's
stack-use-after-scope checks) or of the temporary has a non-trivial destructor
(in which case we'd generate an extra basic block anyway to hold the destructor
call).

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

llvm-svn: 338945

Summary:
Added corpus of arrays to use as inputs for the functions. Check that the two
functions modify the inputted arrays in the same way.

Reviewers: kcc, morehouse

Reviewed By: morehouse

Subscribers: mgorny, cfe-commits, llvm-commits

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

llvm-svn: 338943

llvm-svn: 338942

__builtin_memmove (in non-type-punning cases).

This is intended to permit libc++ to make std::copy etc constexpr
without sacrificing the optimization that uses memcpy on
trivially-copyable types.

__builtin_strcpy and __builtin_wcscpy are not handled by this change.
They'd be straightforward to add, but we haven't encountered a need for
them just yet.

This reinstates r338455, reverted in r338602, with a fix to avoid trying
to constant-evaluate a memcpy call if either pointer operand has an
invalid designator.

llvm-svn: 338941