https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118337
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Thomas Koenig from comment #7) > (In reply to anlauf from comment #6) > > > It is clear that one cannot have 2-way compatibility. > > > > But I wish we could have a limited version of backward-compatibility, > > i.e. trying to consume older module versions with newer compilers. > > Commercial compilers at least try. We might do that for our users, too. > > > > It is a PITA to have to recompile a full software stack only because > > there is a simple addition to the module format. > > This is doable, if a bit of work. We would need to put a version number > on our intrinsic module entities and write this out. On reading, > anything with a higher number than what the current compiler supports > will then be discarded. If we do that, and take care not to disturb > the previous numbers when adding something new, that could work. > A bit like the symbol versioning in the shared libraries... > > We need to bump the module version anyway. Is this something > we could still fit in (with the required testing) before release? Given Fortran is not a primary language it's your call. That said, if we re-order the intrinsic module .def file changes GCC 15, with changed module version to 16, could be made to accept version 15 module files as well, right? And GCC 14 would reject the version 16 modules correctly. Future-proofing in a less explicit way would of course be nice.
