https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Sharing enumerators/defines between the FE and the library is fine. And can be done either way, e.g. the Fortran FE has trigd_fe.inc:#include "../../libgfortran/intrinsics/trigd.inc" and libgfortran.h:#include "../gcc/fortran/libgfortran.h" Sharing data structures is harder, because the FE should not use data structures from the library as is, it should simply create RECORD_TYPE with the corresponding fields (or UNION_TYPE, ...). You could have some header with the field offsets, use those offsets when building the structures and in the library just assert using offsetof that it is ABI compatible. Sharing code between the library and the FE is undesirable. E.g. it is fine (though not ideal) that the library uses __int128 and _Float128), but the FE should not use those, it should use wide_int.*/real.* emulations or trees on top of that or gmp/mpfr for constant evaluation and parsing, not the types that don't exist on many hosts. The FE should be as a cross-compiler usable on any sane host (typically we want at least ilp32 or lp64 or llp64 target, the various DSPs with 16-bit ints etc. aren't usable hosts). So it needs to run on any host OS, any host endianity and any any host CPU.
