https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
--- Comment #16 from Dan Bonachea <dobonachea at lbl dot gov> --- Gfortran's use of a traditional preprocessor remains a major impediment to portability for Fortran codes that include non-trivial use of the (previously unspecified) Fortran preprocessor. In honor of this bug's recent 20th birthday, I'm linking the (two-part) Fortran preprocessor Specifications, which were passed last year by INCITS/Fortran (aka J3, the US standards body that develops the ISO/IEC Fortran standard): * Gary Klimowicz, Dan Bonachea, Patrick Fasano, Steve Lionel, "Formal specifications for the Fortran preprocessor (FPP)", INCITS/US Fortran Programming Language Standards Technical Committee (J3/25-142r2), June 2025. https://j3-fortran.org/doc/year/25/25-142r2.txt * Patrick Fasano, Dan Bonachea. "Formal specifications for macro identification and expansion in the Fortran preprocessor (FPP)", INCITS/US Fortran Programming Language Standards Technical Committee (J3/25-176r3), November 2025. https://j3-fortran.org/doc/year/25/25-176r3.txt These documents specify, in detail, the consensus of the Fortran standard committee regarding how a C-like Fortran preprocessor should behave. GFortran's traditional preprocessor behavior is currently very far from this consensus, whereas other competing open source Fortran compilers (LLVM Flang) are much closer.
