Internal Compiler Error on FunctionReference node on fir-dev branch

Hello!

I’ve been trying to compile a project using flang on fir-dev branch yet I got weird internal compiler error for this chunk of code (it is a minimal reproducible example):

SUBROUTINE FOO_2()
      IMPLICIT NONE
      A(0)%B(Y)=0
END SUBROUTINE

The compiler output:

$ build/bin/flang-new bar.f90 
fatal internal error: node has not been analyzed:
Expr -> LiteralConstant -> IntLiteralConstant = '0'

PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /home/d.dudkin/dev/llvm-project/build/bin/flang-new -fc1 -triple x86_64-unknown-linux-gnu -emit-obj -o /tmp/bar-fd0182.o bar.f90
...

But for this program, the compiler exits fine:

SUBROUTINE FOO_3()
      IMPLICIT NONE
      A(X)%B(0)=0
END SUBROUTINE
error: Semantic errors in bar.f90
./bar.f90:3:7: error: No explicit type declared for 'a'
        A(X)%B(0)=0
        ^
./bar.f90:3:9: error: No explicit type declared for 'x'
        A(X)%B(0)=0
          ^

The command to reproduce is simple: flang-new <file>. I checked it on commit [NFC] Move genMaxWithZero into fir:::factory (#1585) · flang-compiler/f18-llvm-project@46bb541 · GitHub.

I have an idea on how to fix a “false-positive” internal error: we can ignore the error if for the node or for any of its parent nodes there’ a fatal semantic error. But:

  1. I do not know how to implement it, since the error is printed here: f18-llvm-project/tools.cpp at fir-dev · flang-compiler/f18-llvm-project · GitHub, and I don’t see how we can get access to SemanticContext object to check on errors.
  2. I think there can be another approach to fix it in more delicate approach.

Also, I tried just to return a nullptr here: f18-llvm-project/tools.cpp at fir-dev · flang-compiler/f18-llvm-project · GitHub if x.typedExpr is missing, and it worked ok, and all the tests for flang passed.

I’d love to fix it myself and contribute it back, so I appreciate any tips!
Thank you.

I’ve got a fix for this one that’s working its way to LLVM.

Could you please share the link to Phabricator?

There isn’t one yet; it’s a change that would cause painful cherry-picking back to fir-dev if pushed into llvm while code remains to be “upstreamed”.