[all-commits] [llvm/llvm-project] 803f1e: [flang] Fix spurious errors from runtime derived t...

Peter Klausler via All-commits all-commits at lists.llvm.org
Thu Apr 22 09:44:21 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 803f1e46539765688c5e035bdb22289f08ebb8d1
      https://github.com/llvm/llvm-project/commit/803f1e46539765688c5e035bdb22289f08ebb8d1
  Author: peter klausler <pklausler at nvidia.com>
  Date:   2021-04-22 (Thu, 22 Apr 2021)

  Changed paths:
    M flang/include/flang/Evaluate/tools.h
    M flang/lib/Evaluate/fold-implementation.h
    M flang/lib/Evaluate/fold-integer.cpp
    M flang/lib/Semantics/runtime-type-info.cpp
    M flang/lib/Semantics/type.cpp
    M flang/test/Semantics/modfile22.f90
    M flang/test/Semantics/typeinfo01.f90
    M flang/tools/f18/f18.cpp

  Log Message:
  -----------
  [flang] Fix spurious errors from runtime derived type table construction

Andrezj W. @ Arm discovered that the runtime derived type table
building code in semantics was detecting fatal errors in the tests
that the f18 driver wasn't printing.  This patch fixes f18 so that
these messages are printed; however, the messages were not valid user
errors, and the rest of this patch fixes them up.

There were two sources of the bogus errors.  One was that the runtime
derived type information table builder was calculating the shapes of
allocatable and pointer array components in derived types, and then
complaining that they weren't constant or LEN parameter values, which
of course they couldn't be since they have to have deferred shapes
and those bounds were expressions like LBOUND(component,dim=1).

The second was that f18 was forwarding the actual LEN type parameter
expressions of a type instantiation too far into the uses of those
parameters in various expressions in the declarations of components;
when an actual LEN type parameter is not a constant value, it needs
to remain a "bare" type parameter inquiry so that it will be lowered
to a descriptor inquiry and acquire a captured expression value.

Fixing this up properly involved: moving some code into new utility
function templates in Evaluate/tools.h, tweaking the rewriting of
conversions in expression folding to elide needless integer kind
conversions of type parameter inquiries, making type parameter
inquiry folding *not* replace bare LEN type parameters with
non-constant actual parameter values, and cleaning up some
altered test results.

Differential Revision: https://reviews.llvm.org/D101001




More information about the All-commits mailing list