[flang-commits] [PATCH] D123927: [flang] Do not ICE on recursive function definition in function result

Daniil Dudkin via Phabricator via flang-commits flang-commits at lists.llvm.org
Mon Apr 18 11:41:31 PDT 2022


unterumarmung added inline comments.


================
Comment at: flang/include/flang/Semantics/symbol.h:698
+  inline const DeclTypeSpec *GetTypeImpl(VisitedSymbols &visited) const;
+  inline int RankImpl(VisitedSymbols &visited) const {
+    if (visited.contains(this)) {
----------------
klausler wrote:
> Your changes make Symbol::Rank() and Symbol::GetType() more expensive to call and liable to allocate/deallocate memory for all programs.  Would it be sufficient to just use an integer argument to limit the call depth?  That would avoid a crash in erroneous tests without affecting compilation for correct programs.
That's a great idea! But, to be honest, I'm having a hard time coming up with an initial value for such argument. Is there a limit for number of nested calls of these functions for correct programs? Or, maybe, we should use some //big enough// value that //probably// is not encountered in correct programs, yet lets us avoid the stack overflow?


================
Comment at: flang/lib/Semantics/check-declarations.cpp:1789
     if (!details) {
+      if (generic.test(Symbol::Flag::Function)) {
+        Characterize(generic);
----------------
klausler wrote:
> When `generic` is not `GenericDetails`, what is it?
Well, the `generic` was written not by me. If I understand correctly, `generic` is a `Symbol` that meant to have the `GenericDetails`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123927



More information about the flang-commits mailing list