Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added OpenMP 5.0 specification based semantic checks for CRITICAL con… #1128

Open
wants to merge 2 commits into
base: fir-dev
Choose a base branch
from

Conversation

NimishMishra
Copy link

…struct name resolution

Cherry picking https://reviews.llvm.org/D110502 onto fir-dev branch

@NimishMishra
Copy link
Author

NimishMishra commented Oct 13, 2021

@kiranchandramohan @clementval Could you please see if this is fine?

All of the parser changes have already been done in NimishMishra@7a22c26 , so those are skipped

@schweitzpgi
Copy link

I get compilation failures with this patch.

check-omp-structure.cpp:1020:65: error: ?const struct Fortran::parser::Verbatim? has no member named ?t?
   const auto &dirName{std::get<std::optional<parser::Name>>(dir.t)};
                                                                 ^

Copy link

@schweitzpgi schweitzpgi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does not compile.

I assume there is something that needs to be chery-picked from main here.

@kiranchandramohan
Copy link
Collaborator

I cannot compile either.

@NimishMishra
Copy link
Author

Fixed build failures. @kiranchandramohan @schweitzpgi it is compiling for me now. Please check once.

Copy link
Collaborator

@kiranchandramohan kiranchandramohan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still have a build failure. See inline comment.

Also, have two failed tests after fixing the build failure.
Failed Tests (2):
Flang :: Lower/OpenMP/critical.f90
Flang :: Semantics/omp-sync-critical02.f90

flang/lib/Semantics/resolve-directives.cpp Outdated Show resolved Hide resolved
@NimishMishra
Copy link
Author

@kiranchandramohan Please check this PR. For me, ninja check-flang has one test case failing. But I am not sure how this relates to my PR. Perhaps this has something to do with Lowering that the fir-dev branch has. Any ideas on what changes in my PR could be causing this? I am not at all versed with lowering yet

FAIL: Flang :: Lower/OpenMP/critical.f90 (8 of 1157)
******************** TEST 'Flang :: Lower/OpenMP/critical.f90' FAILED ********************
Script:
--
: 'RUN: at line 3';   bbc -fopenmp -emit-fir /home/manwe/Desktop/f18-llvm-project/flang/test/Lower/OpenMP/critical.f90 -o - |    /home/manwe/Desktop/f18-llvm-project/build/bin/FileCheck /home/manwe/Desktop/f18-llvm-project/flang/test/Lower/OpenMP/critical.f90 --check-prefix=FIRDialect
: 'RUN: at line 5';   bbc -fopenmp /home/manwe/Desktop/f18-llvm-project/flang/test/Lower/OpenMP/critical.f90 -o - |    tco --disable-llvm --print-ir-after=fir-to-llvm-ir 2>&1 |    /home/manwe/Desktop/f18-llvm-project/build/bin/FileCheck /home/manwe/Desktop/f18-llvm-project/flang/test/Lower/OpenMP/critical.f90 --check-prefix=LLVMIRDialect
: 'RUN: at line 8';   bbc -fopenmp -emit-fir /home/manwe/Desktop/f18-llvm-project/flang/test/Lower/OpenMP/critical.f90 -o - |    tco | /home/manwe/Desktop/f18-llvm-project/build/bin/FileCheck /home/manwe/Desktop/f18-llvm-project/flang/test/Lower/OpenMP/critical.f90 --check-prefix=LLVMIR
--
Exit Code: 2

Command Output (stderr):
--
bbc: /home/manwe/Desktop/f18-llvm-project/flang/lib/Lower/PFTBuilder.cpp:1315: int {anonymous}::SymbolDependenceDepth::analyze(const Fortran::semantics::Symbol&): Assertion `symTy && "symbol must have a type"' failed.

const auto pair{GetContext().scope.try_emplace(
name.source, Attrs{}, UnknownDetails{})};
name.source, Attrs{}, ObjectEntityDetails{})};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you set it back to UnknownDetails it will work. I think for ObjectEntityDetails there are additional requirements.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. This solved the erring test case.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will @clementval @jeanPerier or @schweitzpgi know the importance of using the correct details here? AFAIU, for the name of critical sections we do not need ObjectEntityDetails.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@klausler is it OK to use UnknownDetails here? This is for the name of an OpenMP Critical Section for which I think the ObjectEntityDetails do not apply.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UnknownDetails is mostly a place-holder intended to be replaced once more is known about a symbol.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NimishMishra can you test @klausler's point, i.e what happens when we have a critical construct whose name matches a variable in the same scope?

The OpenMP standard says the following,
The names of critical constructs are global entities of the program. If a name conflicts with any other entity, the behavior of the program is unspecified.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following works fine in fir-dev branch:

program sample
     use omp_lib
     integer :: foo, bar
     bar = 0
     !$omp critical (foo)
          bar = bar + 1
     !$omp end critical (foo)
end program sample

Running as flang-new -fc1 -fopenmp <FILENAME>.f90 gives no semantic problems at all.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also check conflicts with construct names (like a named do loop ) ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked. The semantics phase doesn't complain.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great thanks ! Could you add a regression test (I guess a symbol test would be the best (like these tests)) with both the variable name and construct name that are the same as the critical name just to be sure this property continues to hold true.

flang/lib/Semantics/resolve-directives.cpp Outdated Show resolved Hide resolved
@kiranchandramohan
Copy link
Collaborator

@sscalpone @schweitzpgi : Can you add @NimishMishra to this repo so that he can add reviewers and request reviewers? @NimishMishra works for Flang at AMD.

@kiranchandramohan
Copy link
Collaborator

I think we should not have merge commits in the PRs. Can you make this PR as a few commits,

  1. The cherry-picked upstream commit + any minor changes required to apply the patch.
  2. Changes for MiscDetails.

@NimishMishra
Copy link
Author

I think we should not have merge commits in the PRs. Can you make this PR as a few commits,

  1. The cherry-picked upstream commit + any minor changes required to apply the patch.
  2. Changes for MiscDetails.

@kiranchandramohan I have collapsed all into one commit. Please have a look

@jeanPerier
Copy link
Collaborator

Hi, I have just rebased fir-dev on LLVM 85bf221 from last week.
That means you will need to update this PR with the rebased fir-dev.
You cannot simply rebase your PR with fir-dev (it will try to reapply all fir-dev changes).

You can update the PR as follow (assuming your branch is called my-branch):

  • backup your branch into my-branch-bckup (just to be safe :) )
  • create a new branch my-branch-new following the new fir-dev head
  • cherry-pick all your commits from this PR into my-branch-new
  • once it looks good, force push my-branch-new into the upstream my-branch (git push origin my-branch-new:my-branch -f )

Sorry for the inconvenience, I could not wait for every PR to get in and solve all new conflicts on my side, the rebase
is meant to help upstreaming so that we can avoid having this too many times again in the future.

@kiranchandramohan
Copy link
Collaborator

Can you add the two tests that were suggested?
Also, change the title and description of the PR to match the present contents.

@NimishMishra
Copy link
Author

Can you add the two tests that were suggested? Also, change the title and description of the PR to match the present contents.

If I run flang-new -fc1 -fopenmp normally, things are fine. But if I do flang-new -fc1 -fdebug-unparse-with-symbols -fopenmp, flang-new crashes. But this happens only when critical construct name and some other program entity's name (an integer for example) collides (check the XFAIL test case).

@NimishMishra
Copy link
Author

Gentle ping!

@schweitzpgi schweitzpgi self-requested a review January 25, 2022 20:01
Copy link
Collaborator

@kiranchandramohan kiranchandramohan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
I guess this has to be now added to upstream llvm-project as well.

@NimishMishra
Copy link
Author

LGTM. I guess this has to be now added to upstream llvm-project as well.

Sure. I'll upstream it

@kiranchandramohan
Copy link
Collaborator

Can you add the two tests that were suggested? Also, change the title and description of the PR to match the present contents.

If I run flang-new -fc1 -fopenmp normally, things are fine. But if I do flang-new -fc1 -fdebug-unparse-with-symbols -fopenmp, flang-new crashes. But this happens only when critical construct name and some other program entity's name (an integer for example) collides (check the XFAIL test case).

I think it should not crash. But not sure whether it is an issue with unparsing. Does -fdebug-dump-symbols pass?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants