When a global procedure has no explicit interface, emit warnings
when its references are inconsistent implicit procedure interfaces.
Differential Revision: https://reviews.llvm.org/D145097
Move MaxDepth into the lambda, since it is not needed outside. This
fixes some compilers that complain about missing capture:
error C3493: 'MaxDepth' cannot be implicitly captured because no
default capture mode has been specified
Fixes: f693932fbe ("[SelectionDAG] Transitively copy NodeExtraInfo on RAUW")
GISel's CSE mechanism lazily inserts instructions into the CSE List
to improve on efficiency as well as efficacy of CSE
(for allowing partially built instructions to be fully built).
There's unfortunately a mutual recursion via
`handleRecordedInsts -> handleRecordedInst -> insertNode-> handleRecordedInsts`.
So this change simply records that we're already draining this list so we can just bail out on the recursion.
No changes to codegen are expected as we're still draining/handling the temporary
list via pop_back and we should get the same sequence of instructions
whether we call pop_back in a loop at the top level or recursive.
https://reviews.llvm.org/D145006
reviewed by: dsanders
Revert while I investigate two CI bot failures;
the more important is the lldb-arm-ubuntu where
the FixAddress is removing the 0th bit so we're
adding the `actual=` decorator on a string pointer,
```
Got output:
(char *) strptr = 0x00400817 (actual=0x400816) ptr = [{ },{H}]
```
in TestDataFormatterSmartArray.py line 229.
This reverts commit 4d635be2db.
I also removed two runlines which added no additional coverage. No test in the file has both loads and stores, thus the two configurations duplicate the disabled configuration.
Implement the --build-id flag similarly to ELF, and generate a build_id
section according to the WebAssembly tool convention specified in
https://github.com/WebAssembly/tool-conventions/pull/183
The default style ("fast" aka "tree") hashes the contents of the output
and (unlike ELF) generates a v5 UUID based on the hash (using a random
namespace).
It also supports generating a random v4 UUID, a sha1 hash,
and a user-specified string (as ELF does).
Differential Revision: https://reviews.llvm.org/D107662
During legalization of the SelectionDAG, some nodes are replaced with
arch-specific nodes. These may be complex nodes, where the root node no
longer corresponds to the node that should carry the extra info.
Fix the issue by copying extra info to the new node and all its new
transitive operands during RAUW. See code comments for more details.
This fixes the remaining pcsections-atomics.ll tests on X86.
v2: Optimize copyExtraInfo() deep copy. For now we assume that only
NodeExtraInfo that have PCSections set require deep copy. Furthermore,
limit the depth of graph search while pre-populating the visited set,
assuming the to-be-replaced subgraph 'From' has limited complexity. An
assertion catches if the maximum depth needs to be increased.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D144677
Currently, the selector of a construct entity (e.g., ASSOCIATE(x=>a(1:20)))
is inheriting the CONTIGUOUS attribute from its associated variable
even if it has subscripts that make it noncontiguous (a(1:20:2)).
Add construct entities to the dynamic contiguity predicate instead.
Differential Revision: https://reviews.llvm.org/D145114
A common reason for LLDB failing to attach to an already-running process on Linux is the Yama security module: https://www.kernel.org/doc/Documentation/security/Yama.txt. This patch adds an explaination and suggested fix when it detects that case happening.
This was previously proposed in D106226, but hasn't been updated in a while. The last request was to put the check in a target-specific location, which is the approach this patch takes. I believe Yama only exists on Linux, so it's put in that package.
This has no end-to-end test because I'm not sure how to set `ptrace_scope` in a test environment -- if there are suggestions on how to do that, I'd be happy to add it. (Also, setting it to `3` is comically irreversible). I tested this locally.
Reviewed By: DavidSpickett, labath
Differential Revision: https://reviews.llvm.org/D144904
This patch simplifies the loop inside each worker by extracting index retrieval into a lambda function.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D145101
A BLOCK construct may not contain a statement function definition;
but it may of course contain an assignment statement with an array
element on its left-hand side that looks like a statement function
definition. These misparsed statement functions are converted
into assignment statements during semantics once it is clear what
they are. Move the C1107 check for a statement function definition
in a block construct into declaration checking, which is where it
probably should have been in the first place anyway.
Differential Revision: https://reviews.llvm.org/D145112
This patch makes sure the ordering of TUs in the input CDB is preserved in the full output. Previously, the results were pushed into a global vector, potentially out-of-order and then sorted by the input file name. This is non-deterministic when the CDB contains multiple entries with the same input file. This patch fixes that by pre-allocating the output vector and writing directly to the position corresponding to the current input. This also eliminates one critical section.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D145098
On target where metadata is stored in bits that aren't used for
virtual addressing -- AArch64 Top Byte Ignore and pointer authentication
are two examples -- an SBValue object representing a pointer will
return the address with metadata for SBValue::GetValueAsUnsigned.
Users may want to get the virtual address without the metadata;
this new method gives them a way to do this.
Differential Revision: https://reviews.llvm.org/D142792
This patch should fix the build failures in the Lua ScriptedInterpreter
introduced by 9a9fce1fed.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch should fix the build failures in the Lua ScriptedInterpreter
introduced by 9a9fce1fed.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This test did not exist when I added the previous set of XFAILs (and the
libc++ FreeBSD CI runner is not yet active).
Reviewed by: Mordante
Differential Revision: https://reviews.llvm.org/D145120
This patch changes the implementation of clang-format-diff.py to
start up many clang-format processes in parallel in order to speed
up clang-format-diff.py by several orders of magnitude on large
patches.
Differential Revision: https://reviews.llvm.org/D141230
The paper was making minor corrections to the standard that Clang had
already implemented. This adds (most of) the test coverage for the
paper and claims support. In my testing, we supported this in Clang 15.
There are two ways of specifying a CPU on PowerPC:
power<N> and pwr<N>. Clang/LLVM traditionally
supports the latter and Clang replaces the former
with the latter when passing it to the back end for
the -mcpu= option. However, when the -mtune= option
was introduced, this replacement was not implemented for it.
This leaves us in an inconsistent state of accepting
both forms for -mcpu= and and only the latter for
-mtune=. Furthermore, it leaves us incompatible with
GCC which only understands the power<N> version for
both options.
This patch just adds the same handling for the long
names for -mtune= as already exists for -mcpu=.
Differential revision: https://reviews.llvm.org/D144967
This is a mechanical prep change for scalable vector support. All it does is move the point of TypeSize to unsigned (i.e. the unsafe cast) closer to point of use.
When the left-hand side of an allocatable assignment has an explicit character length,
rather than a deferred length that might imply reallocation, handle any discrepancy
in lengths via truncation or blank padding.
Differential Revision: https://reviews.llvm.org/D145111
The compiler currently ignores attributes for PASS dummy arguments that
are incompatible between a type-bound procedure in an extended type and
the binding of the same name that it overrides in an ancestor type,
if any. Strengthen this checking so that discrepancies between attributes
and intents are caught, and add some tests.
Differential Revision: https://reviews.llvm.org/D145110
A generic procedure binding in an extended derived type may not have the
same name as a symbol inherited from an ancestor type unless that inherited
symbol is also a generic TBP. Since generic names can be things like
"ASSIGNMENT(=)", name resolution doesn't use OkToAddComponent() for
generic TBPs, which would have caught this error as it does for other
symbols in derived types, so it must be special-cased.
Differential Revision: https://reviews.llvm.org/D145109
The Fortran standard's various restrictions on the use of BIND(C)
often depend more on the presence or absence of an explicit NAME=
specification rather than on its value, but semantics and module
file generation aren't making distinctions between explicit NAME=
specifications that happen to match the default name and declarations
that don't have NAME=. Tweak semantics and module file generation
to conform, and also complain when named BIND(C) attributes are
erroneously applied to entities that can't support them, like
ABSTRACT interfaces.
Differential Revision: https://reviews.llvm.org/D145107
Fortran doesn't allow a BIND(C) variable or a component of a BIND(C)
type to be an array with no elements.
Differential Revision: https://reviews.llvm.org/D145106
When a procedure binding in a derived type has PRIVATE accessibility,
it may not be an override of a type-bound procedure that is accessible.
Differential Revision: https://reviews.llvm.org/D145104
Generic interfaces are not permitted to have intrinsic procedures or
statement functions as specific procedures.
Differential Revision: https://reviews.llvm.org/D145103
Provide the name of the construct and the clause info (reduction)
in the TODO mesage.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D145061
A procedure defined in an ABSTRACT INTERFACE may not appear as
a specific procedure in a generic interface.
Differential Revision: https://reviews.llvm.org/D145102
The Fortran 2018 standard, perhaps as an attempt to prevent ambiguity
in older compilers, requires that a statement function appear in an
explicit type declaration statement if its name is also accessible
from a host scope. F18 processes the specification parts of inner
procedures first, so we don't need this requirement to prevent
ambiguity, and can only really check it retrospectively after name
resolution. Emit a portability warning when appropriate.
Differential Revision: https://reviews.llvm.org/D145100
