D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.

This reverts commit 5956648f.
There was a string lifetime issue that is now corrected.

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

Rename warn_drv_overriding_flag_option (-Woverriding-t-option) to warn_drv_overriding_flag_option (-Woverriding-option)

warn_drv_overriding_flag_option was added for clang-cl `/T*` options (D1290) and its group name was planned to be renamed to overriding-option.
The name -Woverriding-t-option does not make sense for other uses,
mostly related to -ffp-model= related diagnostics.

Reviewed By: hans, skan, dexonsmith

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

This is a partial revert of https://reviews.llvm.org/D157837 - it turns
out that the LLVM test suite needs to be updated first not to use any of
the unsupported Flang options:
  * https://github.com/llvm/llvm-test-suite
Sample errors:
```
flang-new: error: unknown argument: '-fbounds-check'
flang-new: error: unknown argument: '-fcheck=all'
flang-new: error: unknown argument: '-fcheck-array-temporaries'
```

Once the test suite is updated, we can restore the reverted setting.

Broken bot:
  * https://lab.llvm.org/buildbot/#/builders/197/builds/9001

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

This is the next preparation patch to support widenable conditions
widening instead of branches widening.

We've added parseWidenableGuard util which parses guard condition and
collects all checks existing in the expression tree: D157276

Here we are adding util which walks similar way through the expression
tree but looks up for widenable condition without collecting the checks.
Therefore llvm::extractWidenableCondition could parse widenable branches
with arbitrary position of widenable condition in the expression tree.

llvm::parseWidenableBranch which is we are going to get rid of is being
replaced by llvm::extractWidenableCondition where it's possible.

Reviewed By: anna

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

This prevents further parsing of tokens (that'll be freed) inside method
body by propagating EOF emitted by reaching code completion token up the parsing
stack.

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

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

[clang][AST] TextNodeDumper learned to output refers_to_enclosing_variable_or_capture flag for DeclRefExpr

Reviewed By: aaron.ballman

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

[X86] SimplifyDemandedBits - move MaskedValueIsZero as late as possible to avoid unnecessary (recursive) analysis costs. NFC.

Mentioned on D155472 for the SHL equivalent

[X86] foldMaskAndShiftToExtract - as long as we call insertDAGNode in the creation order then duplicates don't matter.

Reviewed By: arsenm

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

Missed in https://reviews.llvm.org/D157837.

Fixes:
  * https://lab.llvm.org/buildbot/#/builders/197/builds/8996/steps/13/logs/stdio

On macOS, files are usually below `/Users/...` and clang-cl treats
that as the `/U` flag followed by something instead of as a path.
Put `--` in front of `%s` to make it treat it as a patch, like in
all other tests.

The failure without this change:

    x86-no-gather-no-scatter.cpp:4:14: error: NOGATHER: expected string not found in input
    // NOGATHER: "-target-feature" "+prefer-no-gather"
                 ^
    <stdin>:5:44: note: possible intended match here
    clang: warning: 'x86-no-gather-no-scatter.cpp' treated as the '/U' option [-Wslash-u-filename]
                                               ^

This reverts commit 2e4d2d80.

Invalid checksums detected here:
https://lab.llvm.org/buildbot/#/builders/37/builds/24465

Check for invalid pass flags when running `-one-shot-bufferize` instead of crashing with a failed assertion.

This fixes #64267.

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

Remove `dangerousSetOptions` and call `promoteOperands` with the correct arguments directly.

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

[gn] port d5ca9004 (driver_execs for dsymutil, llvm-debuginfod, llvm-ml, llvm-objdump, llvm-symbolizer)

Despite being true positives, these results just confuse users. So
filter them out.

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

Currently after widening br(WC && (c1 && c2)) we insert assume of
(c1 && c2) which is joined to WC by And operation.
But we are going to support more flexible form of widenable branches
where WC could be placed arbitrary in the expression tree, e.g:
br(c1 && (c2 && WC)).
In that case we won't have (c1 && c2) in the IR. So we need to add
explicit (c1 && c2) and then create an assumption of it.

Reviewed By: anna

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

D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.

This reverts commit 21e7f734.
I'm unable to find a reason for the memory management issues
that caused the revert, so trying again.

Follow-up to D152959:
--debug-only= requires an asserts build.
The test also needs the x86 target.

We added support for the GNUstep ObjC runtime in 0b626473. In order to check if the target process uses
GNUstep we run an expensive symbol lookup in `CreateInstance()`. This turned out to cause a heavy performance
regression for non-GNUstep inferiors.

This patch puts a cheaper check in front, so that the vast majority of requests should return early. This
should fix the symptom for the moment. The conceptual question remains: Why does `LanguageRuntime::FindPlugin`
invoke `create_callback` for each available runtime unconditionally in every `Process::ModulesDidLoad`?

Reviewed By: jasonmolenda, jingham, bulbazord

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

When a function is declared in the same scope as a class with the same
name then the function hides that class. Currently this is done by a
single check after the main loop in LookupResult::resolveKind, but
this can give the wrong result when we have a using declaration in
multiple namespace scopes in two different ways:

 * When the using declaration is hidden in one namespace but not the
   other we can end up considering only the hidden one when deciding
   if the result is ambiguous, causing an incorrect "not ambiguous"
   result.

 * When two classes with the same name in different namespace scopes
   are both hidden by using declarations this can result in
   incorrectly deciding the result is ambiguous. There's currently a
   comment saying this is expected, but I don't think that's correct.

Solve this by checking each Decl to see if it's hidden by some other
Decl in the same scope. This means we have to delay removing anything
from Decls until after the main loop, in case a Decl is hidden by
another that is removed due to being non-unique.

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

Accidentally left review fixes out of the commit.

* Document the valid states: invalid/unset/pointer
  (Currently both documentation and implementation strongly suggest that
   pointer+invalid is poissible, when it's not)
* Remove unused set() functions, which had different semantics between the
  compressed/uncompressed specialization! (The former allowing escaping the
  tristate into pointer+invalid)
* Make the compressed specialization's internals directly model the tristate,
  rather than pretending pointer + invalid were independent.
* Make members of each version identical where possible, remove repetition
* fix operator= accidentally returning a const reference
* Fix indentation :-)

This was motivated by D157868, in which an experienced clang dev was
confused about the possible states for ExprResult - and I vividly
remember getting very confused about this myself.

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

[DAG] SimplifyDemandedBits - if we're only demanding the msb, a UMIN/UMAX node can be simplified to a AND/OR node respectively.

Alive2: https://alive2.llvm.org/ce/z/qnvmc6

Reviewed By: yassingh

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

This is a follow-up of https://reviews.llvm.org/D157837 in which I
missed a few Flang options in Options.td. This patch simply updates the
remaining options that are already supported by Flang with the relevant
visibility flag:

Fixes:
  * https://lab.llvm.org/buildbot/#/builders/191/builds/22241

[DAG] SimplifyDemandedBits - if we're only demanding the signbit, a SMIN/SMAX node can be simplified to a OR/AND node respectively.

Alive2: https://alive2.llvm.org/ce/z/MehvFB

Fixes #64782

When FIR comes from HLFIR, there will be a fir.declare operation between
the source and the usage of each source variable (and some temporary
allocations). This pass needs to be able to follow these so that it can
still transform loops when HLFIR is used, otherwise it mistakenly
assumes these values are not function arguments.

More work is needed after this patch to fully support HLFIR, because the
generated code tends to use fir.array_coor instead of fir.coordinate_of.

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

This pass is intended to spot cases where we can do better than the
default bufferization and to rewrite those specific cases. Then the
default bufferization (bufferize-hlfir pass) can handle everything else.

The transformation added in this patch rewrites simple element-wise
updates to an array to a do-loop modifying the array in place instead of
creating and assigning an array temporary.

See the RFC at
https://discourse.llvm.org/t/rfc-hlfir-optimized-bufferization-for-elemental-array-updates

This patch gets the improvement to exchange2 but not the improvement to cam4
described in the RFC. I think the cam4 improvement will require better alias
analysis. I aim to follow up to fix this in a later patch. With changes
since the RFC, the pass improves polyhedron channel2 by about 52%.

Depends on: D156805 D157718 D157626

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

This patch updates the lowering of the arm_sme.zero to intrinsics so
that it calculates the correct mask for the tile to zero.

The zero instruction takes an 8-bit mask which specifies which 64-bit
tiles to zero, ZA0.D to ZA7.D correspond to bits 0 to 7. To zero tiles
with element sizes of 8-bit to 32-bit just requires zeroing the right
64-bit tiles.

This is quite easy to calculate, each size has a "base mask" which can
be shifted left by the tile ID to get the mask for that tile.

  base_mask << tile_id

After tile allocation, this will be folded to a constant mask.

Reviewed By: awarzynski

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

Implement basic support for verifying LiveIntervals for PHIs.

Reviewed By: arsenm

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

Reviewed By: alanphipps
Differential Revision: https://reviews.llvm.org/D157608

This commit releases a checker that was developed to a stable level in
the Ericsson-internal fork of Clang Static Analyzer.

Note that the functionality of this checker overlaps with
core.UndefinedBinaryOperatorResult ("UBOR"), but there are several
differences between them:
(1) UBOR is only triggered when the constant folding performed by the
Clang Static Analyzer engine determines that the value of a binary
operator expression is undefined; this checker can report issues where
the operands are not constants.
(2) UBOR has unrelated checks for handling other binary operators, this
checker only examines bitwise shifts.
(3) This checker has a Pedantic flag and by default does not report
expressions (e.g. -2 << 2) that're undefined by the standard but
consistently supported in practice.
(4) UBOR exhibits buggy behavior in code that involves cast expressions,
e.g.
    void foo(unsigned short s) {
      if (s == 2) {
        (void) ((unsigned int) s) << 16;
      }
    }

Later it would be good to eliminate this overlap (perhaps by deprecating
and then eliminating the bitwise shift handling in UBOR), but in my
opinion that belongs to separate commits.

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



Co-authored-by: Endre Fulop <endre.fulop@sigmatechnology.se>