Fixes #57340

Reviewed By: RKSimon

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

(cherry picked from commit 12b203ea)

When an object file contains an export directive, we normally do some
amount of deferred processing of them at the end of the linking
process. The -includeoptional option was handled after this, and
any object files (defining new exports) weren't handled.

Move the handling of the -includeoptional into the same late loop
which does the fixups for e.g. export directives.

Ideally, this would also be done for object files that are pulled
in by the wrap options, and for mingw autoimports, but those changes
require more modifications, to make them safe for potentially
being executed multiple times.

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

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

(cherry picked from commit af39e6f6)

This reverts commit bc39d7bd.

rename CLANG_SONAME to LIBCLANG_SOVERSION

[clang][cmake] introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

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

extractShiftForRotate may fail to return canonicalized shifts due to constant folding or other simplification that can occur in getNode()

Fixes Issue #57283

(cherry picked from commit e624f8a3)

We don't know which test suites are going to be included by runtimes
builds so we cannot include those before running the sub-build, but
that's not possible during the LLVM build configuration. We instead use
a response file that's populated by the runtimes build as a level of
indirection.

This addresses the issue described in:
https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788

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

(cherry picked from commit 992e10a3)

This allows reading arguments from file using the response file syntax.
We would like to use this in the LLVM build to pass test suites from
subbuilds.

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

(cherry picked from commit b52820ed)

As reported in [1], cxx-headers is not a valid distribution target
because it is an interface target in CMake. This breaks the most
basic MultiDistributionExample of the runtimes build.

This patch handles interface targets by getting rid of the assumption
that all distribution components have a target associated to them. It
is valid for a distribution component to only have a `install-FOO`
target.

In the case where only `cxx-headers` is provided as a distribution
component, `ninja toolchain-distribution` will not build anything
after this patch, since there is effectively nothing to build for
the `cxx-headers` target. However, running `ninja install-toolchain-distribution`
will build everything, as expected.

[1]: https://discord.com/channels/636084430946959380/636732894974312448/1010013287464828968

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

(cherry picked from commit 5905e699)

Also, add missing tests for assertions in span constructors. Now I
believe that all of std::span's API should be hardened, and all the
assertions should have a corresponding test.

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

(cherry picked from commit 8c6319e3)

This reverts commit 27712337.

See issue: https://github.com/llvm/llvm-project/issues/57346

We currently use CMake's find_library function to detect whether
libpthread exists on the system to determine if pthread should
be added on the link step. However, there are configurations in
which CMake's path checking fails to find the library even though
the toolchain has it.

One such case is with Clang 14.0.0 on PowerPC. Due to a recent
change, the build puts libc++ and related libraries in a
subdirectory that appears to depend on the default target triple.
CMake then uses that subdirectory to determine the architecture
and adds that name to its search paths. However, the triple for
the system GNU toolchain is different so CMake fails to find it.
Namely, Clang 14.0.0's default target triple and the subdirectory
name is powerpc64le-unknown-linux-gnu whereas the system GNU
toolchain has powerpc64le-linux-gnu. Clang's driver has no trouble
finding either the GNU includes/libraries or Clang's own. But
CMake seems to get this wrong.

The net result of this is that we can't do a shared libraries
build of ToT with Clang 14.0.0.

This patch proposes using HAVE_LIBPTHREAD which CMake seems to
determine by compiling a test file with -lpthread (or perhaps
-pthread, I can't really get CMake to tell me how it is figuring
this out). If that variable tells CMake that the build compiler
accepts the pthread option, it seems reasonable to depend on
that variable to determine if we should add it to the link step
when building the llvm_gtest library.

(cherry picked from commit 8537a99b)

When performing device only compilation, there was an issue where
`cubin` outputs were being renamed to `cubin` despite the user's name.
This is required in a normal compilation flow as the Nvidia tools only
understand specific filenames instead of checking magic bytes for some
unknown reason. We do not want to perform this transformation when the
user is performing device only compilation.

Reviewed By: tra

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

(cherry picked from commit 3b523411)

This is mostly a mechanical change to adapt standard type hierarchy
support proposed in LSP 3.17 on top of clangd's existing extension support.

This does mainly two things:
- Incorporate symbolids for all the parents inside resolution parameters, so
  that they can be retrieved from index later on. This is a new code path, as
  extension always resolved them eagerly.
- Propogate parent information when resolving children, so that at least one
  branch of parents is always preserved. This is to address a shortcoming in the
  extension.

This doesn't drop support for the extension, but it's deprecated from now on and
will be deleted in upcoming releases. Currently we use the same struct
internally but don't serialize extra fields.

Fixes https://github.com/clangd/clangd/issues/826.

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

(cherry picked from commit 83411bf0)

This is a follow-up to 2ebfda24
(replace "if" with "else if" since the cases nuw/nsw
were meant to be handled separately).

Test plan:
1/ ninja check-llvm check-clang check-lld
2/ Bootstrapped LLVM/Clang pass tests

(cherry picked from commit d982f1e0)

Commit 8922adf6 recently made JITTargetMachineBuilder honor the
hasJIT property of the target. LLVM supports just-in-time compilation
on RISC-V, so set the flag.

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

(cherry picked from commit 940733d6)

As discussed in D85414 <https://reviews.llvm.org/D85414>, two tests
currently `FAIL` on Sparc since that backend uses the Sun assembler syntax
for the `.section` directive, controlled by
`SunStyleELFSectionSwitchSyntax`.

Instead of adapting the affected tests, this patch changes that default.
The internal assembler still accepts both forms as input, only the output
syntax is affected.

Current support for the Sun syntax is cursory at best: the built-in
assembler cannot even assemble some of the directives emitted by GCC, and
the set supported by the Solaris assembler is even larger: SPARC Assembly
Language Reference Manual, 3.4 Pseudo-Op Attributes
<https://docs.oracle.com/cd/E37838_01/html/E61063/gmabi.html#scrolltoc>.

A few Sparc test cases need to be adjusted. At the same time, the patch
fixes the failures from D85414 <https://reviews.llvm.org/D85414>.

Tested on `sparcv9-sun-solaris2.11`.

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

(cherry picked from commit d9993484)

Reflect in the pointer's offset the length of the leading part
of the consumed string preceding the first converted digit.

Reviewed By: efriedma

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

(cherry picked from commit bcef4d23)

A number of mlir tests `FAIL` on Solaris/sparcv9 with `Target has no JIT
support`.  This patch fixes that by mimicing `clang/test/lit.cfg.py` which
implements a `host-supports-jit` keyword for this.  The gtest-based unit
tests don't support `REQUIRES:`, so lack of support needs to be hardcoded
there.

Tested on `amd64-pc-solaris2.11` (`check-mlir` results unchanged) and
`sparcv9-sun-solaris2.11` (only one unrelated failure left).

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

(cherry picked from commit ca98e0dd)

The hard float ABIs have a rule that if a flattened struct contains
either a single fp value, or an int+fp, or fp+fp then it may be passed
in a pair of registers (if sufficient GPRs+FPRs are available).
detectFPCCEligibleStruct and the helper it calls,
detectFPCCEligibleStructHelper examine the type of the argument/return
value to determine if it complies with the requirements for this ABI
rule.

As reported in bug #57084, this logic produces incorrect results for C++
structs that inherit from other structs. This is because only the fields
of the struct were examined, but enumerating RD->fields misses any
fields in inherited C++ structs. This patch corrects that issue by
adding appropriate logic to enumerate any included base structs.

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

(cherry picked from commit bc538320)

As reported in <https://github.com/llvm/llvm-project/issues/57084>,
under hard float ABIs there are issues with lowering structs that
inherit from other structs.

See <https://reviews.llvm.org/D131677> for a fix.

(cherry picked from commit d17de547)

This is a potentially better alternative to D131452 that also
should avoid the infinite loop bug from:
issue #56403

This is again a minimal fix to reduce merging pain for the
release. But if this makes sense, then we might want to guard
all of the RTLIB generation (and other libcalls?) with a
similar name check.

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

(cherry picked from commit 7f72a0f5)

Issue #56403

(cherry picked from commit 8eddd1ec)

For some reason cmake started selecting a 32-bit version of python on
Windows instead of the 64-bit version when building windows.  Explicitly
setting the default python to 3.10 fixes this problem.

Reviewed By: thieta

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

(cherry picked from commit 99020b3c)

Reviewed By: thieta

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

(cherry picked from commit 5b108dfc)

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

(cherry picked from commit 06b97b49)

When testing LLVM 15.0.0 rc1 on Solaris, I found that 50+ flang tests
`FAIL`ed with

  error:
/vol/llvm/src/llvm-project/local/flang/lib/Optimizer/CodeGen/Target.cpp:310:
not yet implemented: target not implemented

This patch fixes that for Solaris/x86, where the fix is trivial (just
handling it like the other x86 OSes).

Tested on `amd64-pc-solaris2.11`; only a single failure remains now.

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

(cherry picked from commit bcb2740f)

release/15.x uses C++14 and structured bindings trigger warnings in Clang/GCC
and errors in MSVC.

Move the `LLVM_INSTALL_PACKAGE_DIR` declaration from llvm/cmake/modules
directory to the top-level llvm/CMakeLists.txt, in order to fix
the regression in `llvm-config --cmakedir` output for installed LLVM.
Since the tools directory is processed by CMake prior to
llvm/cmake/modules, the llvm-config executable ended up using
the variable prior to it being defined and incorrectly used an empty
path, resulting in e.g.:

    $ llvm-config --cmakedir
    /usr/lib/llvm/16/

With this patch, the path is defined (and therefore the default value
is being set) prior to adding the tools subdirectory and llvm-config
starts working correctly:

    $ llvm-config --cmakedir
    /usr/lib/llvm/16/lib64/cmake/llvm

This fixes a regression introduced by D130539.  Thanks to Petr Polezhaev
for reporting the problem @ https://bugs.gentoo.org/865165

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

(cherry picked from commit d2300552)

arm_sve.h defines and uses __ai macro which needs to be undefined (as it is
already in arm_neon.h).

Reviewed By: paulwalker-arm

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

(cherry picked from commit 48e1250a)

This is a followup to D131350, which caused another problem for i64
types being split into i32 on i32 targets. This patch tries to make sure
that either Illegal types are OK, or that the element types of a
buildvector are legal and bigger than or equal to the size of the
original elements.

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

(cherry picked from commit dfc95bab)

Make sure that FortranDecimal, FortranRuntime and Fortran_main are
installed/packaged even when LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
They are used by flang to link executables, so they should be provided
even with minimal installs.

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

(cherry picked from commit 467abac2)

We were incorrectly checking that it returned an implicaton result,
not that the implication result itself was true.

`getContext().setMCLineTableRootFile` (from D62074) sets `RootFile.Name` to
`FirstCppHashFilename`. `RootFile.Name` is not processed by -fdebug-prefix-map
and will go to DW_TAG_compile_unit's DT_AT_name and DW_TAG_label's
DW_AT_decl_file. Remap `RootFile.Name`.

Fix another issue reported by https://github.com/llvm/llvm-project/issues/56609

Reviewed By: #debug-info, dblaikie, raj.khem

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

(cherry picked from commit d797c2ff)

DWARF v5 6.2.4 The Line Number Program Header says:

> The first entry is the current directory of the compilation. Each additional
> path entry is either a full path name or is relative to the current directory of
> the compilation.

When forming a path, relative DW_AT_comp_dir and directories[0] are not supposed
to be joined together. Fix getFileNameByIndex to special case DWARF v5 DirIdx == 0.

Reviewed By: #debug-info, dblaikie

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

(cherry picked from commit 3329cec2)

For generated assembly debug info, MCDwarfLineTableHeader::CompilationDir is an
unmapped path set in MCContext::setGenDwarfRootFile. Remap it.

A relative destination path of -fdebug-prefix-map= exposes a llvm-dwarfdump bug
which joins relative DW_AT_comp_dir and directories[0].

Fix https://github.com/llvm/llvm-project/issues/56609

Reviewed By: dblaikie

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

(cherry picked from commit f62e60fb)

(cherry picked from commit 53113515)

(cherry picked from commit d561907f)

(cherry picked from commit b0c4cd35)