[flang] crash with "cannot process subprogram that was already processed"

[k-arrows]

It looks like flang-new's behavior for the following test program has changed recently:
https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/gfortran.dg/binding_label_tests_21.f90

Here is the result of comparing the older flang-new with the one I built today. I'm reporting as I think it's worse to crash, but please let me know if it's not right.

LLVM-16.0.3 (OK : reporting semantic errors)

$ flang-new -c binding_label_tests_21.f90
error: Semantic errors in binding_label_tests_21.f90
./binding_label_tests_21.f90:6:7: error: Two entities have the same BIND(C) name 'bar'
  entry sub() bind(C, name="bar") ! { dg-error "Global binding name 'bar' at .1. is already being used as a SUBROUTINE at .2." }
        ^^^
./binding_label_tests_21.f90:5:12: Conflicting declaration
  subroutine foo() bind(C, name="bar") ! { dg-error "Global binding name 'bar' at .1. is already being used as a SUBROUTINE at .2." }
             ^^^
$ flang-new --version
flang-new version 16.0.3 (https://github.com/llvm/llvm-project da3cd333bea572fb10470f610a27f22bcb84b08c)
Target: x86_64-unknown-linux-gnu
Thread model: posix

LLVM-17.0.0 (NG : crash with "cannot process subprogram that was already processed")
Stack dump:

 #0 0x0000563013928282 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
 #1 0x00005630139288c4 SignalHandler(int) Signals.cpp:0:0
 #2 0x00007fcdbb423520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #3 0x00007fcdbb477a7c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #4 0x00007fcdbb477a7c __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 #5 0x00007fcdbb477a7c pthread_kill ./nptl/pthread_kill.c:89:10
 #6 0x00007fcdbb423476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #7 0x00007fcdbb4097f3 abort ./stdlib/abort.c:81:7
 #8 0x00005630138d5fa1 llvm::report_fatal_error(llvm::Twine const&, bool)
 #9 0x00005630138d5e4f llvm::report_fatal_error(llvm::Twine const&, bool)
#10 0x0000563013afd36a mlir::InFlightDiagnostic::~InFlightDiagnostic()
#11 0x0000563013b48c61
#12 0x0000563013b4409f (anonymous namespace)::FirConverter::startNewFunction(Fortran::lower::pft::FunctionLikeUnit&) Bridge.cpp:0:0
#13 0x0000563013b439c8 (anonymous namespace)::FirConverter::lowerFunc(Fortran::lower::pft::FunctionLikeUnit&) Bridge.cpp:0:0
#14 0x0000563013af9de5 Fortran::lower::LoweringBridge::lower(Fortran::parser::Program const&, Fortran::semantics::SemanticsContext const&) 
#15 0x0000563013a66ec3 Fortran::frontend::CodeGenAction::beginSourceFileAction() 
#16 0x000056301394822b Fortran::frontend::FrontendAction::beginSourceFile(Fortran::frontend::CompilerInstance&, Fortran::frontend::FrontendInputFile const&)
#17 0x0000563013940c80 Fortran::frontend::CompilerInstance::executeAction(Fortran::frontend::FrontendAction&)
#18 0x000056301394ad56 Fortran::frontend::executeCompilerInvocation(Fortran::frontend::CompilerInstance*)
#19 0x00005630129e0efd fc1_main(llvm::ArrayRef<char const*>, char const*)
#20 0x00005630129df0d0 main 
#21 0x00007fcdbb40ad90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#22 0x00007fcdbb40ae40 call_init ./csu/../csu/libc-start.c:128:20
#23 0x00007fcdbb40ae40 __libc_start_main ./csu/../csu/libc-start.c:379:5
#24 0x00005630129de655 _start 
flang-new: error: unable to execute command: Aborted
flang-new: error: flang frontend command failed due to signal (use -v to see invocation)
flang-new version 17.0.0 (https://github.com/llvm/llvm-project.git e335e8a43287b8258c719d7a21c4264b0550c554)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[llvmbot]

@llvm/issue-subscribers-flang-ir

[llvmbot]

@llvm/issue-subscribers-bug

[DavidSpickett]

Still present as of 46fe36a.

error: loc("/app/example.f90":5:1): cannot process subprogram that was already processed
LLVM ERROR: aborting
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/clang-llvmflang-trunk-20240830/bin/flang-new -fc1 -triple aarch64-unknown-linux-gnu -S -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -resource-dir /opt/compiler-explorer/clang-llvmflang-trunk-20240830/lib/clang/20 -mframe-pointer=non-leaf -o /app/output.s -x f95-cpp-input /app/example.f90
 #0 0x00000000035093f8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-llvmflang-trunk-20240830/bin/flang-new+0x35093f8)
 #1 0x0000000003506d9c SignalHandler(int) Signals.cpp:0:0
 #2 0x000071b1ba642520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #3 0x000071b1ba6969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
 #4 0x000071b1ba642476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
 #5 0x000071b1ba6287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
<...>

[eugeneepshteyn]

This is specifically when primary procedure and its alternate entry have the same bind_c name. Need to add a check for this case in CheckHelper::CheckGlobalName()