1. Section 2.5 : Parallel Construct
2. Section 2.7.1 : Loop Construct
3. Section 2.7.2 : Sections Construct
4. Section 2.7.3 : Single Construct
5. Section 2.7.4 : Workshare Construct
6. Section 2.8.1 : Simd Construct
7. Section 2.8.3 : Loop Simd Construct
8. Section 2.9.1 : Task Construct
9. Section 2.9.2 : Taskloop Construct
10. Section 2.9.3 : Taskloop Simd Construct
Most of the test cases added as part of this change contains semantic errors except few cases which are semantically correct but thrown a semantic error.
Currently flang is not throwing the errors for these cases and throwing semantic errors for the following correct test cases
{omp-do03.f90 , omp-loop-simd01.f90 , omp-simd02.f90 , omp-taskloop01.f90}
Hence, all the test cases are marked as XFAIL.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D87908
Remove usages of special error reporting functions(error(),
reportError()). This patch is extracted from D87987.
Errors are reported as Expected<>/Error returning values.
This part is for MachO subfolder of llvm-objcopy.
Testing: check-all.
Reviewed By: jhenderson, alexshap
Differential Revision: https://reviews.llvm.org/D88113
This patch expands two LTO test cases to check other aspects.
1) weak.ll has been expanded to show that it doesn't matter whether the
first appearance of a weak symbol appears in a bitcode file or native
object - that one is picked.
2) reproduce-lto.ll has been expanded to show that the bitcode files are
stored in the reproduce package and that intermediate files (such as
the LTO-compiled object) are not.
Differential Revision: https://reviews.llvm.org/D88094
Reviewed by: grimar, MaskRay
Without this change GCC 5.4.0 failed to compile JSON.cpp with the error:
.../llvm-project/llvm/lib/Support/JSON.cpp: In lambda function:
.../llvm-project/llvm/lib/Support/JSON.cpp:291:29: error: use of 'V' before deduction of 'auto'
for (const auto &V : *V.getAsArray())
This is the first patch for https://bugs.llvm.org/show_bug.cgi?id=47581.
Currently -u does not compute function addresses correctly and
dumps broken addresses for non-relocatable objects.
ARM spec says:
"An index table entry consists of 2 words.
The first word contains a prel31 offset (see Relocations) to the start of a function, with bit 31 clear."
...
"The relocated 31 bits form a place-relative signed offset to the referenced entity.
For brevity, this document will refer to the results of these relocations as "prel31 offsets"."
(https://developer.arm.com/documentation/ihi0038/c/?lang=en#index-table-entries)
(https://developer.arm.com/documentation/ihi0038/c/?lang=en#relocations)
Currently we use an address of the SHT_ARM_EXIDX section instead of an address of an entry
in computations. As a result we compute an offset that is not really "place-relative",
but section relative, what is wrong.
The patch fixes this issue.
Differential revision: https://reviews.llvm.org/D88076
In a post review comments for D88097 it was mentioned that code
triggers bunch of warnings of the form:
llvm/tools/llvm-readobj/ELFDumper.cpp:5299:28: warning: loop variable 'Note' is always a copy because
the range of type 'iterator_range<llvm::object::ELFFile<llvm::object::ELFType<llvm::support::big, true> >::Elf_Note_Iterator>'
(aka 'iterator_range<Elf_Note_Iterator_Impl<ELFType<(llvm::support::endianness)0U, true> > >') does not return a reference [-Wrange-loop-analysis]
for (const Elf_Note &Note : this->Obj.notes(P, Err))
It happens because Elf_Note is always copied here:
Elf_Note_Impl<ELFT> operator*() const {
assert(Nhdr && "dereferenced ELF note end iterator");
return Elf_Note_Impl<ELFT>(*Nhdr);
}
This patch fixes the issue by removing a reference.
For some expressions, we can use information from loop guards when
we are looking for a maximum. This patch applies information from
loop guards to the expression used to compute the maximum backedge
taken count in howFarToZero. It currently replaces an unknown
expression X with UMin(X, Y), if the loop is guarded by
X ult Y.
This patch is minimal in what conditions it applies, and there
are a few TODOs to generalize.
This partly addresses PR40961. We will also need an update to
LV to address it completely.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D67178
`TestCases/malloc-no-intercept.c` `FAIL`s on Solaris/x86, e.g. with
`-Dtestfunc=mallinfo`:
/usr/bin/ld: /tmp/malloc-no-intercept-586529.o: in function `main':
/vol/llvm/src/llvm-project/dist/compiler-rt/test/asan/TestCases/malloc-no-intercept.c:30: undefined reference to `nonexistent_function'
clang-12: error: linker command failed with exit code 1 (use -v to see invocation)
This is not surprising, actually:
- `mallinfo` and `mallopt` only exist in `libmalloc`
- `pvalloc` doesn't exist all all
- `cfree` does exist in `libc`, but isn't declared in any public header and
the OpenSolaris sources reveal that it has a different signature than on
Linux
- only `memalign` is a public interface
To avoid this, this patch disables the interceptors for all but `meminfo`.
Additionally, the test is marked `UNSUPPORTED` on Solaris since the
`memalign` and `cfree` variants **do** link on Solaris.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D87898
My toolchain stopped working (LLVM 8.0, libstdc++ 5.4.0) after 577adda:
06:25:37 ../unittests/Support/Path.cpp:91:7: error: chosen constructor is explicit in copy-initialization
06:25:37 {"", false, false}, {"/", true, true}, {"/foo", true, true},
06:25:37 ^~~~~~~~~~~~~~~~~~
06:25:37 /proj/flexasic/app/llvm/8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../../include/c++/5.4.0/tuple:479:19: note: explicit constructor declared here
06:25:37 constexpr tuple(_UElements&&... __elements)
06:25:37 ^
This commit adds explicit calls to std::make_tuple to work around
the problem.
Sema::DiagnoseSwiftName uses the constant 12 instead of the
corresponding enumerator ExpectedFunctionWithProtoType. This is
fragile and will fail if a new value gets added in the middle of the
enum.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D88164
This patch introduces four new comparison functions:
isKnownLT, isKnownLE, isKnownGT, isKnownGE
that return true if we know at compile time that a particular
condition is met, i.e. that one size is definitely greater than
another. The existing operators <,>,<=,>= remain in the code for
now, but over time we would like to remove them and change the
code to use the isKnownXY routines instead. These functions do
not assert like the existing operators because the caller is
expected to properly deal with cases where we return false by
analysing the scalable properties. I've made more of an effort
to deal with cases where there are mixed comparisons, i.e. between
fixed width and scalable types.
I've also added some knownBitsXY routines to the EVT and MVT
classes that call the equivalent TypeSize::isKnownXY routines.
I've changed the existing bitsXY functions to call their knownBitsXY
equivalents and added asserts that the scalable properties match.
Again, over time we expect to migrate callers to use knownBitsXY
and make the code more aware of the scalable nature of the sizes.
Differential revision: https://reviews.llvm.org/D88098
Conversion to LLVM becomes confusing and incorrect if someone tries to lower
STD -> LLVM and only then GPULaunchFuncOp to LLVM separately. Although it is
technically allowed now, it works incorrectly because of the argument
promotion. The correct way to use this conversion pattern is to add to the
STD->LLVM patterns before running the pass.
Differential Revision: https://reviews.llvm.org/D88147
This diff fixes --add-section functionality and simplifies the tests organization.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D87497
The Flang driver depends on libclangBasic. This means, among other
things, that some of the tablegen files (e.g. diagnostic definitions)
need to be generated before various libclangBasic header files can be
included (e.g. DiagnosticIDs.h). If we are lucky, libclangBasic is
indeed built before various flang driver libraries that depend on it
are. This patch makes sure that this is deterministic - i.e.
libclangBasic is built before the Flang driver libraries are.
Differential Revision: https://reviews.llvm.org/D88110
In the frontend driver we should be using FC1Option (frontend driver
options) instead of FlangOption (flang driver options).
Differential Revision: https://reviews.llvm.org/D88108
This takes the mapped instructions from the IRInstructionMapper, and
passes it to the Suffix Tree to find the repeated substrings. Within
each set of repeated substrings, the IRSimilarityCandidates are compared
against one another for structure, and ensuring that the operands in the
instructions are used in the same way. Each of these structurally
similarity IRSimilarityCandidates are contained in a SimilarityGroup.
Tests checking for identifying identity of structure, different
isomorphic structure, and different
nonisomoprhic structure are found in
unittests/Analysis/IRSimilarityIdentifierTest.cpp.
Differential Revision: https://reviews.llvm.org/D86972
This patch makes the 'ExtLen' field of extended opcodes optional. We
don't need to manually calculate it in the future.
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D88136
Since DWARFv5 places TUs in debug_info, some of DWARFContext's APIs have
become a bit erroneous, including TUs in the CU list by accident.
Correct that by providing compile_units (& dwo_compile_units) that
filter out the type units from the debug_info units.
Differential Revision: https://reviews.llvm.org/D87935
Flag DIEs that have DW_CHILDREN_yes set in their abbreviation but don't
actually have any children.
rdar://59809554
Differential revision: https://reviews.llvm.org/D88048
This patch implements custom codegen for the vec_replace_elt and
vec_replace_unaligned builtins.
These builtins map to the @llvm.ppc.altivec.vinsw and @llvm.ppc.altivec.vinsd
intrinsics depending on the arguments. The main motivation for doing custom
codegen for these intrinsics is because there are float and double versions of
the builtin. Normally, the converting the float to an integer would be done via
fptoui in the IR. This is incorrect as fptoui truncates the value and we must
ensure the value is not truncated. Therefore, we provide custom codegen to utilize
bitcast instead as bitcasts do not truncate.
Differential Revision: https://reviews.llvm.org/D83500
Just because sequences of instructions are similar to one another,
doesn't mean they are doing the same thing.
This introduces a structural check for the IRSimilarityCandidate that
compares two IRSimilarityCandidates against one another, and in each
instruction creates a mapping between the operands and results, or
checks that the existing mapping is valid. If this check passes, it
means we have structurally similar IRSimilarityCandidates.
Tests for whether the candidates are found in
unittests/Analysis/IRSimilarityIdentifierTest.cpp.
Recommit of: b27db2bb68 for Differential
URL.
Differential Revision: https://reviews.llvm.org/D86971
Just because sequences of instructions are similar to one another,
doesn't mean they are doing the same thing.
This introduces a structural check for the IRSimilarityCandidate that
compares two IRSimilarityCandidates against one another, and in each
instruction creates a mapping between the operands and results, or
checks that the existing mapping is valid. If this check passes, it
means we have structurally similar IRSimilarityCandidates.
Tests for whether the candidates are found in
unittests/Analysis/IRSimilarityIdentifierTest.cpp.
* Move computation of systemLibraryRoots into a separate function, so we
can add more functionality to it without things becoming unwieldy
* Have `getSearchPaths` and related functions return by value instead of
by output parameter. NRVO should ensure that performance is unaffected.
Reviewed By: #lld-macho, smeenai
Differential Revision: https://reviews.llvm.org/D87959
They cause their corresponding libraries / frameworks to be loaded via
`LC_LOAD_WEAK_DYLIB` instead of `LC_LOAD_DYLIB`.
Reviewed By: #lld-macho, gkm
Differential Revision: https://reviews.llvm.org/D87929
Handle the case where there are both common and non-common definitions
of the same symbol. Add a bunch of tests to ensure compatibility with ld64.
Reviewed By: #lld-macho, gkm
Differential Revision: https://reviews.llvm.org/D86910
On Unix, it is traditionally allowed to write variable definitions without
initialization expressions (such as "int foo;") to header files. These are
called tentative definitions.
The compiler creates common symbols when it sees tentative definitions. When
linking the final binary, if there are remaining common symbols after name
resolution is complete, the linker converts them to regular defined symbols in
a `__common` section.
This diff implements most of that functionality, though we do not yet handle
the case where there are both common and non-common definitions of the same
symbol.
Reviewed By: #lld-macho, gkm
Differential Revision: https://reviews.llvm.org/D86909
Fix the verifier so that overlapping SGPR operands are counted
independently. We cannot assume that overlapping SGPR accesses
only count as a single constant bus use.
The exception is implicit uses which do not add to constant bus
usage (only) when overlapping.
Reviewed By: rampitec
Differential Revision: https://reviews.llvm.org/D87748
Used by kexec-tools (PR46942)
In GNU as, tc-i386.c:output_jump uses 4-byte immediate if a data32 prefix is present.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D88137
Alexey Lapshin