[PATCH] D100897: [flang] Make 'team_number()' an intrinsic function

Craig E Rasmussen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 8 12:07:18 PDT 2021


craig.rasmussen added inline comments.


================
Comment at: flang/include/flang/Evaluate/type.h:132
 
+  static constexpr DynamicType MissingDerivedType() {
+    DynamicType result;
----------------
klausler wrote:
> craig.rasmussen wrote:
> > klausler wrote:
> > > craig.rasmussen wrote:
> > > > This function (whatever it is named) is critical to get team_number to work with a missing optional team arguments.  Otherwise the check  
> > > > 
> > > > CHECK(IsValidKindOfIntrinsicType(category_, kind_));
> > > > 
> > > > disallows the construction of a DynamicType that is not an intrinsic type.
> > > > 
> > > When the derived type TEAM_TYPE from intrinsic module ISO_FORTRAN_ENV is available, this MissingDerivedType() is not required, right?
> > Correct.  This is tested by the new test team_number.f90 (added in this patch).  If the actual argument is available the dummy argument is created from the actual with
> > 
> >         auto dc{characteristics::DummyArgument::FromActual(
> >             std::string{d.keyword}, *expr, context)};
> > 
> > see semantics.cpp line 1651.  Although to be clear, the derived type TEAM_TYPE will have already been loaded from ISO_FORTRAN_ENV via a USE statement by this time, it is just not directly available.
> So when the optional argument is absent, the type is *not* TEAM_TYPE from ISO_FORTRAN_ENV, even if that type is available?
I'm not sure sure I understand the question fully but I'll give it a try.  If the actual argument is missing, the dummy argument type, TEAM_TYPE, remains the same. However, one can't create a characteristics::DummyArgument from the actual argument (which happens if the actual is present) as it is missing. Thus I created the new function MissingDerivedType() to create a DynamicType.

Admittedly, the DynamicType is not well formed because the derived_ member is a nullptr.  However, is the semantic checking that follows this does not create a problem because when the actual argument is missing, there is not type comparison done between the actual argument (since it is missing) and the dummy argument.

If I understand correctly, I don't think the AST is mutated during this pass the DynamicType returned by MissingDerivedType() is not ultimately kept around.


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

https://reviews.llvm.org/D100897



More information about the llvm-commits mailing list