[PATCH] D119555: [flang] Fail at link time if derived type descriptors were not generated

[Jean Perier via Phabricator via llvm-commits]

jeanPerier created this revision.
jeanPerier added reviewers: klausler, schweitz, clementval.
jeanPerier added a project: Flang.
Herald added subscribers: mehdi_amini, jdoerfert.
Herald added a reviewer: sscalpone.
jeanPerier requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

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.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D119555

Files:
  flang/include/flang/Common/builtin-modules.h
  flang/include/flang/Optimizer/Support/InternalNames.h
  flang/include/flang/Semantics/symbol.h
  flang/lib/Optimizer/CodeGen/CodeGen.cpp
  flang/lib/Optimizer/Support/InternalNames.cpp
  flang/lib/Semantics/runtime-type-info.cpp
  flang/test/Fir/convert-to-llvm.fir
  flang/test/Semantics/typeinfo01.f90

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D119555.407908.patch
Type: text/x-patch
Size: 35754 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220211/d28b6326/attachment.bin>