[flang-commits] [flang] [flang] Fix spurious error with separate module procedures (PR #106768)

[Rainer Orth via flang-commits]

rorth wrote:

I've now finally done a `Debug` build.  Here's what I found:

The `SEGV` happens here:
```
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00007ffffefd652c in memcmp () from /lib/64/libc.so.1
1: x/i $pc
=> 0x7ffffefd652c <memcmp+164>:	ldub  [ %o0 + %o1 ], %o5
(gdb) p/x $o0
$9 = 0x142917167
(gdb) p/x $o1
$10 = 0xfffffffebd6e8efa
(gdb) p/x $o0+$o1
$11 = 0x61
```
In the caller I see
```
#1  0x000000012cab7458 in Fortran::parser::CharBlock::Compare (
    this=0x1428cfd90, that=...)
    at /vol/llvm/src/llvm-project/local/flang/include/flang/Parser/char-block.h:141
141	      int cmp{std::memcmp(static_cast<const void *>(begin()),

(gdb) p begin()
$12 = 0x142917167 "m\nreal :: qux(10)\ninterface\nmodule subroutine bar(i)\nend\nmodule function baz()\nend\nend interface\nend\nsubmodule(m) sm\ncontains\nmodule procedure bar\nqux(i) = baz()\nend\nmodule procedure baz\nbaz = 1.\nend\n"...
(gdb) p that.begin()
$13 = 0x61 <error: Cannot access memory at address 0x61>
(gdb) p bytes
$14 = 1
```
ISTM that instead of passing the address of the second string to `memcmp`, the first element (0x61 == 'a') is passed instead.  I suspect this happens further up in the callers
```
#16 0x000000012e321a74 in Fortran::evaluate::ExpressionAnalyzer::ResolveForward
    (this=0xffffffff7fff54d8, symbol=...)
    at /vol/llvm/src/llvm-project/local/flang/lib/Semantics/expression.cpp:2677
2677	      semantics::ResolveSpecificationParts(context_, symbol);
```
I suspect this is here in your patch:
```
@@ -2661,8 +2661,13 @@ bool ExpressionAnalyzer::ResolveForward(const Symbol &symbol) {
       // checking a specification expression in a sibling module
       // procedure.  Resolve its names now so that its interface
       // is known.
+      const semantics::Scope &scope{symbol.owner()};
       semantics::ResolveSpecificationParts(context_, symbol);
-      if (symbol.has<semantics::SubprogramNameDetails>()) {
+      const Symbol *resolved{nullptr};
+      if (auto iter{scope.find(symbol.name())}; iter != scope.cend()) {
+        resolved = &*iter->second;
+      }
+      if (!resolved || resolved->has<semantics::SubprogramNameDetails>()) {
         // When the symbol hasn't had its details updated, we must have
         // already been in the process of resolving the function's
         // specification part; but recursive function calls are not
```

https://github.com/llvm/llvm-project/pull/106768