[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