Reviewed By: mravishankar, hanchung

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

(0e63f1aa was reverted by 7590b765 due to a crash.)

Annotate constructor/destructor names as FunctionDeclarationName.

Fixes #63046.

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

The declare attribute has been updated to allow implicit flag. This is
useful for variables that can be declare'd implicitly - like global
constants. The verifier has been updated to ensure that an implicit
declare'd variable has an implicit data action. The builder doesn't
require for this flag to be set so any code creating this attribute
will continue to work as-is.

Reviewed By: vzakhari

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

Reverting since this caused Linux/odd_stack_size.cpp to fail on a bunch
of builders.

This reverts commit 34e2f4f2.

This fixes https://github.com/llvm/llvm-project/issues/64928.

Differential-Revision: https://reviews.llvm.org/D158945

The macro ACC_DATA_CONSTRUCT_OPS defines all operations which are
data constructs. The recently DeclareOp was not added to the list.
Add it now.

Reviewed By: vzakhari, clementval

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

Original commit message:"

ORC splits into separate dylibs symbols coming from the process and symbols
materialized in the Jit. This patch adapts intent of the existing interface and
adds a regression test to make sure both Jit'd and compiled symbols can be found.

Differential revision: https://reviews.llvm.org/D159115
"

This patch disables the test statement on windows as it seems we might have a
bug in the way we model dllimports.

This reverts commit 196d8569 while investigating
bot failure: https://lab.llvm.org/buildbot/#/builders/216/builds/26444

Fix https://github.com/llvm/llvm-project/issues/58740
The `target_clones` attribute results in ifunc on eligible targets
(Linux glibc/Android or FreeBSD). If the function has internal linkage,
we will get an internal linkage ifunc.
```
__attribute__((target_clones("popcnt", "default")))
static int foo(int n) { return __builtin_popcount(n); }
int use(int n) { return foo(n); }

@foo.ifunc = internal ifunc i32 (i32), ptr @foo.resolver
define internal nonnull ptr @foo.resolver() comdat {
; local linkage comdat is another issue that should be fixed
  ...
  select i1 %.not, ptr @foo.default.1, ptr @foo.popcnt.0
  ...
}
define internal i32 @foo.default.1(i32 noundef %n)
```

ifuncs are not included in module summaries, so LTO doesn't know the
local linkage `foo.default.1` referenced by `foo.resolver`
should be promoted. If a caller of `foo` (e.g. `use`) is imported,
the local linkage `foo.resolver` will be cloned as a definition
(IRLinker::shouldLink), leading to linker errors.
```
ld.lld: error: undefined hidden symbol: foo.default.1.llvm.8017227050314953235
>>> referenced by bar.c
>>>               lto.tmp:(foo.ifunc)
```

As a simple fix, just mark `use` as not eligible for import. Non-local
linkage ifuncs do not have the problem, because they are not imported,
and not cloned when a caller is imported.

---

https://reviews.llvm.org/D82745 contains a more involved fix, though the
original bug it intended to fix
(https://github.com/llvm/llvm-project/issues/45833) now works.

Note: importing ifunc is tricky.
If we import an ifunc, we need to make sure the resolver and the
implementation are in the translation unit, as required by
https://sourceware.org/glibc/wiki/GNU_IFUNC

> Requirement (a): Resolver must be defined in the same translation unit as the implementations.

This is infeasible if the implementation is changed to
available_externally.

In addition, the imported ifunc may be referenced by two translation
units. This doesn't work with PowerPC32 -msecure-plt
(https://maskray.me/blog/2021-01-18-gnu-indirect-function).
At the very least, every referencing translation unit needs one extra
IRELATIVE dynamic relocation.

At least for the local linkage ifunc case, it doesn't have much use
outside of `target_clones`, as a global pointer is usually a better
replacement.

I think ifuncs just have too many pitfalls to design more IR features
around it to optimize them.

Reviewed By: tejohnson

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

Fix static analyzer concerns about dereferencing null values.

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

This patch fixes:

  mlir/lib/Target/Cpp/TranslateToCpp.cpp:320:3: error: default label
  in switch which covers all enumeration values
  [-Werror,-Wcovered-switch-default]

ORC splits into separate dylibs symbols coming from the process and symbols
materialized in the Jit. This patch adapts intent of the existing interface and
adds a regression test to make sure both Jit'd and compiled symbols can be found.

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

Instead, make it a static array that's part of the FlagParser. The advantage
this has is helping reduce fragmentation from needing to anonymously mmap
this array via the LowLevelAllocator. This will instead place the array on
the stack. Functionally, the only difference is that the array will not be
zero-initialized, but all used elements are explicitly initialized via the
flag handlers.

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

Another shell-quoting issue.

Seen in <https://lab.llvm.org/buildbot/#/builders/216/builds/26442>.

For `llvm/utils/lit/tests/shtest-output-printing.py`, the executable
in `%{python}` wasn't properly shell-quoted for windows.  This caused
the 127 exit code mentioned in f254bbf2.  Fix quoting and expect
exit code 1 again.

Fix shell-quoting issue in a few more file names in
`llvm/utils/lit/tests/shtest-shell.py`, missed in f254bbf2.

Test failures seen in
<https://lab.llvm.org/buildbot/#/builders/216/builds/26436>.

[Clang] Modify Parser::ParseLambdaExpressionAfterIntroducer to check whether the lambda-declarator is valid

We had a couple of crashes due to invalid lambda trailing return types that
were diagnosed but not treated as errors during parsing. So now in
Parser::ParseLambdaExpressionAfterIntroducer(...) after ActOnStartOfLambdaDefinition(...)
we also check if the lambda-declarator is invalid and if so we end up in ActOnLambdaError(...).

Fixes: https://github.com/llvm/llvm-project/issues/64962
https://github.com/llvm/llvm-project/issues/28679

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

This reverts commit 024f562d.

Forgot to update flang

Add a c23 module feature for `requires`.

Reviewed By: ChuanqiXu, v.g.vassilev, aaron.ballman

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

Assemblers change certain relocations referencing a local symbol to
reference the section symbol instead. This conversion is disabled for
many conditions (`shouldRelocateWithSymbol`), e.g. TLS symbol, for most
targets (including AArch32, x86, PowerPC, and RISC-V) GOT-generating
relocations.

However, AArch64 encodes the GOT-generating intent in MCValue::RefKind
instead of MCSymbolRef::Kind (see commit
0999cbd0 (2014)), therefore not affected
by the code `case MCSymbolRefExpr::VK_GOT:`. As GNU ld and ld.lld
create GOT entries based on the symbol, ignoring addend, the two ldr
instructions will share the same GOT entry, which is not expected:
```
ldr     x1, [x1, :got_lo12:x]  // converted to .data+0
ldr     x1, [x1, :got_lo12:y]  // converted to .data+4

.data
// .globl x, y  would suppress STT_SECTION conversion
x:
.zero 4
y:
.long 42
```

This patch changes AArch64 to suppress local symbol to S...

This is necessary to allow testing pre-commit CI from GH PRs before
the repo-lockdown script is removed entirely.

The current implementation is not very ergonomic or descriptive: It uses `std::optional<unsigned>` where `std::nullopt` represents the parent op and `unsigned` is the region number.
This doesn't give us any useful methods specific to region control flow and makes the code fragile to changes due to now taking the region number into account.

This patch introduces a new type called `RegionBranchPoint`, replacing all uses of `std::optional<unsigned>` in the interface. It can be implicitly constructed from a region or a `RegionSuccessor`, can be compared with a region to check whether the branch point is branching from the parent, adds `isParent` to check whether we are coming from a parent op and adds `RegionSuccessor::parent` as a descriptive way to indicate branching from the parent.

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

[DAG] visitSHL - use FoldConstantArithmetic to fold constants in (shl (add x, c1), c2) -> (add (shl x, c2), c1 << c2) fold

Matches what we do in the (shl (mul x, c1), c2) -> (mul x, c1 << c2) fold as well as inside visitShiftByConstant

This reverts commit cf403c10.

This is breaking Android sanitizer buildbots (see the discussion on
https://reviews.llvm.org/D158793).

Disable the new test flang/test/Evaluate/test-out_of_range.f90
on targets and systems that do not support the kinds of REAL
that it exercises.

Pushed without review to clear up broken build-bots.

This basically inlines the logic that was previously located in
https://github.com/google/llvm-premerge-checks so it is part of
the monorepo. This has the benefit of making it extremely easy
for individual projects to understand and modify this logic for
their own needs, unlike the current model where this logic lives
in a separate non-LLVM repository.

It also allows testing changes to the CI configuration using a simple
Phabricator review, since the code that defines the CI pipeline is taken
from the patch under review.

This (or something equivalent) is necessary if we want to retain the
current monolithic pre-commit CI throughout the GitHub PR transition.
Since triggering the monolithic CI is currently attached to the system
we use for triggering CI pipelines from Phabricator, we will lose that
part of the CI when we move to GitHub PRs if we don't do anything.

I've decided to rewrite the code as a shell script because the logic
was fairly simple and it seemed a lot easier than figuring out how to
pull only the relevant parts of llvm-premerge-checks into the monorepo.
Furthermore, I think we should strive to move away from the monolithic
CI altogether since sub-projects should understand, own and maintain the
tests that are relevant for them to run in the CI (with LLVM providing
the infrastructure). Hence, this is somewhat of a temporary solution
until monolithic CI is removed entirely.

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

Handle the case when shell quotes are not necessary.

Label resolution gets into an infinite loop trying to emit an inappropriate
error or warning for a GOTO whose target is on an enclosing END IF
statement with an intervening ELSE or ELSE IF.  The scope tracking mechanism
viewed the END IF as being part of the ELSE block's scope.

Fix with the same means that was used to fix a similar bogus error
on GOTOs to END SELECT in SELECT CASE blocks: nest the THEN/ELSE IF/ELSE
blocks one level deeper than before, so that the END IF is in the IF
block but not in any of its parts.

Fixes https://github.com/llvm/llvm-project/issues/64654 for
llvm-test-suite/Fortran/gfortran/regression/goto_5.f90.

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

This was mention in D150044 and D154995 that this would be useful.
This addresses the last review coment of D150044.

Reviewed By: #libc, ldionne

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

This adds more information regarding the libc++ coding style and
reference that are useful when working on a standard library
implementation.

This information is based on review comments and tips I give to new
contributors an information I wish I'd know when I started working on
libc++.

Depends on D156051

Reviewed By: #libc, jloser, var-const, ldionne

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

Process and fold the new F'2023 intrinsic function SELECTED_LOGICAL_KIND.

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

Failures were seen at
<https://lab.llvm.org/buildbot/#/builders/216/builds/26431>.

All but one failure is due to different shell-quoting of file names
because they contain special characters under windows.  Generalize
associated FileCheck patterns.

`llvm/utils/lit/tests/shtest-output-printing.py` fails because the
exit code was 127 instead of the expected 1.  Unfortunately, this CI
config doesn't pass `-dump-input-filter=all` to FileCheck, so we
cannot see the rest of the lit execution trace.  For now, generalize
the FileCheck pattern to accept any non-zero exit code to get past
this error.

Invoking compiler-rt function __truncsfbf2 to convert a zero 32-bit float
0x00000000 to a 16-bit bfloat value currently generates the denormal value
0x0040, rather than value 0x0000. Negative zero 0x80000000 is converted
to denormal 0x8040 rather than 0x8000.

This behavior is seen in flang code under development (not yet integrated)
that converts bfloat/REAL(KIND=3) argument values to float/REAL(KIND=4)
values and then converts those values back to bfloat/REAL(KIND=3). There
are other instances of the problem. A round-trip type conversion using
__truncsfbf2 of a denormal generates a different denormal, and an sNaN
is converted to a qNaN.

The problem is addressed in generic conversion function fp_trunc_impl.inc
by removing trailing 0 significand bits when the source and destination
type formats are identical except for the significand size. This condition
is met only for float -> bfloat conversions.

Round-trip conversions for at least some other type pairs have the same
problem. A solution in those cases would need to account for exponent
size differences. Those cases are not relevant to flang compilations
and are not addressed here. A broader solution might subsume this fix,
or this fix might remain useful as is.

There are no existing tests of bfloat conversion functionality in the
compiler-rt test directory. Tests for other conversions use a common
infrastructure that does not currently have support for bfloat conversions.
This patch does not attempt to add that infrastructure for this new case.
CodeGen test bfloat.ll checks bfloat adds and other operations that invoke
__truncsfbf2.

This patch is the follow-up improvement of D122152.
Fixes https://github.com/llvm/llvm-project/issues/64558.

`select (a | c), a, b -> select a, true, (select ~c, b, false)` where `c` is free to invert
`select (c & ~b), a, b -> select b, true, (select c, a, false)`
Alive2: https://alive2.llvm.org/ce/z/KwxtMA

Reviewed By: nikic

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

This adds a comparison operation to EmitC which supports ==, !=, <=, <, >=, >, <=>.

Reviewed By: jpienaar

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

Fold the F'2018 intrinsic function OUT_OF_RANGE(), which returns .TRUE.
when a conversion of an integer or real value to an integer or real type
would yield an overflow or (for real->integer only) invalid operand
exception.  Test all type combinations, with both rounding possibilities
for the real->integer cases.

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

Currently all of this logic expects to include and link with the headers
in the `linux/` directory. This patch adds a wrapper macro to optionally
add the appropriate dependency if it exists. This is preliminary to
adding some GPU specific versions of these files.

Reviewed By: lntue

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

Leading zeros should appear only for Iw.m output formatting.
Gw, Gw.d, and Gw.dEe output editing all map to Iw with no ".m"
(Fortran 202X 13.7.5.2.2).

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

This is NFCI as far as I can tell, but I see no reason not to do it.

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

[RISCV] Improve splatPartsI64WithVL for fixed vector constants where Hi and Lo are the same and the VL is constant.

If doubling the VL will fit in a vsetivli, use it. It will be cheap
to change and cheap to change back.

This improves codegen from D158896.

Reviewed By: reames

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