Note that we could use the initial address in the cooked character stream as the basis for the "<" operator. I used that in an earlier implementation, and it worked fine and was immune to changes caused by calls to ReplaceName(). But it has the potential problem that there may be cases where we're comparing symbols from .mod files. Peter's solution of serial numbers would fix this.

In D97774#2598594, @PeteSteinfeld wrote:

In D97774#2598541, @kiranchandramohan wrote:

I see a failure in the buildbot.
https://lab.llvm.org/buildbot/#/builders/33/builds/2845

/home/flang/flang-aarch64-ubuntu-clang/flang-aarch64-ubuntu-clang/llvm-project/flang/lib/Semantics/resolve-names.cpp:3655:25: error: loop variable 'procInCycle' of type 'const Fortran::common::Reference<const Fortran::semantics::Symbol>' creates a copy from type 'const Fortran::common::Reference<const Fortran::semantics::Symbol>' [-Werror,-Wrange-loop-construct]

for (const auto procInCycle : procsInCycle) {
                ^

/home/flang/flang-aarch64-ubuntu-clang/flang-aarch64-ubuntu-clang/llvm-project/flang/lib/Semantics/resolve-names.cpp:3655:14: note: use reference type 'const Fortran::common::Reference<const Fortran::semantics::Symbol> &' to prevent copying

for (const auto procInCycle : procsInCycle) {
     ^~~~~~~~~~~~~~~~~~~~~~~~
                &

Thanks, @kiranchandramohan. I'll fix this.

In D97774#2598541, @kiranchandramohan wrote:

I see a failure in the buildbot.
https://lab.llvm.org/buildbot/#/builders/33/builds/2845

/home/flang/flang-aarch64-ubuntu-clang/flang-aarch64-ubuntu-clang/llvm-project/flang/lib/Semantics/resolve-names.cpp:3655:25: error: loop variable 'procInCycle' of type 'const Fortran::common::Reference<const Fortran::semantics::Symbol>' creates a copy from type 'const Fortran::common::Reference<const Fortran::semantics::Symbol>' [-Werror,-Wrange-loop-construct]

for (const auto procInCycle : procsInCycle) {
                ^

/home/flang/flang-aarch64-ubuntu-clang/flang-aarch64-ubuntu-clang/llvm-project/flang/lib/Semantics/resolve-names.cpp:3655:14: note: use reference type 'const Fortran::common::Reference<const Fortran::semantics::Symbol> &' to prevent copying

for (const auto procInCycle : procsInCycle) {
     ^~~~~~~~~~~~~~~~~~~~~~~~
                &

Superseded by D97749.

Fixed the formatting of an error message as suggested by Tim.

I changed the solution to the problem with SymbolSet having an inconsistent "<"
operator by making it unordered.

Responding to Peter's and Tim's comments. The "<" operator is used not only
for SymbolSet, but it's also used to sort the elements in a SymbolVector in
several places. The simplest and least disruptive fix was to follow another
suggestion from Tim to record the initial value of a symbol's name and use that
initial value as the basis for the "<" operator. This change makes the result
of the "<" operator immune to calls to "ReplaceName()".

All builds, tests, and looks good.

All builds, tests, and looks good.

Responding to comments from Tim. I made the functions that characterize
Procedure, DummyArgument, and DummyProcedure that are mutually recursive all be
static and reside completely in characteristics.cpp. I also started using the
type SymbolSet and recoded the function to create a string of comma separated
names to use a utility from LLVM.

Added a reference to the standard.

Trying to improve the error message when a circularity is detected. I added a
list of the procedures in the cycle.

In D96631#2561336, @klausler wrote:

I think there's ways by which the characteristics of a procedure could be self-dependent besides the use of a dummy procedure, so you might want a less specific error. But that's probably the most common way that a user can get themselves into trouble with this sort of thing, so you might be okay. Improve or change the message as you like, or not. Maybe Tim can suggest better wording.

Responding to Peter's feedback -- an attempt to clarify the error message.

All builds, tests, and looks good.

f18.cpp needs to have clang-format run on it. Otherwise, all builds, tests, and looks good.

In D95080#2523025, @MaskRay wrote:

In your commit the message does not include Reviewed by:. Many people agree that both Reviewed by: & Differential Revision: should be present. The Reviewed by: list indicates people who acknowledged the patch. (The Reviewers: list does not necessarily mean all the people on the list have acknowledged the patch so Reviewers: is mostly useless.)

arc amend can fetch the Phabricator summary and amend the local description.

You can install llvm/utils/git/pre-push.py to prevent accidental Summary:, Reviewers:, Subscribers: and Tags: in the presence of Differential Revision:.

All builds, tests, and looks good.

All builds, tests, and looks good.

All builds, tests, and looks good.

All builds, tests, and looks good.

All builds, tests, and looks good.

Responsed to comments from Tim.

Changes in response to comments by Tim. Basically, better handling with
respect to moving data around by using rvalue references and eliminating
unnecessary use of the type "std::optional<>".

All looks good. Thanks for the fast action!

When I look at the history of mlir/include/mlir/Dialect/Linalg/Transforms/CodegenStrategy.h, the latest change is this commit. Are you able to build LLVM with this change?

I tried building LLVM from scratch this morning, and I got an error:

I implemented a separate class to handle changing the lower bounds of array
constants as suggested by Peter. In the process I noticed that there was an
unused class in Evaluate/check-expression.cpp. Also, when implementing the new
class I found a bug when handling parenthesized expressions which also exists
in the class I was previously using, so I fixed it in both places. I also
added new tests that include parenthesized expressions.

In D95449#2523153, @klausler wrote:

Can you fix the problem by just calling "x.set_lbounds(GetLowerBounds())" on the folded result array and leaving ScalarConstantExpander alone?

All builds, tests, and looks good.

All builds, tests, and looks good.

I don't understand these changes very well, but it all builds and tests correctly.

All builds, tests, and looks good.

All builds, tests, and looks good.

All builds, tests, and looks good.

I changed this update to just add some tests and a new error message.

This is an odd quirk of the language.

All builds, tests, and looks good.

In D94505#2493131, @klausler wrote:

If a dummy procedure has an explicit interface, the actual procedure must conform to it (15.5.2.9 paragraph 1). Do your changes allow a actual procedure with an implicit interface to be associated with a dummy procedure with an explicit interface?