[Bug fortran/96158] Debug symbols not emitted for module common variables

tkoenig at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Jul 13 17:03:53 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to AJM from comment #8)

> 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,

That is correct, there is a _much_ better way to do it: C interoperability.
That is standard, and gfortran will even generate your C prototypes
for you :-)

For example:

$ cat a.f90
module foo
  use iso_c_binding
  type, bind(c) :: bar
     character(c_char) :: x(4)
     integer(kind=c_int) :: y
  end type bar
  type (bar), bind(C) :: myvar
end module foo

$ gfortran -fc-prototypes -c a.f90
#include <stddef.h>
#ifdef __cplusplus
#include <complex>
#define __GFORTRAN_FLOAT_COMPLEX std::complex<float>
#define __GFORTRAN_DOUBLE_COMPLEX std::complex<double>
#define __GFORTRAN_LONG_DOUBLE_COMPLEX std::complex<long double>
extern "C" {
#else
#define __GFORTRAN_FLOAT_COMPLEX float _Complex
#define __GFORTRAN_DOUBLE_COMPLEX double _Complex
#define __GFORTRAN_LONG_DOUBLE_COMPLEX long double _Complex
#endif

typedef struct bar {
    char x[4];
    int y;
} bar;
extern bar myvar;

#ifdef __cplusplus
}
#endif



> 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").

All of that is not an issue with C interoperability, because these
things just work - the Fortran processor (in this case gfortran)
and its companion C processor (gcc) have the same conventions regarding
layout of variables etc.

> 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).

Maybe, if you show the code above to whoever's in charge, that might
cause that person to reconsider :-)


More information about the Gcc-bugs mailing list