The `stdint.h` header provides the standard types. Previously we used
`-nostdinc` and defined these ourselves. This patch switches to a
freestanding version which should work properly. Without
`-ffreestanding` the `stdint.h` header will include other libraries. But
in a freestanding environment it should work given the primitives.

Reviewed By: jdoerfert

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

Summray:
These clang tools should print some basic help and version messages so
they are less opaque.

Reviewed By: ye-luo

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

This isn't safe to do.

Link: https://github.com/llvm/llvm-project/issues/53562
Fixes: https://github.com/llvm/llvm-project/issues/61023

Reviewed By: efriedma, nikic

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

This is related to llvm-project#61074.
In general, it is undefined behavior if user subprogram is declared
with a name that matches a name of function from any runtime library
that Flang is using (e.g. FortranRuntime, libm, etc.). With this change-set
we avoid ICE for invalid calls generated during math lowering by
type casing the function before the call. This happens when a user function
call is lowered before the math function call with the same name.
To detect the name clash in cases when the math function call is lowered
before the user function call we set fir.runtime attribute for the math
functions and check it when we lower the user function call.

The warnings are currently emitted only in debug compiler and
under llvm debug options. I think they should be reported
in the same way as regular Flang warnings.

Note that this change-set does not resolve issues with the conversion
passes that might introduce libm calls after the lowering.

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

When generic_atomic_rmw is inside of memref.alloca_scope, then the pattern would fail.

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

Also fix few lints

Reviewed By: cryptoad

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

Fixed vector costs may be more precise, but the actual lowering will use scalable vectors if nothing better is available.  During review, we noticed a case where fixed vector reverse can be improved cost model wise, that will follow seperately.

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

This replaces several rewriting rules in ScalarEvolution::applyLoopGuards
that are applied to min/max expressions with the equivalent ones but
applied to its arguments.
So previously given we had a loop guard min(a, b) >= c,
the min expression would get rewritten as max(c, min(a, b)).
With such approach, we were unable to apply the rewrite if min operands
were zext for example (min(zext(a), zext(b))), however it's equivalent
to the expression zext(min(a, b)) for which we could apply the rewrite.

Now we'd rewrite the min operands also with these expressions:
a -> max(c, a) and
b -> max(c, b).
and this would allow us to apply the loop guard in this and similar cases:
min(zext(a), zext(b)) would get rewritten as min(zext(max(c, a)), zext(max(c, b)))
instead of just being skipped.

The list of added rules (omitting predicates signedness for simplicity):
1. Guard:     min(a, b) >= c
   Old rule:  min(a, b) -> max(c, min(a, b))
   New rules: a -> max(a, c) and b -> max(b, c)
2. Guard:     min(a, b) > c
   Old rule:  min(a, b) -> max(c + 1, min(a, b))
   New rules: a -> max(a, c + 1) and b -> max(b, c + 1)
3. Guard:     max(a, b) <= c
   Old rule:  max(a, b) -> min(c, max(a, b))
   New rules: a -> min(a, c) and b -> min(b, c)
4. Guard:     max(a, b) < c
   Old rule:  max(a, b) -> min(c - 1, max(a, b))
   New rules: a -> min(a, c - 1) and b -> min(b, c - 1)
The old rewrites still hold.

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

Structs that contain global or local pointers can be passed as kernel
arguments starting OpenCL v2.0 with the introduction of shared virtual memory.

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

This patch improves diagnostic for clang constexpr evaluator by adding
a check for nullptr in function pointer call evaluations.

ex.
```
constexpr int foo(int (*bla)(void)) {
  return bla();
}

static_assert(foo(nullptr) == 1);
```

BEFORE this patch, clang generates the following diagnostic for the
code above:

```
<source>:5:15: error: static assertion expression is not an integral constant expression
static_assert(foo(nullptr) == 1);
              ^~~~~~~~~~~~~~~~~
<source>:2:10: note: subexpression not valid in a constant expression
  return bla();
         ^
<source>:5:15: note: in call to 'foo(nullptr)'
static_assert(foo(nullptr) == 1);
              ^
1 error generated.
```

AFTER this patch, subexpression not valid in a constant expression note
is replaced with 'bla' evaluates to a null function pointer.

Fixes https://github.com/llvm/llvm-project/issues/59872
Differential Revision: https://reviews.llvm.org/D145793

This reverts commit 0fe16607 which wasn't ready
to land.

This reverts commit 0317147a.

It causes broken module error when building chromium media_unittests
PHI nodes not grouped at top of basic block!
%19 = phi ptr [ %16, %15 ], [ %18, %12 ], !dbg !16
label %17
LLVM ERROR: Broken module found, compilation aborted!

On some R-profile CPUs, leaving out the FPU is an option. Clang will
accept `-march=armv8-r+nofp`, but it's currently not possible to find
out via the preprocessor whether it's in that mode (e.g. to change or
disable inline asm statements in your code).

The __ARM_FP macro, which has a bit set for each size of floating
point number supported by the hardware, is the natural thing to test.
But Clang was defining it unconditionally on AArch64. Now it checks
for FP support before defining it at all.

Reviewed By: tmatheson, DavidSpickett

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

Commit 3671bdbc("[BPF] Fix a BTF type pruning bug") fixed a
pruning bug to allow generate more types. But the commit has a bug
which permits to generate more types than necessary. The following
is an example to illustrate the problem.

   struct t1 {
     int a;
   };
   struct t2 {
     struct t1 *p1;
     struct t1 *p2;
     int b;
   };
   int foo(struct t2 *arg) {
     return arg->b;
   }

The following is the part of BTF generation sequence:
  (1). 'struct t2 *arg' -> 'struct t1 *p1'
       In this step, the type 'struct t1' will be generated as
       a forward decl and the ptr type (to 'struct t1') will
       be stored in the internal type table.
  (2). now the second field 'struct t1 *p2' will be processed.
       Since the ptr type (to 'struct t1') already in the type
       table, the existing logic strips out ptr modifier and
       is able to generate BTF type for 'struct t1'.

In the above step (2), if CheckPointer is true (the type traversal
chain including a struct member), 'ptr' modifier should be checked
and the subsequent type generation should be skipped since
the same case has been processed in visitDerivedType().

The issue is exposed when I am trying to use llvm15 to compile
some internal bpf programs. The bpf skeleton put the whole
ELF section (after striping some sections like dwarf) as a string.
The large BTF section triggered the following error:

  bpf_object_with_struct_ops_test_prog_bpf/BpfObjectWithStructOpsTestProg.skel.h:222:23:
  error: string literal of length 140144 exceeds maximum length 65536 that C++ compilers
  are required to support [-Werror,-Woverlength-strings]
        return (const void *)"\
                             ^~
  1 error generated.

Although adding -Wno-overlength-strings could workaround the issue,
improving llvm BTF generation sounds better esp. for users using vmlinux.h.

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

PassManagerBuilder is dead, long live PassBuilder!

bugpoint's -O# are now useless (and probably have been for a while given the number of passes we've removed from PassManagerBuilder). Perhaps they'll be revived if bugpoint ever works with the new PM.

Reviewed By: nikic, MaskRay

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

Extend the logic for the WinSDK and UCRT handling to prefer a user
specified version of the VisualC++ tools and Windows SDK.  This allows
us to now perform the regular search for the installation but select the
exact version of the SDK or VC++ tools to override the latest version.
Similar to the other flags controlling this behaviour, if the user
specifies a value, we will not perform validation on the input and will
attempt to prefer that, particularly in the case of VisualC++ tools
where no fallback occurs.

Reviewed by: hans
Differential Revision: https://reviews.llvm.org/D145517

This patch implements the C++20-style contains() for DenseMap,
MapVector, and StringMap.

With this patch, every set and map container type that has count()
also has contains().

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

Pass BUILDTREE_ONLY to llvm_gtest_main only if LLVM_INSTALL_GTEST
is not set.  This fixes 08079863.
Otherwise, llvm_gtest_main cannot be used
in LLVM_DISTRIBUTION_COMPONENTS, effectively making it impossible
to install llvm_gtest correctly.

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

The current setting is not working.
When compiling `flang`, the `external-hello-world` is still compiled by default.

Reviewed By: luporl

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

This should be a typo in `emitConstantSizeRepmov`. Both its caller and
callee store the alignment in a 64-bit variables, no reason to truncate
it to 32-bit. It results in alignment turns into 0 when larger than
0x100000000.

Fixes #61348

Reviewed By: RKSimon

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

The code structure was copied from AArch64 which has a much more complicated splice cost model.

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

Fixes #61374

This is a convenient flag for context where we intend to summarize a top-level
operation without the full-blown regions it may hold.

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

When using attributes by plugins (both in clang and clang-tidy) the
preprocessor functions `__has_attribute`, `__has_c_attribute`,
`__has_cpp_attribute` still returned 0.

That problem is fixed by having the "hasAttribute" function also check
if any of the plugins provide that attribute.

This also adds C2x spelling to the example plugin for attributes so that
`__has_c_attribute` can be tested.

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

This makes it easier to add additional handling when the
tablegen-generated code does not find a match.

No functional change intended.

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

This intends to simplify this checking when it is done in more places.

No functional change intended.

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

This moves the code to instantiate the attribute plugins to the same
place where the plugin registry is defined so they live together and the
user of the plugins doesn't have the burden of instantiating the
plugins.

No functional change intended.

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

This moves the ParsedAttrInfo class and the registry for attribute
plugin to be part of Basic module instead of Sema module.

This will allow it to be accessed from preprocessor later on.

No functional change intended.

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

Refactoring in advance of a semantic change.

Prior to this patch, unrecognised z/s/sx/x prefixed extensions were not
ignored when IgnoreUnknown=true.

The first version of this patch, a7313f83, incorrectly used
`!isSupportedExtension(Ext)` rather than `!isSupportedExtension(Name)`.
i.e. checked the full substring rather than the split out name, causing
incorrect behaviour when a version is specified. This was fixed and a
new test case addded.

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

This slightly increases the costs of InsertElement instructions that are part
of a vector splat sequence, i.e. a load, InsertElement and a shuffle (load +
dup). The resulting LD1R is a high latency instruction, and this slight
increase in costs avoids SLP vectorisation for a couple of cases where this
isn't profitable.

Fixes: https://github.com/llvm/llvm-project/issues/61047

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

When the argument is a parent component the box needs to
be updated to reflect the correct type. Use `updateBoxForParentComponent`
to update the argument accordingly.

Reviewed By: PeteSteinfeld

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

When the base box is a block argument, the defining op is null.
Only try to recover embox/rebox if there is a defining op.

Reviewed By: PeteSteinfeld

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

Windows builds were failing due to missing include for std::addressof
after D145095.

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

This patch replaces member accesses to declaration references during template
instantiation if the context is the unevaluated context and the class does not
contain the declaration.

The replacement fixes the issue #58674. Unlike previous fixes such as D143840,
it checks the membership during instantiation rather than right after parsing,
so the check is more accurate and efficient.

This patch also includes cases that previous fixes had once failed on.

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