update upcoming meeting issue status

llvm-svn: 352339

[AArch64][GlobalISel] Add some missing vector support for FP arithmetic ops.

Moved the fneg lowering legalization test from AArch64 to X86, as we want to
specify that it's already legal.

llvm-svn: 352338

[AArch64][GlobalISel] Add some vector support for fp <-> int conversions.

Some unrelated, but benign, test changes as well due to the test update script.

llvm-svn: 352337

[LLD][COFF] Partial sections

Persist (input) sections that make up an OutputSection. This is a supporting patch for the upcoming D54802.

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

llvm-svn: 352336

Make more allocator methods work correctly with in an out-of-process mode.

Summary:
This makes `GetBlockBegin()` and `GetBlockBeginFastLocked()` work correctly with `RemoteAddressSpaceView`.

This has a knock on effect of also making the `PointerIsMine()` and
`GetMetaData()` methods behave correctly when `RemoteAddressSpaceView`
is used to instantiate the allocators.

This will be used by future out-of-process allocator enumeration
patches.

rdar://problem/45284065

Reviewers: kcc, vitalybuka, dvyukov, cryptoad, eugenis, george.karpenkov, yln

Subscribers: #sanitizers, llvm-commits, kubamracek

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

llvm-svn: 352335

GlobalISel: Don't reduce elements for atomic load/store

This is invalid for the same reason as in the narrowScalar handling
for load.

llvm-svn: 352334

[x86] add restriction for lowering to vpermps

This transform was added with rL351346, and we had
an escape for shufps, but we also want one for
unpckps vs. vpermps because vpermps doesn't take
an immediate shuffle index operand.

llvm-svn: 352333

GlobalISel: Factor fewerElementVectors into separate functions

llvm-svn: 352332

[x86] add tests for extract/extract/unpack; NFC

llvm-svn: 352331

[X86][SSE] Add UNDEF handling to combineSelect ISD::USUBSAT matching (PR40083)

llvm-svn: 352330

[X86][SSE] Add UNDEF test case for combineSelect ISD::USUBSAT matching (PR40083)

llvm-svn: 352329

[X86][SSE] Permit UNDEFs in combineAddToSUBUS matching (PR40083)

llvm-svn: 352328

[x86] add more tests for lowerShuffleWithUndefHalf; NFC

Some other transform is creating the opposite form and causing
an infinite loop if we try to split some of these.

llvm-svn: 352327

[X86][SSE] Add PSUBUS undef element test case (PR40083)

llvm-svn: 352326

[COFF] Add support for the new relocation IMAGE_REL_ARM{,64}_REL32

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

llvm-svn: 352325

[COFF] Add new relocation types.

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

llvm-svn: 352324

[SemaCXX] Fix ICE with structure bindings to members of template

Summary:
Trying to use structure binding with a structure that doesn't implement
std::tuple_size, should unpack the data members. When the struct is a
template though, clang might hit an assertion (if the type has not been
completed before), because CXXRecordDecl::DefinitionData is nullptr.

This commit fixes the problem by completing the type while trying to
decompose the structured binding.

The ICE happens in real world code, for example, when trying to iterate
a protobuf generated map with a range-based for loop and structure
bindings (because google::protobuf::MapPair is a template and doesn't
support std::tuple_size).

Reported-by: nicholas.sun@nlsun.com
Patch by Daniele Di Proietto

Reviewers: #clang, rsmith

Reviewed By: #clang, rsmith

Subscribers: cpplearner, Rakete1111, cfe-commits

Tags: #clang

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

llvm-svn: 352323

Fix some warnings on MSVC

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

llvm-svn: 352322

[X86] Add test cases for PR36721 (unnecessary andl for %cl when shifting)

llvm-svn: 352321

[x86] refactor logic in lowerShuffleWithUndefHalf

Although this is longer code, this is no-functional-change-intended.
The goal is to untangle the conditions under which we bail out, so
that's easier to adjust.

llvm-svn: 352320

GlobalISel: Verify load/store has a pointer input

I expected this to be automatically verified, but it seems
nothing uses that the type index was declared as a "ptype"

llvm-svn: 352319

[X86][NFC] Replace "<%s" with "< %s" in run-lines.

While i have no intention of actually commiting regeneration
of the check lines in these test files with update_llc_test_checks,
lack of that whitespace breaks that util, which is mildly inconvenient.

llvm-svn: 352318

[NFC][MCA][X86][BdVer2] Cherry-pick int-to-ivec forwarding tests from BtVer2

llvm-svn: 352317

[X86] Add CGP tests for PR40486

llvm-svn: 352316

[TTI] Add generic SADDSAT/SSUBSAT costs

Add generic costs calculation for SADDSAT/SSUBSAT intrinsics, this uses generic costs for sadd_with_overflow/ssub_with_overflow, an extra sign comparison + a selects based on the sign/overflow.

This completes PR40316

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

llvm-svn: 352315

[X86] Regenerate reverse branch test to explicitly show branching and condition codes.

llvm-svn: 352314

[X86] Regenerate test to explicitly show branching and condition codes.

llvm-svn: 352313

Re-apply "r351584: "GlobalISel: Verify g_zextload and g_sextload""

I reverted it originally due to a bot failing. The underlying bug has been fixed
as of r352311.

llvm-svn: 352312

[AArch64][GlobalISel] Fix the G_EXTLOAD combiner creating non-extending illegal instructions.

This fixes loads like 's1 = load %p (load 1 from %p)' being combined with an
extend into an illegal 's8 = g_extload %p (load 1 from %p)' which doesn't do any
extension, by avoiding touching those < s8 size loads.

This bug was uncovered by a verifier update r351584, which I reverted it to keep
the bots green.

llvm-svn: 352311

Revert "Add support for prefix-only CLI options"

This reverts commit r351038.

llvm-svn: 352310

Revert "Detect incorrect FileCheck variable CLI definition"

This reverts commit r351039.

llvm-svn: 352309

Revert "Fix defines.txt"

This reverts commit r351042.

llvm-svn: 352308

Remove Expr sugar decorating the CXXUuidofExpr node.

Summary: Sugar, like ConstantExpr, causes an infinite expansion of the template object.

Reviewers: rsmith, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: riccibruno, aaron.ballman, cfe-commits, tzik, rnk

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

llvm-svn: 352307

[X86] Add some missing blsr patterns

The add+and sequence followed by a branch can
happen e.g. when looping over the set bits of an integer:

```
while (x != 0) {
   func(x & ~x);
   x &= x - 1;
}
```

Reviewed By: ctopper

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

llvm-svn: 352306

[NFC][X86] Add a few more blsr test cases

llvm-svn: 352305

Follow-up to r352254: Initialize Selection field.

The diagnostic there fired spuriosly due to uninitialized memory.

llvm-svn: 352304

[X86] Add a pattern for (i64 (and (anyext def32:), 0x00000000FFFFFFFF)) to produce SUBREG_TO_REG

def32 here means the producing instruction zeroed bits 63:32. We already do this for zext, but it looks like we can get an and+anyext sometimes.

Spotted in the diffs from D33587.

llvm-svn: 352303

lld: elf: discard more specific .gnu.linkonce section

Summary:
lld discards .gnu.linonce.* sections work around a bug in glibc.
https://sourceware.org/bugzilla/show_bug.cgi?id=20543

Unfortunately, the Linux kernel uses a section named
.gnu.linkonce.this_module to store infomation about kernel modules. The
kernel reads data from this section when loading kernel modules, and
errors if it fails to find this section. The current behavior of lld
discards this section when kernel modules are linked, so kernel modules
linked with lld are unloadable by the linux kernel.

The Linux kernel should use a comdat section instead of .gnu.linkonce.
The minimum version of binutils supported by the kernel supports comdat
sections. The kernel is also not relying on the old linkonce behavior;
it seems to have chosen a name that contains a deprecated GNU feature.

Changing the section name now in the kernel would require all kernel
modules to be recompiled to make use of the new section name. Instead,
rather than discarding .gnu.linkonce.*, let's discard the more specific
section name to continue working around the glibc issue while supporting
linking Linux kernel modules.

Link: https://github.com/ClangBuiltLinux/linux/issues/329
Reviewers: pcc, espindola

Reviewed By: pcc

Subscribers: nathanchance, emaste, arichardson, void, srhines

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

llvm-svn: 352302

GlobalISel: Fix typo in assert messages

llvm-svn: 352301

GlobalISel: Implement narrowScalar for mul

llvm-svn: 352300

[FIX] Adjust CXX microsoft abi dynamic cast test to r352293

llvm-svn: 352299

GlobalISel: fewerElementsVector for intrinsic_trunc/intrinsic_round

llvm-svn: 352298

AMDGPU/GlobalISel: Use scalarize instead of clampMaxNumElements

llvm-svn: 352297

[GlobalISel][IRTranslator] Fix crash on translation of fneg.

When the fneg IR instruction was added the code to do translation wasn't
tested, and tried to get an invalid operand.

llvm-svn: 352296

AMDGPU/GlobalISel: Legalize more bit ops

llvm-svn: 352295

AMDGPU/GlobalISel: Widen small uaddo/usubo

llvm-svn: 352294

[ValueTracking] Look through casts when determining non-nullness

Bitcast and certain Ptr2Int/Int2Ptr instructions will not alter the
value of their operand and can therefore be looked through when we
determine non-nullness.

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

llvm-svn: 352293

[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker

This patch effectively fixes the almost decade old checker naming issue.
The solution is to assert when CheckerManager::getChecker is called on an
unregistered checker, and assert when CheckerManager::registerChecker is called
on a checker that is already registered.

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

llvm-svn: 352292

[X86] combineAddOrSubToADCOrSBB/combineCarryThroughADD - use oneuse for entire SDNode

Fix issue noted in D57281 that only tested the one use for the SDValue (the result flag), not the entire SUB.

I've added the getNode() to make it clearer what is intended than just the -> redirection.

llvm-svn: 352291

Fix a lit test failure after D54438

llvm-svn: 352290

[X86] combineCarryThroughADD - add support for X86::COND_A commutations (PR24545)

As discussed on PR24545, we should try to commute X86::COND_A 'icmp ugt' cases to X86::COND_B 'icmp ult' to more optimally bind the carry flag output to a SBB instruction.

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

llvm-svn: 352289

[X86] Fold X86ISD::SBB(ISD::SUB(X,Y),0) -> X86ISD::SBB(X,Y) (PR25858)

We often generate X86ISD::SBB(X, 0) for carry flag arithmetic.

I had tried to create test cases for the ADC equivalent (which often uses the same pattern) but haven't managed to find anything yet.

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

llvm-svn: 352288

[analyzer] Reimplement dependencies between checkers

Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.

Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.

Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.

This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.

In detail:

* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
  - StackAddrEscapeBase
  - StackAddrEscapeBase
  - CStringModeling
  - DynamicMemoryModeling (base of the MallocChecker family)
  - IteratorModeling (base of the IteratorChecker family)
  - ValistBase
  - SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
  - NSOrCFErrorDerefChecker (base of NSErrorChecker and  CFErrorChecker)
  - IvarInvalidationModeling (base of IvarInvalidation checker family)
  - RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.

Big thanks to Artem Degrachev for all the guidance through this project!

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

llvm-svn: 352287

Generate test results for combine-fcopysign.ll using update_llc_test_checks.py . NFC

llvm-svn: 352285

[analyzer] Fix an bug where statically linked, but not registered checkers weren't recognized

My last patch, D56989, moved the validation of whether a checker exists into
its constructor, but we do support statically linked (and non-plugin) checkers
that were do not have an entry in Checkers.td. However, the handling of this
happens after the creation of the CheckerRegistry object.

This patch fixes this bug by moving even this functionality into
CheckerRegistry's constructor.

llvm-svn: 352284

[X86][SSE] Generalized unsigned compares to support nonsplat constant vectors (PR39859)

llvm-svn: 352283

[analyzer][NFC] Keep track of whether enabling a checker was explictly specified in command line arguments

I added a new enum to CheckerInfo, so we can easily track whether the check is
explicitly enabled, explicitly disabled, or isn't specified in this regard.
Checkers belonging in the latter category may be implicitly enabled through
dependencies in the followup patch. I also made sure that this is done within
CheckerRegisty's constructor, leading to very significant simplifications in
its query-like methods.

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

llvm-svn: 352282

[X86] Add nonsplat increment/decrement constant vector with min/max test (PR39859)

llvm-svn: 352281

[x86] add helper for creating a half-width shuffle; NFC

This reduces a bit of duplication between the combining and
lowering places that use it, but the primary motivation is
to make it easier to rearrange the lowering logic and solve
PR40434:
https://bugs.llvm.org/show_bug.cgi?id=40434

llvm-svn: 352280

[analyzer][NFC] Supply CheckerRegistry with AnalyzerOptions

Since pretty much all methods of CheckerRegistry has AnalyzerOptions as an
argument, it makes sense to just simply require it in it's constructor.

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

llvm-svn: 352279

[analyzer] Split unix.API up to UnixAPIMisuseChecker and UnixAPIPortabilityChecker

The actual implementation of unix.API features a dual-checker: two checkers in
one, even though they don't even interact at all. Split them up, as this is a
problem for establishing dependencies.

I added no new code at all, just merely moved it around.

Since the plist files change (and that's a benefit!) this patch isn't NFC.

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

llvm-svn: 352278

[analyzer] Supply all checkers with a shouldRegister function

Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO)
function very similarly to ento::register##CHECKERNAME. This will force every
checker to implement this function, but maybe it isn't that bad: I saw a lot of
ObjC or C++ specific checkers that should probably not register themselves based
on some LangOptions (mine too), but they do anyways.

A big benefit of this is that all registry functions now register their checker,
once it is called, registration is guaranteed.

This patch is a part of a greater effort to reinvent checker registration, more
info here: D54438#1315953

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

llvm-svn: 352277

[AST] Pack GenericSelectionExpr

Store the controlling expression, the association expressions and the
corresponding TypeSourceInfos as trailing objects.

Additionally use the bit-fields of Stmt to store one SourceLocation,
saving one additional pointer. This saves 3 pointers in total per
GenericSelectionExpr.

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

Reviewed By: aaron.ballman

Reviewers: aaron.ballman, steveire
llvm-svn: 352276

[AST][NFC] Various cleanups to GenericSelectionExpr

Various cleanups to GenericSelectionExpr factored out of D57104. In particular:

1. Move the friend declaration to the top.
2. Introduce a constant ResultDependentIndex instead of the magic "-1".
3. clang-format
4. Group the member function together so that they can be removed as one block
   by D57106.

NFC.

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

Reviewed By: aaron.ballman

llvm-svn: 352275

[X86] Add test case from PR34292

llvm-svn: 352274

[llvm-mca][X86] Add some missing DQI tests

Match more of the coverage of test\CodeGen\X86\avx512-schedule.ll as discussed on D57244

llvm-svn: 352273

[X86] Add 'less_than_ideal' followup test case from PR24545

llvm-svn: 352272

[X86] Autoupgrade some of the intrinsics used by stack folding tests that have been previously removed.

llvm-svn: 352271

[X86] Remove and autoupgrade vpconflict intrinsics that take a mask and passthru argument.

We have unmasked versions as of r352172

llvm-svn: 352270

Revert r352255 "[SelectionDAG][X86] Don't use SEXTLOAD for promoting masked loads in the type legalizer"

This might be breaking an lldb windows buildbot.

llvm-svn: 352268

[X86] Custom codegen 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics.

Summary:
The 512-bit cvt(u)qq2tops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics all have the possibility of taking an explicit rounding mode argument. If the rounding mode is CUR_DIRECTION we'd like to emit a sitofp/uitofp instruction and a select like we do for 256-bit intrinsics.

For cvt(u)qqtopd and cvt(u)dqtops we do this when the form of the software intrinsics that doesn't take a rounding mode argument is used. This is done by using convertvector in the header with the select builtin. But if the explicit rounding mode form of the intrinsic is used and CUR_DIRECTION is passed, we don't do this. We shouldn't have this inconsistency.

For cvt(u)qqtops nothing is done because we can't use the select builtin in the header without avx512vl. So we need to use custom codegen for this.

Even when the rounding mode isn't CUR_DIRECTION we should also use select in IR for consistency. And it will remove another scalar integer mask from our intrinsics.

To accomplish all of these goals I've taken a slightly unusual approach. I've added two new X86 specific intrinsics for sitofp/uitofp with rounding. These intrinsics are variadic on the input and output type so we only need 2 instead of 6. This avoids the need for a switch to map them in CGBuiltin.cpp. We just need to check signed vs unsigned. I believe other targets also use variadic intrinsics like this.

So if the rounding mode is CUR_DIRECTION we'll use an sitofp/uitofp instruction. Otherwise we'll use one of the new intrinsics. After that we'll emit a select instruction if needed.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: cfe-commits

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

llvm-svn: 352267

[X86] Remove GCCBuiltins from 512-bit cvt(u)qqtops, cvt(u)qqtopd, and cvt(u)dqtops intrinsics. Add new variadic uitofp/sitofp with rounding mode intrinsics.

Summary: See clang patch D56998 for a full description.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 352266

[libFuzzer] add CompressedTest.cpp, a real-life-ish test for a custom mutator

llvm-svn: 352265

GlobalISel: Fix address space limit in LLT

The IR enforced limit for the address space is 24-bits, but LLT was
only using 23-bits. Additionally, the argument to the constructor was
truncating to 16-bits.

A similar problem still exists for the number of vector elements. The
IR enforces no limit, so if you try to use a vector with > 65535
elements the IRTranslator asserts in the LLT constructor.

llvm-svn: 352264

[libFuzzer] print uncovered functions when doing -print_coverage=1

llvm-svn: 352263

[WebAssembly][NFC] Group SIMD-related ISel configuration

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish

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

llvm-svn: 352262

[PowerPC] Update Vector Costs for P9

For the power9 CPU, vector operations consume a pair of execution units rather
than one execution unit like a scalar operation. Update the target transform
cost functions to reflect the higher cost of vector operations when targeting
Power9.

Patch by RolandF.

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

llvm-svn: 352261

[X86] Add DAG combine to merge vzext_movl with the various fp<->int conversion operations that only write the lower 64-bits of an xmm register and zero the rest.

Summary: We have isel patterns for this, but we're missing some load patterns and all broadcast patterns. A DAG combine seems like a better fit for this.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 352260

[lldb] Update shebang python2 -> python

llvm-svn: 352259

[llvm-nm] Print out N_COLD_FUNC as "cold func"

Per post-commit feedback from Mike, have llvm-nm print out this symbol
attribute as "[cold func]".

llvm-svn: 352258

Remove dead declaration.

llvm-svn: 352257

[NVPTX] Some nvvm.read.ptx.sreg intrinsics should have IntrInaccessibleMemOnly attribute.

These intrinsics may return different values every time they are called
and should not be CSE'd. IntrInaccessibleMemOnly appears to be the right
attribute to model this behavior.

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

llvm-svn: 352256

[SelectionDAG][X86] Don't use SEXTLOAD for promoting masked loads in the type legalizer

Summary:
I'm not sure why we were using SEXTLOAD. EXTLOAD seems more appropriate since we don't care about the upper bits.

This patch changes this and then modifies the X86 post legalization combine to emit a extending shuffle instead of a sign_extend_vector_inreg. Could maybe use an any_extend_vector_inreg, but I just did what we already do in LowerLoad. I think we can actually get rid of this code entirely if we switch to -x86-experimental-vector-widening-legalization.

On AVX512 targets I think we might be able to use a masked vpmovzx and not have to expand this at all.

Reviewers: RKSimon, spatel

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 352255

lld-link: Store comdat selection in SectionChunk, reject more invalid associated comdats

I need the comdat selection for PR40094. To keep the patch for that smaller,
I'm adding it here, and as a first application I'm using it to reject
associative comdats referring to earlier associative comdats. Depends on
D56929; together with that all associative comdats referring to other
associative comdats are now rejected.

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

llvm-svn: 352254

Attempt to fix build on Windows with LLVM_ENABLE_PIC=OFF

libclang can be built in shared or static mode. On Windows, with
LLVM_ENABLE_PIC=OFF, it was built in neither mode, leading to clients of
libclang (c-index-test, c-arcmt-test) failing to link with it set.

Since PIC isn't really a thing on Windows, build libclang in shared mode when
LLVM_ENABLE_PIC=OFF there. This is also somewhat symmetric with the existing
ENABLE_STATIC a few lines down.

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

llvm-svn: 352253

Fixed frontend clang tests in windows read-only container

Summary:
When mounting LLVM source into a windows container in read-only mode, certain tests fail. Ideally, we want all these tests to pass so that developers can mount the same source folder into multiple (windows) containers simultaneously, allowing them to build/test the same source code using various different configurations simultaneously.

**Fix**: I've found that when attempting to open a file for writing on windows, if you don't have the correct permissions (trying to open a file for writing in a read-only folder), you get [Access is denied](https://support.microsoft.com/en-us/help/2623670/access-denied-or-other-errors-when-you-access-or-work-with-files-and-f). In llvm, we map this error message to a linux based error, see: https://github.com/llvm-mirror/llvm/blob/master/lib/Support/ErrorHandling.cpp

This is why we see "Permission denied" in our output as opposed to the expected "No such file or directory", thus causing the tests to fail.

I've changed the test locally to instead point to the root drive so that they can successfully bypass the Access is denied error when LLVM is mounted in as a read-only directory. This way, the test operate exactly the same, but we can get around the windows-complications of what error to expect in a read-only directory.

Patch By: justice_adams

Reviewers: rsmith, zturner, MatzeB, stella.stamenova

Reviewed By: stella.stamenova

Subscribers: ormris, cfe-commits

Tags: #clang

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

llvm-svn: 352252

Build LLVM-C.dll by default on windows and enable in release package

With the fixes to the building of LLVM-C.dll in D56781 this should now
be safe to land. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.

Patch by Jakob Bornecrantz!

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

llvm-svn: 352250

Simplify LangOpts initalization in ClangExpressionParser [NFC]

Reviewers: davide

Reviewed By: davide

Subscribers: shafik, davide, lldb-commits

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

llvm-svn: 352249

  [NFC] Test commit : fix typo.

llvm-svn: 352248

[RISCV] Add target DAG combine for bitcast fabs/fneg on RV32FD

DAGCombiner::visitBITCAST will perform:
 fold (bitconvert (fneg x)) -> (xor (bitconvert x), signbit)
 fold (bitconvert (fabs x)) -> (and (bitconvert x), (not signbit))

As shown in double-bitmanip-dagcombines.ll, this can be advantageous. But
RV32FD doesn't use bitcast directly (as i64 isn't a legal type), and instead
uses RISCVISD::SplitF64. This patch adds an equivalent DAG combine for
SplitF64.

llvm-svn: 352247

[llvm] Opt-in flag for X86DiscriminateMemOps

Summary:
Currently, if an instruction with a memory operand has no debug information,
X86DiscriminateMemOps will generate one based on the first line of the
enclosing function, or the last seen debug info.

This may cause confusion in certain debugging scenarios. The long term
approach would be to use the line number '0' in such cases, however, that
brings in challenges: the base discriminator value range is limited
(4096 values).

For the short term, adding an opt-in flag for this feature.

See bug 40319 (https://bugs.llvm.org/show_bug.cgi?id=40319)

Reviewers: dblaikie, jmorse, gbedwell

Reviewed By: dblaikie

Subscribers: aprantl, eraman, hiraditya

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

llvm-svn: 352246

[libunwind] Use placement new to avoid dependency C++ library

The rest of libunwind already uses placement new, these are the only
places where non-placement new is being used introducing undesirable
C++ library dependency.

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

llvm-svn: 352245

[GlobalISel][AArch64][NFC] Fix incorrect comment in selectUnmergeValues

s/scalar/vector/

llvm-svn: 352243

Simplify. NFC.

llvm-svn: 352242

Revert rL352238.

llvm-svn: 352241

[RISCV] Add another potential combine to {double,float}-bitmanip-dagcombines.ll

(fcopysign a, (fneg b)) will be expanded to bitwise operations by
DAGTypeLegalizer::SoftenFloatRes_FCOPYSIGN if the floating point type isn't
legal. Arguably it might be worth doing a combine even if it is legal.

llvm-svn: 352240

[Sema] Improve a -Warray-bounds diagnostic

Fix a bug where we would compare array sizes with incompatible
element types, and look through explicit casts.

rdar://44800168

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

llvm-svn: 352239

[WarnMissedTransforms] Set default to 1.

Summary:
Set default value for retrieved attributes to 1, since the check is against 1.
Eliminates the warning noise generated when the attributes are not present.

Reviewers: sanjoy

Subscribers: jlebar, llvm-commits

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

llvm-svn: 352238

Reapply: [RISCV] Set isAsCheapAsAMove for ADDI, ORI, XORI, LUI

This reapplies commit r352010 with RISC-V test fixes.

llvm-svn: 352237

[MBP] Don't move bottom block before header if it can't reduce taken branches

If bottom of block BB has only one successor OldTop, in most cases it is profitable to move it before OldTop, except the following case:

-->OldTop<-
|    .    |
|    .    |
|    .    |
---Pred   |
     |    |
    BB-----

Move BB before OldTop can't reduce the number of taken branches, this patch detects this case and prevent the moving.

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

llvm-svn: 352236