COMMON blocks are a feature of Fortran that has no direct analog in C languages, but they are similar to data sections in assembly language programming. A COMMON block is a named area of memory that holds a collection of variables. Fortran subprograms may map the COMMON block memory area to their own, possibly distinct, non-empty list of variables. A Fortran COMMON block might look like the following example.

COMMON /ALPHA/ I, J

For this construct, the compiler generates a new scope-like DI construct (!DICommonBlock) into which variables (see I, J above) can be placed. As the common block implies a range of storage with global lifetime, the !DICommonBlock refers to a !DIGlobalVariable. The Fortran variable that comprise the COMMON block are also linked via metadata to offsets within the global variable that stands for the entire common block.

It's not strictly required to have it explicitly named. Our implementation allocates a COMMON block as an "untyped" block of memory and each subprogram can, of course, remap the storage units to its own list of variable names. The DW_TAG_common_block does require a DW_AT_location, and the !DIGlobalVariable fulfills that requirement.

It's not strictly required to have it explicitly named. Our implementation allocates a COMMON block as an "untyped" block of memory and each subprogram can, of course, remap the storage units to its own list of variable names. The DW_TAG_common_block does require a DW_AT_location, and the !DIGlobalVariable fulfills that requirement.

Ah, yes I see. I forgot that for us, we have a platform-specific ELF section flag for "overlay" sections which are common blocks. We don't need the extra hidden weak variable to be the intermediate allocator.

You can simulate the relevant effect of LTO by producing two .ll files and running llvm-link on them. Alternatively you can also run llvm-lto/llvm-lto2 on them for a more complete simulation.

We admit that we're not entirely sure what we're looking for exactly, and we are not familiar with llvm-lto. However, we conducted an experiment using llvm-lto as follows.

We wrote a Fortran program using separate source files. 2 of these files contained subroutines that have COMMON /foo/ specifications. These COMMON blocks define a series of variables under different names. (For example, variable a1 and a2 map to the same memory location in the same /foo/ COMMON block but each is from a different SUBROUTINE scopes.)

We ran llvm-lto on the resulting .bc files with -O3 and -O0.

Debugging the resulting program, we see that the variables in one subroutine are present and can be queried. The variables in the second subroutine are present but have no location information. We see the same behavior regardless of the optimization level.

This is a different result than we obtain when we do not manually intervene with LTO. When compiling with our Fortran compiler and no LTO, we can set breakpoints in both of the aforementioned routines and all the expected COMMON variables are present, can be queried as to value, and have location information in the DWARF.

We are not clear if this is a problem versus working as intended, and if it is the former what, if anything, we ought to do about it.

Regarding your LTO-like experiments, that result is more or less what I thought would happen. In a normal compilation, each CU gets its own description of the types, and the fact that they are different in different CUs doesn't matter. Within each CU's context, the common-block description is complete and will be used correctly by the debugger.
In LTO, however, the IR linker wants to de-duplicate debug information, to avoid multiple copies of the same type in the final object file. I suspect that de-duplication (which IIRC is founded on the C++ "one definition rule") probably should not apply to Fortran, or at least not to common blocks.
This is not something you need to solve today, but I think after this lands, you should file a bug to the effect that LTO with Fortran can produce incorrect debug information, specifically for common blocks. That will at least keep track of this factoid somewhere that we can find it again.

So: One test comment, you'll need to file that bug, and I am embarrassed to say I haven't looked at the code part of the patch. But if @dblaikie or @aprantl are happy that's good enough for me.