Add a variation of @nested_loop_outer_iv_addrec_invariant_in_inner with
the dependence sink and source swapped to extend test coverage.
Also simplifies the test by removing an unneeded reduction.
(cherry picked from commit e117137af0a37ac309d40db57ec7162ef3d22c29)
Code needs double backticks, while single backticks produce italics.
Lists need to be fully indented and have blank lines around them.
Links are written "`text <url>`_".
We use links instead of `:manpage:`, because the latter is meant
more for man pages cross-referencing each other.
Reviewed By: aaron.ballman, thieta
Differential Revision: https://reviews.llvm.org/D132791
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 af39e6f6fc905f3c067f022fb44136779d2f9c84)
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 e624f8a3bb88075493dec521408993ea0ef7bde0)
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 992e10a3fce41255e4b11782f51d0f4b26dca14d)
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 b52820edec6f3d95edef7859a56ef30878b08382)
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 5905e699342fd476d7eb9e35db5d84248a7e9156)
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 8c6319e30a357fb9b25db09b6f5fc9cf3e7c4aab)
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 8537a99b2c1d08e9e586b3fb9e36728075ec4a03)
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 3b52341116b794e53dec2fd07e568884e5a0b8bb)
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 83411bf06f34ae06731008eeabfc53553c1a1f86)
This is a follow-up to 2ebfda2417
(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 d982f1e0c69f3447c4520ae4c010520f62ed1174)
Commit 8922adf646 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 940733d6a0a92245912361bf116514172a15f4f8)
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 d9993484ee40abaab6d9e96872d3a29044202aea)
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 bcef4d238d113c61127575bf5dd0328f97bda9e9)
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 ca98e0dd6cf59907f07201c4282dcafeeea11a91)
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 bc538320809fb52af12ec0366118c82201af4f40)
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 7f72a0f5bb3743428021df920d9a7c50f74f61ae)
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 99020b3c73c1e22fa388be8fd0c44391d40b3a38)
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 bcb2740f415b0f825402f656dda3271414121a0e)
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 d230055234863aafe63489f9ab95e52d2c1883f2)
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 48e1250a91d244741c8677fed248ace1fcd7c41c)
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 dfc95bab078297b1564c1ac757b1ac093d125b2d)
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 467abac2046d037f8d4cf428e76b77e5b06c187f)
`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 d797c2ffdb591d10de2964907962aaacb2e360ca)
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 3329cec2f79185bafd678f310fafadba2a8c76d2)
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 f62e60fb238146113f84e0efb1a2ebc52f05cc0a)
