https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62226
--- Comment #2 from Manuel López-Ibáñez ---
(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).
