[all-commits] [llvm/llvm-project] 7dd7cc: [flang] Fail at link time if derived type descript...

[jeanPerier via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7dd7ccd2247052528ea6bbfbd37c7c7e589ac5cb
      https://github.com/llvm/llvm-project/commit/7dd7ccd2247052528ea6bbfbd37c7c7e589ac5cb
  Author: Jean Perier <jperier at nvidia.com>
  Date:   2022-02-14 (Mon, 14 Feb 2022)

  Changed paths:
    M flang/include/flang/Optimizer/Support/InternalNames.h
    M flang/include/flang/Semantics/runtime-type-info.h
    M flang/include/flang/Semantics/symbol.h
    M flang/lib/Optimizer/CodeGen/CodeGen.cpp
    M flang/lib/Optimizer/Support/InternalNames.cpp
    M flang/lib/Semantics/runtime-type-info.cpp
    M flang/test/Fir/convert-to-llvm.fir
    M flang/test/Semantics/typeinfo01.f90

  Log Message:
  -----------
  [flang] Fail at link time if derived type descriptors were not generated

Currently, code generation was creating weak symbols for derived type
descriptor global it could not find in the current compilation unit.
The rational is that:
 - the derived type descriptors of external module derived types are
   generated in the compilation unit that compiled the module so that
   the type descriptor address is uniquely associated with the type.
 - some types do not have derived type descriptors: the builtin derived
   types used to create derived type descriptors. The runtime knows
   about them and does not need them to accomplish the feat of
   describing themselves. Hence, all unresolved derived type descriptors
   in codegen cannot be assumed to be resolved at link time.

However, this caused immense debugging pain when, for some reasons, derived
type descriptor that should be generated were not. This caused random
runtime failures instead of a much cleaner link time failure.

Improve this situation by allowing codegen to detect the builtin derived
types that have no derived type descriptors and requiring the other
unresolved derived type descriptor to be resolved at link time.

Also make derived type descriptor constant data since this was a TODO
and makes the situation even cleaner. This requiring telling lowering
which compiler created symbols can be placed in read only memory. I
considered using PARAMETER, but I have mixed feeling using it since that
would cause the initializer expressions of derived type descriptor to
be invalid from a Fortran point of view since pointer targets cannot be
parameters. I do not want to start misusing Fortran attributes, even if
I think it is quite unlikely semantics would currently complain. I also
do not want to rely on the fact that all object symbols with the
CompilerCreated flags are currently constant data. This could easily
change in the future and cause runtime bugs if lowering rely on this
while the assumption is not loud and clear in semantics.
Instead, add a ReadOnly symbol flag to tell lowering that a compiler
generated symbol can be placed in read only memory.

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