[PATCH] D120396: [flang] Support export/import OpenMP Threadprivate Flag

Kiran Chandramohan via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 24 02:37:19 PST 2022


kiranchandramohan added inline comments.


================
Comment at: flang/lib/Semantics/mod-file.cpp:328
+                   if (symbol.test(Symbol::Flag::OmpThreadprivate) &&
+                       !FindCommonBlockContaining(symbol)) {
+                     decls_ << "!$omp threadprivate(" << symbol.name() << ")\n";
----------------
peixin wrote:
> schweitz wrote:
> > What are the expectations of having a variable that is both in a COMMON block and flagged as OMP thread private? (This suggests COMMON will have priority over thread private.)
> > 
> > I think you should have a test case below to check that combination of conditions and ensure against regressions, etc.
> An element of common block cannot be in Threadprivate directive. The semantic check is in https://github.com/llvm/llvm-project/blob/3e3e79a9e4c378b59f5f393f556e6a84edcd8898/flang/lib/Semantics/check-omp-structure.cpp#L879-L883. The Threadprivate flag is resolved as every element has the flag (https://github.com/llvm/llvm-project/blob/3e3e79a9e4c378b59f5f393f556e6a84edcd8898/flang/lib/Semantics/resolve-directives.cpp#L1640-L1652). No addition information needs to be exported for common block in Threadprivate directive.
> 
> Added the test case for common block.
Would it be better to always generate the declarative directives, irrespective of conditions and then use it conditionally?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120396/new/

https://reviews.llvm.org/D120396



More information about the llvm-commits mailing list