preprocessor token "#" doesn't work in gfortran as in gcc, intel-fortran or sun-fortran compiler

Hello,
Consider this code
{{{
#include
#define TO_STR(EXPR) # EXPR
int main() {
printf("%s\n", TO_STR(bazz));
return 0;
}
}}}
Running
gcc foo.c && ./a.out
gives
bazz
The fortran version is
{{{
#define TO_STR(EXPR) #EXPR
PROGRAM test
print *,TO_STR(bazz)
END PROGRAM test
}}}
Running
ifort -fpp foo.f90 && ./a.out
or
sunf95 -fpp foo.f90 && ./a.out
gives
bazz
as expected.
But
gfortran -cpp foo.f90
chokes with
{{{
foo.f90:4.10:
print *,#bazz
1
Error: Expected expression in PRINT statement at (1)
}}}
After some tinkering I came up with
{{{
#define TO_STR(EXPR) "EXPR"
PROGRAM test
print *,TO_STR(bazz)
END PROGRAM test
}}}
Running
gfortran -cpp foo.f90 && ./a.out
gives
bazz
Why does gfortran -cpp" behave different than gcc or any other fortran compiler
I have around? Is this by intention or just a bug?

Hi,
Maik Beckmann wrote:
> Why does gfortran -cpp" behave different than gcc or any other fortran compiler
> I have around? Is this by intention or just a bug?
gfortran's preprocessor uses traditional C preprocessing rules, which
differ from what was standardized in C90 in regards to token pasting and
stringification. There may be a command line option to change this
behavior (I don't know), and it may make sense to revise that decision
if all other compilers behave differently.
Cheers,
- Tobi

Tobias Schlüter wrote:
> Maik Beckmann wrote:
>> Why does gfortran -cpp" behave different than gcc or any other fortran
>> compiler I have around? Is this by intention or just a bug?
>
> gfortran's preprocessor uses traditional C preprocessing rules, which
> differ from what was standardized in C90 in regards to token pasting and
> stringification. There may be a command line option to change this
> behavior (I don't know), and it may make sense to revise that decision
> if all other compilers behave differently.
>
> Cheers,
> - Tobi
As far as I know, gfortran, and later versions of g77, invoke tradcpp, the
same as 'gcc -traditional' does. tradcpp doesn't support C99 or C++, and
doesn't break Fortran string concatenation. In order to support
installations where the default gnu Fortran version is likely to be broken
(or the name of it varies), some of my customers use the 'gcc -traditional
-x c' command to pre-process .F
The gcc maintainers decided to support the distinctions by providing the
separate tradcpp.

Tim Prince schrieb am Mittwoch 10 Juni 2009 um 18:42:
> As far as I know, gfortran, and later versions of g77, invoke tradcpp, the
> same as 'gcc -traditional' does. tradcpp doesn't support C99 or C++, and
> doesn't break Fortran string concatenation. In order to support
> installations where the default gnu Fortran version is likely to be broken
> (or the name of it varies), some of my customers use the 'gcc -traditional
> -x c' command to pre-process .F
> The gcc maintainers decided to support the distinctions by providing the
> separate tradcpp.
Is there a command line switch to force gfortran to use the current gcc cpp?
Thanks,
-- Maik

On Wed, Jun 10, 2009 at 06:58:02PM +0200, Maik Beckmann wrote:
> Tim Prince schrieb am Mittwoch 10 Juni 2009 um 18:42:
> > As far as I know, gfortran, and later versions of g77, invoke tradcpp, the
> > same as 'gcc -traditional' does. tradcpp doesn't support C99 or C++, and
> > doesn't break Fortran string concatenation. In order to support
> > installations where the default gnu Fortran version is likely to be broken
> > (or the name of it varies), some of my customers use the 'gcc -traditional
> > -x c' command to pre-process .F
> > The gcc maintainers decided to support the distinctions by providing the
> > separate tradcpp.
>
> Is there a command line switch to force gfortran to use the current gcc cpp?
>
No. See cpp.c.
--
Steve

Steve Kargl wrote:
> On Wed, Jun 10, 2009 at 06:58:02PM +0200, Maik Beckmann wrote:
>> Tim Prince schrieb am Mittwoch 10 Juni 2009 um 18:42:
>>> As far as I know, gfortran, and later versions of g77, invoke tradcpp, the
>>> same as 'gcc -traditional' does. tradcpp doesn't support C99 or C++, and
>>> doesn't break Fortran string concatenation. In order to support
>>> installations where the default gnu Fortran version is likely to be broken
>>> (or the name of it varies), some of my customers use the 'gcc -traditional
>>> -x c' command to pre-process .F
>>> The gcc maintainers decided to support the distinctions by providing the
>>> separate tradcpp.
>> Is there a command line switch to force gfortran to use the current gcc cpp?
>>
>
> No. See cpp.c.
One could do the preprocessing and compilation in two steps, i.e.
gcc -E source.F -o source.f
gfortran source.f
should do what you want.
Cheers,
- Tobi

Tobias Schl=FCter wrote:
> Steve Kargl wrote:
>> On Wed, Jun 10, 2009 at 06:58:02PM +0200, Maik Beckmann wrote:
>>> Tim Prince schrieb am Mittwoch 10 Juni 2009 um 18:42:
>>>> As far as I know, gfortran, and later versions of g77, invoke=20
>>>> tradcpp, the
>>>> same as 'gcc -traditional' does. tradcpp doesn't support C99 or=20
>>>> C++, and
>>>> doesn't break Fortran string concatenation. In order to support
>>>> installations where the default gnu Fortran version is likely to be=20
>>>> broken
>>>> (or the name of it varies), some of my customers use the 'gcc=20
>>>> -traditional
>>>> -x c' command to pre-process .F
>>>> The gcc maintainers decided to support the distinctions by providing=
=20
>>>> the
>>>> separate tradcpp.
>>> Is there a command line switch to force gfortran to use the current=20
>>> gcc cpp?
>>>
>>
>> No. See cpp.c.
>=20
> One could do the preprocessing and compilation in two steps, i.e.
> gcc -E source.F -o source.f
^^^^^^^^^^^^^^^^^^^^^^^^^^^
you may need '-x c' on that command line
> gfortran source.f
> should do what you want.
>=20
> Cheers,
> - Tobi

Maik Beckmann wrote:
> Tim Prince schrieb am Mittwoch 10 Juni 2009 um 18:42:
>> As far as I know, gfortran, and later versions of g77, invoke tradcpp, the
>> same as 'gcc -traditional' does. tradcpp doesn't support C99 or C++, and
>> doesn't break Fortran string concatenation. In order to support
>> installations where the default gnu Fortran version is likely to be broken
>> (or the name of it varies), some of my customers use the 'gcc -traditional
>> -x c' command to pre-process .F
>> The gcc maintainers decided to support the distinctions by providing the
>> separate tradcpp.
>
> Is there a command line switch to force gfortran to use the current gcc cpp?
>
I haven't heard of any such thing. Why would anyone support it? You
could simply use the gcc pre-processing without -traditional, if you don't
care about breaking Fortran string concatenation.

Tim Prince schrieb am Mittwoch 10 Juni 2009 um 19:57:
> Maik Beckmann wrote:
> >
> > Is there a command line switch to force gfortran to use the current gcc
> > cpp?
>
> I haven't heard of any such thing. Why would anyone support it? You
> could simply use the gcc pre-processing without -traditional, if you don't
> care about breaking Fortran string concatenation.
If all compilers would behave behave the same way it wouldn't an issue. But
having to maintain something just for gfortran is just inconvenient.
ifort and sunf95 both take
-fpp
to preprocess a source file while gfortran wants
-cpp
ifort and sunf95 both use the standard cpp
#define TO_STR(EXPR) #EXPR
while gfortran wants
#define TO_STR(EXPR) "EXPR"
No show stoppers at all, but inconvenient.
Thanks,
--Maik

On Wed, Jun 10, 2009 at 10:29:16PM +0200, Maik Beckmann wrote:
> Tim Prince schrieb am Mittwoch 10 Juni 2009 um 19:57:
> > Maik Beckmann wrote:
> > >
> > > Is there a command line switch to force gfortran to use the current gcc
> > > cpp?
> >
> > I haven't heard of any such thing. Why would anyone support it? You
> > could simply use the gcc pre-processing without -traditional, if you don't
> > care about breaking Fortran string concatenation.
>
> If all compilers would behave behave the same way it wouldn't an issue. But
> having to maintain something just for gfortran is just inconvenient.
>
> ifort and sunf95 both take
> -fpp
> to preprocess a source file while gfortran wants
> -cpp
> ifort and sunf95 both use the standard cpp
> #define TO_STR(EXPR) #EXPR
> while gfortran wants
> #define TO_STR(EXPR) "EXPR"
>
> No show stoppers at all, but inconvenient.
>
Have you asked Intel and Sun to support the gfortran
syntax and feature?
--
Steve

Steve Kargl wrote:
> On Wed, Jun 10, 2009 at 10:29:16PM +0200, Maik Beckmann wrote:
...
>>
>> ifort and sunf95 both take
>> -fpp
>> to preprocess a source file while gfortran wants
>> -cpp
.....
>> No show stoppers at all, but inconvenient.
>>
>
> Have you asked Intel and Sun to support the gfortran
> syntax and feature?
>
From ifort -help:
-E preprocess to stdout
-EP preprocess to stdout, omitting #line directives
-P preprocess to file, omitting #line directives
-preprocess-only
same as -P
-fpp[n], -[no]fpp
run Fortran preprocessor on source files prior to compilation
n=0 disable running the preprocessor, equivalent to nofpp
n=1,2,3 run preprocessor
-cpp[n] same as -fpp[n]
As most of us use the same pre-processing options for ifort and gfortran,
we don't notice that others also exist.

Steve Kargl schrieb am Mittwoch 10 Juni 2009 um 22:54:
> Have you asked Intel and Sun to support the gfortran
> syntax and feature?
Not yet. I like to spend my time on FLOSS projects rather than helping the
big commercial ones get their products sorted :P
--Maik

On Wed, Jun 10, 2009 at 02:12:27PM -0700, Tim Prince wrote:
> Steve Kargl wrote:
> > On Wed, Jun 10, 2009 at 10:29:16PM +0200, Maik Beckmann wrote:
> ...
> >>
> >> ifort and sunf95 both take
> >> -fpp
> >> to preprocess a source file while gfortran wants
> >> -cpp
> .....
> >> No show stoppers at all, but inconvenient.
> >>
> >
> > Have you asked Intel and Sun to support the gfortran
> > syntax and feature?
> >
> >From ifort -help:
> -fpp[n], -[no]fpp
> run Fortran preprocessor on source files prior to compilation
^^^^^^^^^^^^^^^^^^^^
-cpp with gfortran invokes the C preprocessor. gfortran does not
have a separate preprocessor designed to work with Fortran. You've
already hinted at the problem for Maik.
troutmask:sgk[213] cat a.F90
print *, 'Hello' // ' world!'
end
troutmask:sgk[214] gfc4x -cpp -o z a.F90
troutmask:sgk[215] ./z
Hello world!
troutmask:sgk[216] cpp -std=c99 a.F90
# 1 "a.F90"
# 1 ""
# 1 ""
# 1 "a.F90"
print *, 'Hello'
end
troutmask:sgk[217] cpp -std=c89 a.F90
# 1 "a.F90"
# 1 ""
# 1 ""
# 1 "a.F90"
print *, 'Hello' // ' world!'
end
--
Steve

Tim Prince schrieb am Mittwoch 10 Juni 2009 um 23:12:
> Steve Kargl wrote:
>
> >> ifort and sunf95 both take
> >> -fpp
> >> to preprocess a source file while gfortran wants
> >> -cpp
>
> .....
>
> >> No show stoppers at all, but inconvenient.
>
> -cpp[n] same as -fpp[n]
>
> As most of us use the same pre-processing options for ifort and gfortran,
> we don't notice that others also exist.
Thank you, I wasn't aware of.
There is what sun has to say;
-F Apply the preprocessor to .F and .F90 files, but do not
compile
-fpp Expands source code macros and enables conditional
compilation of code
-ftrap=[,...] Select floating-point trapping mode in effect at startup
-xpp[=] Select preprocessor; ={fpp|cpp}
Suffix 'S' Assembler source for cpp
I guess I did choose -fpp because the intel and sun compiler were the ones I
had to support first and its means the same to both.
However, I'm fine with the command switch. I shouldn't have bring it up.
As a mainly gcc using c++ coder and working with people who are intel and sun
fortran users I was just a little stunned by the unfamiliar preprocessor
behavior and wondered if this was just an oversight. If you guys say it stays
the way it is I fine with it. I'll continue to use the workaround I choose
right now
{{{
#ifdef __GNUC__
...
#else
...
#endif
}}}
Thanks,
--Maik

Steve Kargl schrieb am Mittwoch 10 Juni 2009 um 23:23:
> -cpp with gfortran invokes the C preprocessor. gfortran does not
> have a separate preprocessor designed to work with Fortran. You've
> already hinted at the problem for Maik.
>
> troutmask:sgk[213] cat a.F90
> print *, 'Hello' // ' world!'
> end
> troutmask:sgk[214] gfc4x -cpp -o z a.F90
> troutmask:sgk[215] ./z
> Hello world!
> troutmask:sgk[216] cpp -std=c99 a.F90
> # 1 "a.F90"
> # 1 ""
> # 1 ""
> # 1 "a.F90"
> print *, 'Hello'
> end
> troutmask:sgk[217] cpp -std=c89 a.F90
> # 1 "a.F90"
> # 1 ""
> # 1 ""
> # 1 "a.F90"
> print *, 'Hello' // ' world!'
> end
Thanks you for this explanations. This makes using the regular gcc cpp not
an options for me, since I know this kind of // concats are used a lot in our
code.
Thanks,
-- Maik

On Wed, Jun 10, 2009 at 11:38:01PM +0200, Maik Beckmann wrote:
> Steve Kargl schrieb am Mittwoch 10 Juni 2009 um 23:23:
>
> > -cpp with gfortran invokes the C preprocessor. gfortran does not
> > have a separate preprocessor designed to work with Fortran. You've
> > already hinted at the problem for Maik.
> >
> > troutmask:sgk[213] cat a.F90
> > print *, 'Hello' // ' world!'
> > end
> > troutmask:sgk[214] gfc4x -cpp -o z a.F90
> > troutmask:sgk[215] ./z
> > Hello world!
> > troutmask:sgk[216] cpp -std=c99 a.F90
> > # 1 "a.F90"
> > # 1 ""
> > # 1 ""
> > # 1 "a.F90"
> > print *, 'Hello'
> > end
>
> Thanks you for this explanations. This makes using the regular gcc cpp not
> an options for me, since I know this kind of // concats are used a lot in our
> code.
>
You can suppress the line numbering and stripping of the C99 comments
with -P and -C.
troutmask:sgk[204] cpp -P -C -std=c99 a.F90
print *, 'Hello' // ' world!'
end
I haven't looked into whether other problems exists. Tim might know.
--
Steve

Maik Beckmann wrote:
> As a mainly gcc using c++ coder and working with people who are intel and sun
> fortran users I was just a little stunned by the unfamiliar preprocessor
> behavior and wondered if this was just an oversight. If you guys say it stays
> the way it is I fine with it.
For the sake of explanation, not adding much to the discussion: gfortran
strives for compatibility with g77 (the longtime 'standard' Fortran
compiler). g77 used traditional preprocessing. That's why gfortran
behaves the way it does. I'm surprised other compilers chose to act
incompatibly. Since noone complained so far (as for all I remember), my
guess is that either the differences simply are not what Fortran users
care about or people are happy with g77-compatible behavior.
Regards,
- Tobi

Steve Kargl wrote:
> On Wed, Jun 10, 2009 at 11:38:01PM +0200, Maik Beckmann wrote:
>> Steve Kargl schrieb am Mittwoch 10 Juni 2009 um 23:23:
>>
>>> -cpp with gfortran invokes the C preprocessor. gfortran does not
>>> have a separate preprocessor designed to work with Fortran. You've
>>> already hinted at the problem for Maik.
>>>
>>> troutmask:sgk[213] cat a.F90
>>> print *, 'Hello' // ' world!'
>>> end
>>> troutmask:sgk[214] gfc4x -cpp -o z a.F90
>>> troutmask:sgk[215] ./z
>>> Hello world!
>>> troutmask:sgk[216] cpp -std=c99 a.F90
>>> # 1 "a.F90"
>>> # 1 ""
>>> # 1 ""
>>> # 1 "a.F90"
>>> print *, 'Hello'
>>> end
>> Thanks you for this explanations. This makes using the regular gcc cpp not
>> an options for me, since I know this kind of // concats are used a lot in our
>> code.
>>
>
> You can suppress the line numbering and stripping of the C99 comments
> with -P and -C.
>
> troutmask:sgk[204] cpp -P -C -std=c99 a.F90
>
>
> print *, 'Hello' // ' world!'
> end
>
> I haven't looked into whether other problems exists. Tim might know.
>
This is still somewhat of a wild and wooly area. Coincidentally, a
colleague (whom I had never before met in person) and I ran into the need
this afternoon to save the pre-processed file, rather than rely on
automatic .F pre-processing, so we fell back on 'gcc -traditional -x c -E
.....'
Due to the support of OpenMP (which requires some tradcpp or cpp-like
functionality, incompatible with the Coco standard) by most compilers,
there is a de facto requirement for a degree of commonality.

Maik Beckmann wrote:
> Steve Kargl schrieb am Mittwoch 10 Juni 2009 um 23:23:
>
>> -cpp with gfortran invokes the C preprocessor. gfortran does not
>> have a separate preprocessor designed to work with Fortran. You've
>> already hinted at the problem for Maik.
>>
> Thanks you for this explanations. This makes using the regular gcc cpp not
> an options for me, since I know this kind of // concats are used a lot in our
> code.
>
There is the plan to teach libcpp about Fortran comments and string
handling, which is a prerequisite for running CPP in not in the
-traditional mode. However, it is unclear when this project will be
completed. Would you be interested to work on it? (gfortran always needs
helping hands; essentially all who work on gfortran do so in their spare
time and have a background in physics, chemistry, meteorolgy etc.)
See e.g. the following bug report, which also has a preliminary patch
(Fortran comments) but lacks the Fortran string support.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
Tobias

Tobias Burnus schrieb am Donnerstag 11 Juni 2009 um 17:18:>
> There is the plan to teach libcpp about Fortran comments and string
> handling, which is a prerequisite for running CPP in not in the
> -traditional mode. However, it is unclear when this project will be
> completed.
ok
> Would you be interested to work on it? (gfortran always needs
> helping hands; essentially all who work on gfortran do so in their spare
> time and have a background in physics, chemistry, meteorolgy etc.)
Right now a do work on CMake's fortran support from time to time. There is no
time slot free to add another long time commitment.
However, what I'm willing to and already done a few times is to invest hours
or even days in writing good bug reports on gcc/gfortran (Reducing i.e. a
segfault in nK lines of (foreign) code to a few lines long self contained test
case is pretty time consuming).
Sorry,
-- Maik

Maik Beckmann wrote:
> Steve Kargl schrieb am Mittwoch 10 Juni 2009 um 22:54:
>> Have you asked Intel and Sun to support the gfortran
>> syntax and feature?
>
> Not yet. I like to spend my time on FLOSS projects rather than helping the
> big commercial ones get their products sorted :P
I can assure you they don't mind. Their representatives almost always
ask me at J3/Fortran meetings what part of Fortran 2003 we support with
the latest gfortran release.
Obviously, they do not want to fall behind.
Kind regards,
--
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html