Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies
On 7/19/23 20:47, Ben Boeckel wrote: On Wed, Jul 19, 2023 at 17:11:08 -0400, Nathan Sidwell wrote: GCC is neither of these descriptions. a CMI does not contain the transitive closure of its imports. It contains an import table. That table lists the transitive closure of its imports (it needs that closure to do remapping), and that table contains the CMI pathnames of the direct imports. Those pathnames are absolute, if the mapper provded an absolute pathm or relative to the CMI repo. The rationale here is that if you're building a CMI, Foo, which imports a bunch of modules, those imported CMIs will have the same (relative) location in this compilation and in compilations importing Foo (why would you move them?) Note this is NOT inhibiting relocatable builds, because of the CMI repo. But it is inhibiting distributed builds because the distributing tool would need to know: - what CMIs are actually imported (here, "read the module mapper file" (in CMake's case, this is only the modules that are needed; a single massive mapper file for an entire project would have extra entries) or "act as a proxy for the socket/program specified" for other approaches); This information is in the machine (& human) README section of the CMI. - read the CMIs as it sends to the remote side to gather any other CMIs that may be needed (recursively); Contrast this with the MSVC and Clang (17+) mechanism where the command line contains everything that is needed and a single bolus can be sent. um, the build system needs to create that command line? Where does the build system get that information? IIUC it'll need to read some file(s) to do that. And relocatable is probably fine. How does it interact with reproducible builds? Or are GCC CMIs not really something anyone should consider for installation (even as a "here, maybe this can help consumers" mechanism)? Module CMIs should be considered a cacheable artifact. They are neither object files nor source files. On 7/18/23 20:01, Ben Boeckel wrote: Maybe I'm missing how this *actually* works in GCC as I've really only interacted with it through the command line, but I've not needed to mention `a.cmi` when compiling `use.cppm`. Is `a.cmi` referenced and read through some embedded information in `b.cmi` or does `b.cmi` include enough information to not need to read it at all? If the former, distributed builds are going to have a problem knowing what files to send just from the command line (I'll call this "implicit thin"). If the latter, that is the "fat" CMI that I'm thinking of. please don't use perjorative terms like 'fat' and 'thin'. Sorry, I was internally analogizing to "thinLTO". --Ben -- Nathan Sidwell
[PATCH] libfortran: Fix build for targets that don't have 10byte or 16 byte floating point
So the problem here is EXPAND_INTER_MACRO_16 expands to nothing if 16 byte FP does not exist but we still add a comma after it and that causes a build failure. The same is true for EXPAND_INTER_MACRO_10 too. Committed as obvious after a bootstrap and test on x86_64-linux-gnu and aarch64-linux-gnu. libgfortran/ChangeLog: PR libfortran/110759 * ieee/ieee_arithmetic.F90 (COMP_INTERFACE): Remove the comma after EXPAND_INTER_MACRO_16 and EXPAND_INTER_MACRO_10. (EXPAND_INTER_MACRO_16): Add comma here if 16 byte fp exist. (EXPAND_INTER_MACRO_10): Likewise. --- libgfortran/ieee/ieee_arithmetic.F90 | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libgfortran/ieee/ieee_arithmetic.F90 b/libgfortran/ieee/ieee_arithmetic.F90 index aa897abae39..debe40449f4 100644 --- a/libgfortran/ieee/ieee_arithmetic.F90 +++ b/libgfortran/ieee/ieee_arithmetic.F90 @@ -535,13 +535,13 @@ UNORDERED_MACRO(4,4) end interface #ifdef HAVE_GFC_REAL_16 -# define EXPAND_INTER_MACRO_16(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_16 +# define EXPAND_INTER_MACRO_16(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_16 , #else # define EXPAND_INTER_MACRO_16(TYPE,OP) #endif #ifdef HAVE_GFC_REAL_10 -# define EXPAND_INTER_MACRO_10(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_10 +# define EXPAND_INTER_MACRO_10(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_10 , #else # define EXPAND_INTER_MACRO_10(TYPE,OP) #endif @@ -549,8 +549,8 @@ UNORDERED_MACRO(4,4) #define COMP_INTERFACE(TYPE,OP) \ interface IEEE_/**/TYPE/**/_/**/OP ; \ procedure \ - EXPAND_INTER_MACRO_16(TYPE,OP) , \ - EXPAND_INTER_MACRO_10(TYPE,OP) , \ + EXPAND_INTER_MACRO_16(TYPE,OP) \ + EXPAND_INTER_MACRO_10(TYPE,OP) \ _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_8 , \ _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_4 ; \ end interface ; \ -- 2.31.1
