https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62226
--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Tobias Burnus from comment #1) > I am not sure whether the original issue still exists. > > Fortran now uses a lot of the common machinery and also seems to handle > CPP() well. > > Thus, is this now fixed/superseded by the recent and not so recent > developments or is something still needed? If Fortran will always use a subset of the CPP options used by the C FE and defined by c-family/c.opt, then I guess it may not be needed. But be aware that this code: https://github.com/gcc-mirror/gcc/blob/8bafc9640f353ff11c0535a03096fb4db9a5bb95/gcc/fortran/cpp.c#L1062 only works because this file: https://github.com/gcc-mirror/gcc/blob/master/gcc/c-family/c.opt#L390 encodes the CppReason and it is not possible without the patch in this PR to have a CPP option that only works for Fortran only encoded in fortran/lang.opt I haven't tested whether diagnostics from CPP show the appropriate option in Fortran and behave correctly with #pragma GCC diagnostics. Another minor thing: You added recently another copy of: https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/gcc/c-family/c-common.c#L6293 I may have added that function there, but it should be added in common code. In fact, it could be actually generated as "static inline" together with the table of codes: https://github.com/gcc-mirror/gcc/blob/master/gcc/opth-gen.awk so that it is available by including opts.h (in fact, that function is the only user of cpp_reason_option_codes, so the table could be inside the function rather than being yet another global).
