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

When we replaced the multiplicand the destination node might already exist.
When that happens the original gets CSEd and deleted. However, it's actually
used as the offset so nonsense is produced.

Should fix PR32726.

llvm-svn: 301983

llvm-svn: 301982

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

This reverts r301712.

llvm-svn: 301981

Remove "_NC" suffix and semantics from TLSDESC_LD{64,32}_LO12 and
  TLSDESC_ADD_LO12 relocations
Rearrange ordering in AArch64.def to follow relocation encoding
Fix name:
  R_AARCH64_P32_LD64_GOT_LO12_NC => R_AARCH64_P32_LD32_GOT_LO12_NC
Add support for several "TLS", "TLSGD", and "TLSLD" relocations for
  ILP32
Fix return values from isNonILP32reloc
Add implementations for
  R_AARCH64_ADR_PREL_PG_HI21_NC, R_AARCH64_P32_LD32_GOT_LO12_NC,
  R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC,
  R_AARCH64_P32_TLSDESC_LD32_LO12, R_AARCH64_LD64_GOT_LO12_NC,
  *TLSLD_LDST128_DTPREL_LO12, *TLSLD_LDST128_DTPREL_LO12_NC,
  *TLSLE_LDST128_TPREL_LO12, *TLSLE_LDST128_TPREL_LO12_NC
Modify error messages to give name of equivalent relocation in the
  ABI not being used, along with better checking for non-existent
  requested relocations.
Added assembler support for "pg_hi21_nc"
Relocation definitions added without implementations:
  R_AARCH64_P32_TLSDESC_ADR_PREL21, R_AARCH64_P32_TLSGD_ADR_PREL21,
  R_AARCH64_P32_TLSGD_ADD_LO12_NC, R_AARCH64_P32_TLSLD_ADR_PREL21, 
  R_AARCH64_P32_TLSLD_ADR_PAGE21, R_AARCH64_P32_TLSLD_ADD_LO12_NC,
  R_AARCH64_P32_TLSLD_LD_PREL19, R_AARCH64_P32_TLSDESC_LD_PREL19,
  R_AARCH64_P32_TLSGD_ADR_PAGE21, R_AARCH64_P32_TLS_DTPREL,
  R_AARCH64_P32_TLS_DTPMOD, R_AARCH64_P32_TLS_TPREL,
  R_AARCH64_P32_TLSDESC
Fix encoding:
  R_AARCH64_P32_TLSDESC_ADR_PAGE21

Reviewers: Peter Smith

Patch by: Joel Jones (jjones@cavium.com)

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

llvm-svn: 301980

llvm-svn: 301979

The directory and file tables now have form-based content descriptors.
Parse these and extract the per-directory/file records based on the
descriptors.  For now we support only DW_FORM_string (inline) for the
path names; follow-up work will add support for indirect forms (i.e.,
DW_FORM_strp, strx<N>, and line_strp).

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

llvm-svn: 301978

Turns out this wasn't NFC-ish at all because there's a bug processing shuffles
that change the size of their input vectors (that case always seems to trip us
up). 

This should fix PR32872 while we investigate how it failed and reduce a testcase:
https://bugs.llvm.org/show_bug.cgi?id=32872
 

llvm-svn: 301977

llvm-svn: 301976

llvm-svn: 301975

llvm-svn: 301974

- 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 )

llvm-svn: 301973

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.

 

llvm-svn: 301972

LTO and other fancy linking previously led to DWARF that contained invalid references. We already validate that CU relative references fall into the CU, and the DW_FORM_ref_addr references fall inside the .debug_info section, but we didn't validate that the references pointed to correct DIE offsets. This new verification will ensure that all references refer to actual DIEs and not an offset in between.

This caught a bug in DWARFUnit::getDIEForOffset() where if you gave it any offset, it would match the DIE that mathes the offset _or_ the next DIE. This has been fixed.

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

llvm-svn: 301971

llvm-svn: 301970

This reverts commit r301964. It broke the build.

llvm-svn: 301969

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

llvm-svn: 301968

llvm-svn: 301967

This patch marks a few ASan tests as unsupported on iOS. These are mostly tests that use files or paths that are invalid/inaccessible on iOS or the simulator. We currently don't have a good way of propagating/copying secondary files that individual tests need. The same problem exists on Android, so I'm just marking the tests as UNSUPPORTED now.

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

llvm-svn: 301966

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

llvm-svn: 301965