We want to move away from those tests and towards explicit .verify.cpp
tests, since those have a simpler model.

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

The common GPU operation transformation that lowers `math` operations
to function calls in the `gpu-to-nvvm` and `gpu-to-rocdl` passes handles
`vector` types by applying the function to each scalar and returning a
new vector. However, there was a typo that results in incorrectly
accumulating the result vector, and the rewrite returns an `llvm.mlir.undef`
result instead of the correct vector. A patch is added and tests are
strengthened.

Reviewed By: ThomasRaoux

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

In the MLIR dataflow analysis framework, when an `AnalysisState` is updated, it's dependents are enqueued to be visited.

Currently, there are two ways dependents are managed:

* `AnalysisState::dependents` stores a list of dependents. `DataFlowSolver::propagateIfChanged()` reads this list and enqueues them to the worklist.

* `AnalysisState::onUpdate()` allows custom logic to enqueue more to the worklist. This is called by `DataFlowSolver::propagateIfChanged()`.

This cleanup diff consolidates the two into `AnalysisState::onUpdate()`. This way, `DataFlowSolver` does not need to know the detail about `AnalysisState::dependents`, and the logic of dependency management is entirely handled by `AnalysisState`.

Reviewed By: Mogball

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

Kind of an edge case.  When a MODULE FUNCTION or SUBROUTINE
interface is defined by a MODULE PROCEDURE in the same program
unit, ensure that the symbol table pointer in the parse tree is
updated to point to the SubprogramDetails symbol for the
interface, and not left pointing to what should soon become
a dead SubprogramNameDetails symbol.

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

Before, we checked and manifested attributes right in the IR. This was
bad as we modified the IR before the manifest stage. Now we can
add/remove/inspect attributes w/o going to the IR (except for the
initial query).

We had some custom manifest for assumption attributes but we use the
generic manifest logic. If we later decide to curb duplication (of
attributes on the call site and callee), we can do that at a single
location and for all attributes.

The test changes basically add known `llvm.assume` callee information to
the call sites.

We had some custom handling for existing MemoryEffects but we now move
it to the place we check other existing attributes before we manifest
new ones. If we later decide to curb duplication (of attributes on the
call site and callee), we can do that at a single location and for all
attributes.

The test changes basically add known `memory` callee information to the
call sites.

This patch should fix some data races when a python script (i.e. a
Scripted Process) has a nested call to another python script (i.e. a
OperatingSystem Plugin), which can cause concurrent writes to the python
lock count.

This patch also fixes a data race happening when resetting the operating
system unique pointer.

To address these issues, both accesses is guarded by a mutex.

rdar://109413039

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



Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

We always assume that this is valid anyway, might as well take a
reference.

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

OPEN statements can be used to change some, but not all, attributes
of units that have already been opened.  The I/O runtime library
wasn't allowing ENCODING= to be changed.  Every other Fortran compiler
permits this usage, and it's safe and useful, so allow it.
(Otherwise there's no good way to ensure that the preconnected
unit 6 is in UTF-8 mode.)

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

We intentionally process NAMELIST groups in a scope after having
resolved all of the names in that scope.  This means that a name
whose first appearance in a scope is in the NAMELIST group resolves
to a local object, if any, rather than to any host associated object.
The standard is unclear on this point, and there is no clear
precedent in other compilers.

This patch doesn't implement this choice -- that was done long ago --
but just documents the behavior in Extensions.md.

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

The code that folds the intrinsic function HYPOT was neglecting to
warn the programmer about overflow when it occurs.

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

We already have LLDB_DEPRECATED which is used to mark methods as
deprecated with a message and an alternative to use instead. This is
expresses an intent of "We recognize this functionality is useful but
there are some pitfalls with the interface we have exposed."

In other cases, there are no "alternative" methods to use and the code should be
refactored to avoid using a method entirely. For example,
`SBValue::Cast` should be avoided in favor of using the expression
evaluator to perform a cast. There isn't a mechanical solution, the
recommendation is to instead refactor your code.

This commit renames the existing `LLDB_DEPRECATED` to
`LLDB_DEPRECATED_FIXME`, and adds a `LLDB_DEPRECATED` macro to cover the
second scenario.

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

I'm not convinced that it makes sense for the paths to be ConstStrings. We're
going to be putting them into FileSpecs (which are backed by
ConstStrings, for now) but otherwise there's no need to store them as
ConstStrings upfront.

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

Based on @peixin test case shared in D153004.

Add a document that summarizes Fortran 202X's upcoming
features and their urgency for implementation.

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

Before we ended up not calling the specialized AAType::isImpliedByIR but
the generic IRAttribute::isImpliedByIR in the IRAttribute::initialize
function.

In a follow up we will reuse the logic in MemoryEffectsBase to merge
AAMemoryLocation and AAMemoryBehavior without duplicating all the bit
fiddling code already available in MemoryEffectsBase.

Reviewed By: nikic

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

Instead of just returning a raw `const char *`, I think llvm::StringRef
would make more sense. Most of the time that we use the return value of
`GetProcessPluginName` we're passing it to `CreateProcess` which takes a
StringRef anyway.

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

Actual argument expressions must be evaluated before the invocation
of the sequence of per-element calls of an impure elemental subprogram.
Otherwise, the side effects of the calls may affect the input for
the consequent elements.
The proposed changes are described by Jean in D154174.

Reviewed By: tblah

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

Update trip count of test in
pr56319-vector-exit-cond-optimization-epilogue-vectorization.ll to
make sure epilogue vectorization will still trigger after D154261,
checking for the original issue.

Move the original test to limit-vf-by-tripcount.ll for testing new
functionality of D154261.

This patch lowers allocatables and pointers named in "private" OpenMP clause.

Reviewed By: kiranchandramohan

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

Index accessing checks are not performed for aliases
of `std::array`, as only `std::array` itself seems to be checked.

This patch aims to extend it for aliases such as:
 `using MyArray = std::array<int, 10>;`

Reviewed By: PiotrZSL

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

Victor Zverovich pointed out[1] that printf takes the field width and
precision arguments before the value to be printed whereas std::print
takes the value first (unless positional arguments are used.) Many of
the test cases in use-std-print.cpp were incorrect.

Teach the check to rotate the arguments when required to correct
this. Correct the test cases and add more.

[1] https://github.com/fmtlib/fmt/pull/3515#issuecomment-1615259893

Reviewed By: PiotrZSL

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

This doesn't really use fast comparison or string uniqueness. In fact,
all of the current callers pass an empty string for type_name. The only
reason I don't remove it is because it looks like it is used downstream
for swift.

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

2/3 of the ConstStrings in this class were just to be able to log
something. Putting something in the StringPool just to log it doesn't
make a lot of sense, so let's remove them.

The remaining use is for `RegisterPersistentDecl` which is fine for now.

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

The soon-to-be-published next revision of the ISO Fortran language standard
contains a couple of breaking changes to previous specifications that may cause
existing programs to silently change their behavior.

For the change that introduces automatic reallocation of deferred length
allocatable character scalar variables when they appear as the targets
of internal WRITE statements, as IOMSG=/ERRMSG= variables, as outputs
of INQUIRE specifiers, or as INTENT(OUT) arguments to intrinsic
procedures, this patch adds an optional portability warning.

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

There are existing implementations for `scf.for`, `scf.forall` and `affine.for`. This revision adds an interface method to the `LoopLikeOpInterface`.

* `scf.forall` now implements the `LoopLikeOpInterface`.
* The implementations of `scf.for` and `scf.forall` become interface method implementations. `affine.for` remains as is for the moment. (The implementation of `promoteIfSingleIteration` depepends on helper functions from `MLIRAffineAnalysis`, which cannot be used from `MLIRAffineDialect`, where the interface is currently implemented.)
* More efficient implementations of `promoteIfSingleIteration`. In particular, the `scf.forall` operation now inlines operations instead of cloning them. This also preserves handles when used from the transform dialect.

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

It is needed for target specific initializatons.

Reviewed By: qcolombet

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

This is a prep patch for D150388. Treating rddsp and wrdsp as copy
instructions was causing test failures as we tried using isCopyInstr()
hook to query target-specific copy instructions for LiveRangeSplitting.

As suggested, removing 'isMoveReg = 1' from wrdsp and rddsp so they
aren't considered simple copy-like instructions for the moment.

Reviewed By: sdardis

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

This commit ensures that the garbage collector attribute of LLVMFuncOps
is exported, even when they are declarations.

This also does some cleanups, I am happy to undo them (or send as
separate patches):
- Change the early exit to stop only once we hit an expansion inside the
  main file, to make sure we keep following the nested expansions.
- Add more tests to cover all the cases mentioned in the implementation
- Drop the adjustments for prev/next tokens. We do the final checks
  based on the expansion locations anyway, so any intermediate mapping
  was a no-op.

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

This patch simply adds a cmake install line for omp_lib.h that was
previously missing, to put it alongisde omp_lib.mod so it can be found
by the driver.

In the case of partially mapped structs, libomptarget sometimes adds
padding to device allocations to ensure they are aligned properly.
However, without this patch, it considers that padding to be mapped to
the host, which can cause presence checks (e.g.,
`omp_target_is_present` or a `present` modifier) to misbehave for
unmapped parts of the struct.  This patch keeps the padding but treats
it as unmapped.  See the new test case for examples.

Reviewed By: grokos, jdoerfert

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

Add `__has_extension (cxx_defaulted_functions)` and
`__has_extension (cxx_default_function_template_args)` since they are
accepted in C++98 mode as extensions.

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

Reviewed By: aaron.ballman

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

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