This is an archive of the discontinued LLVM Phabricator instance.

[flang] Allow to use already existing names for contruct-name
AbandonedPublic

Authored by FruitClover on Mar 3 2022, 9:38 PM.

Details

Reviewers
klausler
Summary

Relax reference checks to allow reuse ObjectEntries names in scope for newerly
created construct-name.

Fortran has restriction that for do-construct-name corresponding end-do shall
be at end-do-stmt specifying the same do-construct-name, and gfortran/nvfortran
allows to reuse names from objects.

Diff Detail

Event Timeline

FruitClover created this revision.Mar 3 2022, 9:38 PM
FruitClover created this object with visibility "FruitClover (Mike K)".
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2022, 9:38 PM
FruitClover requested review of this revision.Mar 3 2022, 9:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2022, 9:38 PM
FruitClover changed the visibility from "FruitClover (Mike K)" to "Public (No Login Required)".Mar 3 2022, 9:51 PM
FruitClover set the repository for this revision to rG LLVM Github Monorepo.Mar 3 2022, 10:00 PM
FruitClover retitled this revision from [flang] Allow to use already exising names for contruct-name to [flang] Allow to use already existing names for contruct-name.Mar 3 2022, 11:59 PM
FruitClover edited the summary of this revision. (Show Details)Mar 4 2022, 12:53 AM
klausler added inline comments.Mar 4 2022, 8:58 AM
flang/lib/Semantics/resolve-names.cpp
614

"details" is being passed by value; perhaps a const reference would be better.

615

Two things here: first, this doesn't need to be an if statement, it can be just a simple return statement.

Second, why allow this only for object entities? Wouldn't any symbol other than another construct name be allowable?

FruitClover added inline comments.Mar 8 2022, 8:34 PM
flang/lib/Semantics/resolve-names.cpp
615

Second, why allow this only for object entities? Wouldn't any symbol other than another construct name be allowable?

You are right and actually there is uncovered case when variable named as construct-name used inside construct scope: (from Fortran 2018, 19.3, also asked gfortran folks here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 to be sure)

subroutine s1
  logical :: x
  x: if (x) then  ! should be an error
  end if x
end

Is ScopeHandler::PushScope the right place for such fix or it should be done in expression.cpp?

Please consult subclause 19.3.1 of the Fortran 2018 standard. Named constructs are in the same class as most other local entities. I don't think that what you're trying to do here is standard-conforming.

FruitClover abandoned this revision.Apr 5 2022, 9:05 AM

Please consult subclause 19.3.1 of the Fortran 2018 standard. Named constructs are in the same class as most other local entities. I don't think that what you're trying to do here is standard-conforming.

Thanks, flang is right and current PR was based on gfortran behavior that accepts non-conforming code for corner cases, proposed fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 to gfortran instead.
Closed.