https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
--- Comment #8 from AJM <amelvill at umich dot edu> ---
> > >> I won't comment on the questionable programming idiom of placing
> > >> a common block in a module, which kind of defeats the niceties of
> > >> a module.
> > > If somebody wants to transition your code from using common blocks to
> > > modules, that is a good way to proceed. When all the direct usage
> > > of the common block have been removed, you can then remove the
> > > COMMON statement from the module.
> >
> > This is the case, more or less. I didn't write the code that did this.
> >
> > I would be quite happy to see the common blocks get moved to a module,
> > but to make things a bit more dangerous on that side, these variables
> > are bound to a C variable.
> Do you mean the variable is declared with BIND(C)?
> If so, you should be getting an error.
The bind statement would look like this, directly under the "common" statement,
inside somemodule.f90:
module somemodule
integer*8 moduleVar !then many more variables
common /othermodule/ moduleVar !then many more variables
bind(C, name="othermodule") :: /othermodule/
end module
The program, with the bind statement added, compiles without errors.
If you really need to know, on the C side there is a struct with fields that
match the order and size of the variables in the common statement / module
declaration. I am almost certain that this is not the "right way" to do this,
and that there is some UB there in struct packing and compiler decisions on the
size of the variables (neither the C side nor the fortran side has packing
pragmas, and worse, the C side uses compiler defined integer types like "int").
Without a doubt this is not an ideal setup, a rewrite is probably in order to
ensure portability. We don't have the time resources for that rewrite right
now, though (and that's not my call, either).
While I was making a minimal example I originally thought bind was the root
cause, but I eliminated it as the source of the problem (I found that I could
reproduce the issue with only common). I removed it to try and make the most
minimal example possible.
This C side explanation is, in my opinion, not relevant at all to the bug at
hand and is our team's responsibility, not gfortran's. It's just to give you
context as to what I'm working with here and why "just make a module" is not
really an option, I would consider the C interfacing very precarious and I
personally only have the expertise to make it portable from the C side, not the
Fortran side (though I'm trying to get up to speed on the latter).
Though, if anyone has any suggestions for documentation I can read about how to
avoid problems between g++ and gfortan that might come about from moving this
to a module I would appreciate it. I'm hoping that eventually I can come up
with a path towards making this a module that would exactly replicate the
original's intended behavior in a standards compliant way without breaking
anything. That path is not clear, at the moment.
> A quick scan of the DWARF5 standard does not show
> a DW_TAG that applies to a variable declared in
> a module.
Referring to the github repo quickly
https://github.com/amelvill-umich/Fortran_GDB_Common#with-that-line-commented-out
, with the common statement commented out,
$ nm somemodule.o
0000000000000000 B __somemodule_MOD_modulevar
$ gdb main
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
(...)
Reading symbols from main...
(gdb) b 9
Breakpoint 1 at 0x1238: file main.f90, line 9.
(gdb) r
Starting program: /home/me/a_dev/fortran_gdb_common/main
moduleVar=123
Breakpoint 1, myprogram () at main.f90:9
9 end program
(gdb) call moduleVar
$1 = 123
It seems like gfortran emits symbols of the form __<modulename>_MOD_<varname>
if the common statement is omitted, could the compiler emit something like this
for common statements? Like __<common>_MOD_<varname>?
In my test program's case, could it emit __othermodule_MOD_moduleVar? Would
there be issues with name collisions if there actually was a module named
othermodule (in addition to common)?
To be fair, I have not read the DWARF spec in depth, and "this is undefined
behavior" is a fair answer.
