Reviewers: chandlerc, beanz, mgorny

Reviewed By: beanz

Subscribers: llvm-commits

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

llvm-svn: 302025

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

llvm-svn: 302024

VFPCLASS is for vector types and not scalar, so it cannot get here.

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

llvm-svn: 302023

It is needed to check that the number of operands are 2 when
finding the case of a logic combination, e.g. 'and' of two compares.

Review: Ulrich Weigand
llvm-svn: 302022

- Fixes breakage from commit 5536f.
- Interference with commit 764f3 caused testcase to fail. Reverting
  764f3 allows commit 5536f to succeed.
- Generated kernel code was slightly different due to 764f3, which
  caused testcase to fail.

llvm-svn: 302021

This patch implements the LLVM part for no_caller_saved_registers attribute as appears here: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5ed3cc7b66af4758f7849ed6f65f4365be8223be.
In order to implement the attribute, we use the dynamic CSR mechanism to remove returned/passed arguments from the function regmask/CSR list.

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

llvm-svn: 302020

Fixes PR31789 - When loop-vectorize tries to use these intrinsics for a
non-default address space pointer we fail with a "Calling a function with a
bad singature!" assertion. This patch solves this by adding the 'vector of
pointers' argument as an overloaded type which will determine the address
space.

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

llvm-svn: 302018

llvm-svn: 302017

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

llvm-svn: 302016

Summary:
Currently, loop deletion deletes loop where the only values
that are used outside the loop are loop-invariant.
This patch adds logic to delete loops where the loop is proven to be
never executed (i.e. the only predecessor of the loop preheader has a
constant conditional branch as terminator, and the preheader is not the
taken target). This will remove loops that become dead after
loop-unswitching generates constant conditional branches.

The next steps are:
1. moving the loop deletion implementation to LoopUtils.
2. Add logic in loop-simplifyCFG which will support changing conditional
constant branches to unconditional branches. If loops become unreachable in this
process, they can be removed using `deleteDeadLoop` function.

Reviewers: chandlerc, efriedma, sanjoy, reames

Reviewed by: sanjoy

Subscribers: mzolotukhin, llvm-commits

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

llvm-svn: 302015

This reverts commit 358ad02d999e88853d2cfc954bd2f668308a51f7.

llvm-svn: 302014

gnuwin32 rm does not like wildcards that match nothing even if we
specify -f (probably because the wildcard expansion happens in-process
there). We could use make $(wildcard) here, but it seems safer to
explicitly list the files here, just like the normal Makefile.rules
does.

llvm-svn: 302013

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

llvm-svn: 302012

The "macosx" OS type is still the canonical type. In the future "macos" will
become the canonical OS type (but we will still support "macosx").

rdar://27043820

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

llvm-svn: 302011

Pre-commit as requested in D32769.

llvm-svn: 302010

These were relying on the attribute group numbering

llvm-svn: 302009

Summary: It seems that if we have no context, then it can't possibly be a method.  Check that first.

Reviewers: clayborg

Reviewed By: clayborg

Subscribers: labath, lldb-commits

Differential Revision: https://reviews.llvm.org/D32708
Patch by Scott Smith <scott.smith@purestorage.com>.

llvm-svn: 302008

The --section-start <name>=<address> needs to be translated into equivalent
linker script commands. There are a couple of problems with the existing
implementation:
- The --section-start with the lowest address is assumed to be at the start
of the map. This assumption is incorrect, we have to iterate through the
SectionStartMap to find the lowest address.
- The addresses in --section-start were being over-aligned when the
sections were marked as PageAlign. This is inconsistent with the use of
SectionStartMap in fixHeaders(), and can cause problems when the PageAlign
causes an "unable to move location counter backward" error when the
--section-start with PageAlign is aligned to an address higher than the next
--section-start. The ld.bfd and ld.gold seem to be more consistent with this
approach but this is not a well specified area.
    
This change fixes the problems above and also corrects a typo in which
fabricateDefaultCommands() is called with the wrong parameter, it should be
called with AllocateHeader not Config->MaxPageSize.

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

llvm-svn: 302007

Before rL301170 was landed, LLD did not produce correct entries in .gdb_index address area.
Issue was fixed on LLVM DWARF parsers side and was relative to how .debug_ranges
section was scanned. It was main problem of PR32319.

It makes sense to have testcase on LLD size too. This checks that we generate proper values 
now, because we do not have any tests for .gdb_index which works with .debug_ranges atm.

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

llvm-svn: 302006

llvm-svn: 302005

Before this change a memory reference identifier had the form:

  <STMT>_<ACCESSTYPE><ID>_<MEMREF>, e.g., Stmt_bb9_Write0_MemRef_tmp11

After this change, we use the format:

  <STMT>_<ACCESSTYPE><ID>, e.g., Stmt_bb9_Write0

The name of the array that is accessed through a memory reference is not
necessary to uniquely identify a memory reference, but was only added to
provide additional information for debugging. We drop this information now
for the following two reasons:

  1) This shortens the names and consequently improves readability
  2) This removes a second location where we decide on the name of a scop array,
     leaving us only with the location where the actual scop array is created.

Having after 2) only a single location to name scop arrays will allow us to
change the naming convention of scop arrays more easily, which we will do
in a future commit to reduce compilation time.

llvm-svn: 302004

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

llvm-svn: 302003

The patch is failing to add StringTableStreamBuilder.h, but that isn't
even discovered because the corresponding StringTableStreamBuilder.cpp
isn't added to any CMakeLists.txt file and thus never built. I think
this patch is just incomplete.

llvm-svn: 302002

This patch addresses https://github.com/google/sanitizers/issues/804.
Users can use mcheck and mprobe functions to verify heap state so we should intercept them to avoid breakage of valid code.

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

llvm-svn: 302001

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

llvm-svn: 302000

This was reported by the ASAN bot, and it turned out to be
a fairly fundamental problem with the design of VarStreamArray
and the way it passes context information to the extractor.

The fix was cumbersome, and I'm not entirely pleased with it,
so I plan to revisit this design in the future when I'm not
pressed to get the bots green again.  For now, this fixes
the issue by storing the context information by value instead
of by reference, and introduces some impossibly-confusing
template magic to make things "work".

llvm-svn: 301999

-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

llvm-svn: 301998

These were relying on the attribute group numbering

llvm-svn: 301996

No change in which intrinsics should be speculated.

llvm-svn: 301995

llvm-svn: 301994

Also added a test case, thanks to Greg Clayton.

<rdar://problem/18913551>

llvm-svn: 301993

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.

llvm-svn: 301992

We should always expect values to be named before running the module summary
analysis (see NameAnonGlobals pass), so it's fine if we crash in that case.

llvm-svn: 301991

Summary:
This is the corresponding llvm change to D28037 to ensure no performance
regression.

Reviewers: bogner, kbarton, hfinkel, iteratee, echristo

Subscribers: nemanjai, llvm-commits

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

llvm-svn: 301990

llvm-svn: 301989

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.

llvm-svn: 301988

llvm-svn: 301987

Previously we had knowledge of how to serialize and deserialize
a string table inside of DebugInfo/PDB, but the string table
that it serializes contains a piece that is actually considered
CodeView and can appear outside of a PDB.  We already have logic
in llvm-readobj and MCCodeView to read and write this format,
so it doesn't make sense to duplicate the logic in DebugInfoPDB
as well.

This patch makes codeview::StringTable (for writing) and
codeview::StringTableRef (for reading), updates DebugInfoPDB
to use these classes for its own writing, and updates llvm-readobj
to additionally use StringTableRef for reading.

It's a bit more difficult to get MCCodeView to use this for
writing, but it's a logical next step.

llvm-svn: 301986

llvm-svn: 301985

This patch verifies the .debug_line:
- verify all addresses in a line table sequence have ascending addresses
- verify that all line table file indexes are valid

Unit tests added for both cases.

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

llvm-svn: 301984