[Bug fortran/95146] New: gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[Bug fortran/95146] New: gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146

            Bug ID: 95146
           Summary: gfortran -cpp – leading spaces before '#'
                    preprocessing directive not handled
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Found when looking at the build results for
  meson (Python-based build system)
which fail like:

[  384s] Command line:  gfortran /home/abuild/rpmbuild/BUILD/meson-0.54.1/b
536484cc32/meson-private/tmpp6hst_hh/testfile.f90 -pipe -cpp -E -P
-D_FILE_OFFSET_BITS=64 -cpp -P -O0 
[  384s] 
[  384s] Code:
[  385s]  
[  385s]         #ifdef __has_include
[  385s]          #if !__has_include("omp.h")
[  385s]           #error "Header 'omp.h' could not be found"
[  385s]          #endif
[  385s]         #else
[  385s]          #include <omp.h>
[  385s]         #endif
...
[  385s] Error: "__has_include" used outside of preprocessing directive

The problem is that the leading spaces before the '#' are not properly handled.

Simpler example ' #define A 5'. Without space, "gfortran -E" removes that line,
with space, the line remains after preprocessing.

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
This seems to be a side effect of using
  -traditional
in gfortran see PR 28662 for moving to no traditional.

Also gcc -E -traditional shows this behavior of just echoing the strings.

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Pre ANSI/ISO C (aka K&R C), preprocessor were true preprocessor and always
required # in the first column.

I think meson should be fixed really to work rather than working around the
issue in gfortran.

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Pre ANSI/ISO C (aka K&R C), preprocessor were true preprocessor and always
> required # in the first column.
> 
> I think meson should be fixed really to work rather than working around the
> issue in gfortran.

Actually it was already fixed:
https://github.com/mesonbuild/meson/issues/7017

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Pre ANSI/ISO C (aka K&R C), preprocessor were true preprocessor and always
> required # in the first column.
> 
> I think meson should be fixed really to work rather than working around the
> issue in gfortran.

Well, gfortran should finally move to non-traditional, but that's not that
trivial as PR 28662 shows.

→ Close as INVALID as the current behavior is fine with -traditional and the
other is already covered.

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Moving to the non-traditional C preprocessor will cause havoc with
the // operator in Fortran.

c = 'a' // 'b' would then be turned into c = 'a', probably not intended :-)

[Bug fortran/95146] gfortran -cpp – leading spaces before '#' preprocessing directive not handled

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Thomas Koenig from comment #5)
> Moving to the non-traditional C preprocessor will cause havoc with
> the // operator in Fortran.
> c = 'a' // 'b' would then be turned into c = 'a', probably not intended :-)

That's one of the reasons that PR 28662 is still pending; it requires a special
Fortran mode for libcpp. — See PR 28662 comment 4 to 10. – Still useful, but
not trivial.