Preprocessed fortran
gmail-unlp
I've posted this at http://groups.google.com/group/gnu-fortran/topics
but I don't even see my post there, so I also post here.
I have some fortran code in files with include directives, such as
$ cat printinc.f95
PROGRAM printinc
IMPLICIT NONE
INCLUDE 'printinc.h'
INTEGER :: i
DO i = 1, nloop
PRINT *, n
END DO
END PROGRAM printinc
$ cat printinc.h
INTEGER :: n, nloop
PARAMETER (n = 10, nloop = 10)
and I would like to obtain the .f95 file with the .h included (as I
assume the compiler do, but I don't know about compiler behavior very
deeply, of course), i.e. something like
PROGRAM printinc
IMPLICIT NONE
INTEGER :: n, nloop
PARAMETER (n = 10, nloop = 10)
INTEGER :: i
DO i = 1, nloop
PRINT *, n
END DO
END PROGRAM printinc
Is/Are there some gfortran compiler siwtch/es for this? If there are
for ifort, please tell me. I have no other compilers at hand...
Thanks in advance,
Fernando.
steve
> but I don't even see my post there, so I also post here.
>
> I have some fortran code in files with include directives, such as
>
> $ cat printinc.f95
> PROGRAM printinc
>
> IMPLICIT NONE
>
> INCLUDE 'printinc.h'
It seems that you are confusing C terminology with a Fortran
feature. "INCLUDE 'printinc.h'" is not a pre-processing directive.
It is a Fortran statement. With gfortran (and I assume other
compilers), it will start to read the file printinc.f95 and process
the statements leading up to "INCLUDE 'printinc.h'". When
gfortran processes that statement, it simply opens the files
and continues processing without 'copying' the content into
printinc.f95. When gfortran hits the end of printinc.h, it closes
the file and returns to processing printinc.f95.
If you want to treat INCLUDE as if it is a C pre-processor
directive, then rename INCLUDE to #include (yes, case is
important), and make sure the # is in the 1st column.
Then, invoke gfortran with
gfortran -cpp -E printinc.f90
troutmask:sgk[219] gfc4x -cpp -E er.f90
# 1 "er.f90"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "er.f90"
PROGRAM printinc
IMPLICIT NONE
# 1 "printinc.h" 1
INTEGER :: n, nloop
PARAMETER (n = 10, nloop = 10)
# 6 "er.f90" 2
INTEGER :: i
DO i = 1, nloop
PRINT *, n
END DO
END PROGRAM printinc
--
steve
gmail-unlp
Thanks, steve,
You are right, I'm confusing C terminology with a Fortran feature.
Thanks for the rest too, it is what I need right now.
Fernando.
Ken Fairfield
>
> I've posted this athttp://groups.google.com/group/gnu-fortran/topics
Steve commented on Fortran INCLUDE vs. C #include in
terms of both terminology and what the compiler needs
to do functionally.
I'd just note that commercial compilers, at least in the
past, used to optionally provide a listing file which gave
line numbers as counted by the compiler (helpful when
correlating error messages to source code), and those
could optionally include, or not, the expanded INCLUDE
file in the listing. Check whether your compiler supports
such an option.
-Ken
Dan Nagle
On 2010-12-30 15:47:15 -0500, steve said:
> "INCLUDE 'printinc.h'" is not a pre-processing directive.
> It is a Fortran statement.
Just to indulge in a bit of nitpicking ...
Include is a Fortran line, not a statement. See 3.4 of 10-007r1.
You can't, for example, have any text other then the include line
on the same line, other than a trailing comment.
Steve probably knows much better than I do how gfortran handles
include lines. And he is certainly correct about not confusing
C preprocessor terminology and Fortran concepts.
--
Cheers!
Dan Nagle
glen herrmannsfeldt
> On Dec 30, 12:04 pm, gmail-unlp <ftine...@gmail.com> wrote:
>> I've posted this athttp://groups.google.com/group/gnu-fortran/topics
>> but I don't even see my post there, so I also post here.
>> I have some fortran code in files with include directives, such as
(snip)
>> INCLUDE 'printinc.h'
(snip)
> Steve commented on Fortran INCLUDE vs. C #include in
> terms of both terminology and what the compiler needs
> to do functionally.
The early C compilers did it with a separate program, writing
an intermediate file, such that the term "pre-processor" had
a specific meaning. Most now don't work that way, but it is
still considered a preprocessor, as the processing happens
before the compilation part sees the line. It doesn't seem
so far off to call the similar function by Fortran preprocessing.
> I'd just note that commercial compilers, at least in the
> past, used to optionally provide a listing file which gave
> line numbers as counted by the compiler (helpful when
> correlating error messages to source code), and those
> could optionally include, or not, the expanded INCLUDE
> file in the listing. Check whether your compiler supports
> such an option.
The C preprocessor generates # lines in the output such that error
messages can give the appropriate file and line number.
-- glen
gmail-unlp
Thanks, Ken. Right now, I need "all Fortran code" without Includes
in each file, but thanks anyway, this may be helpful for the ifort
or other compilers, since gfortran does not seem to expand included
files, according to what I understand from steve answer.
Fernando.
gmail-unlp
Thanks, Dan. After reading steve answer I was going to ask just about
the/some reference in the standard in order to have clearer concepts/
avoid confusion in the future. And you already answered my
not-already-made question.
Thank you so much,
Fernando.
gmail-unlp
> Ken Fairfield <ken.fairfi...@gmail.com> wrote:
> > On Dec 30, 12:04 pm, gmail-unlp <ftine...@gmail.com> wrote:
> >> I've posted this athttp://groups.google.com/group/gnu-fortran/topics
> >> but I don't even see my post there, so I also post here.
> >> I have some fortran code in files with include directives, such as
> (snip)
> >> INCLUDE 'printinc.h'
>
> (snip)
>
> > Steve commented on Fortran INCLUDE vs. C #include in
> > terms of both terminology and what the compiler needs
> > to do functionally.
>
> The early C compilers did it with a separate program, writing
> an intermediate file, such that the term "pre-processor" had
> a specific meaning. Most now don't work that way, but it is
> still considered a preprocessor, as the processing happens
> before the compilation part sees the line. It doesn't seem
> so far off to call the similar function by Fortran preprocessing.
I'm quite near this line of thinking, but I have to take into
account steve and Dan answers/suggestions. More specifically, I'll
try to reach/read/understand the reference so kindly given by Dan
about Fortran Include lines.
Thank you, glen,
Fernando.
glen herrmannsfeldt
(snip)
>> > INCLUDE 'printinc.h'
(snip)
> Thanks, Ken. Right now, I need "all Fortran code" without Includes
> in each file, but thanks anyway, this may be helpful for the ifort
> or other compilers, since gfortran does not seem to expand included
> files, according to what I understand from steve answer.
Well, the INCLUDE is standard Fortran, but it isn't a Fortran
statement. Also, it is usual for C compilers to have an option
to output the preprocessed file, but not usual for Fortran compilers
to output the result of INCLUDE lines.
-- glen
gmail-unlp
wrote:
You are right, my mistake again, this time I know the concepts but my
English is far from good, so I sometimes I write some nonsense...
sorry
and thank you again, glen,
Fernando.
steve
> Ken Fairfield <ken.fairfi...@gmail.com> wrote:
> > On Dec 30, 12:04 pm, gmail-unlp <ftine...@gmail.com> wrote:
> >> I've posted this athttp://groups.google.com/group/gnu-fortran/topics
> >> but I don't even see my post there, so I also post here.
> >> I have some fortran code in files with include directives, such as
> (snip)
> >> INCLUDE 'printinc.h'
>
> (snip)
>
> > Steve commented on Fortran INCLUDE vs. C #include in
> > terms of both terminology and what the compiler needs
> > to do functionally.
>
> The early C compilers did it with a separate program, writing
> an intermediate file, such that the term "pre-processor" had
> a specific meaning.
It still has a specific meaning within the context of
the C programming language. See for example Sec. 5.1.1.1
and Sec 6.10 of n1256.pdf. Oddly, the word "preprocess[ing|or]"
appears on the order of hundred times in n1256.pdf;
while it appears to be absences in the final committee
draft of the Fortran 2003 Part 1.
> Most now don't work that way, but it is
> still considered a preprocessor, as the processing happens
> before the compilation part sees the line. It doesn't seem
> so far off to call the similar function by Fortran preprocessing.
Twisting the words to suit your needs? A Fortran processor
does no preprocessing when it processes an INCLUDE line.
Sec 3.4 in F2003 is fairly clear on what INCLUDE is/does.
--
steve
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>Ken Fairfield <ken.fa...@gmail.com> wrote:
>
>> Steve commented on Fortran INCLUDE vs. C #include in
>> terms of both terminology and what the compiler needs
>> to do functionally.
>
>The early C compilers did it with a separate program, writing
>an intermediate file, such that the term "pre-processor" had
>a specific meaning. Most now don't work that way, but it is
>still considered a preprocessor, as the processing happens
>before the compilation part sees the line. It doesn't seem
>so far off to call the similar function by Fortran preprocessing.
You are right about the history, but wrong about what now happens.
Decoding #if expressions requires a 'look-forward' into a later
phase. If I recall correctly, C99 introduced an obscure aspect
by which another aspect of the compilation could affect the action
of the preprocessor, but I forget the details now. There were just
SO many subtle problems in C99 :-(
Only REAL experts (and I mean in C arcana, not Fortran) can use
the C preprocessor safely in C code, and all of the ones I know of
also know better than to do it.
Most people get away with it, because simple uses in combination
with a C90 compiler switch are fairly safe. But every now and
then they come unstuck, and have difficulty believing what they
are told when they consult a real expert.
Regards,
Nick Maclaren.
glen herrmannsfeldt
(snip, I wrote)
>>The early C compilers did it with a separate program, writing
>>an intermediate file, such that the term "pre-processor" had
>>a specific meaning. Most now don't work that way, but it is
>>still considered a preprocessor, as the processing happens
>>before the compilation part sees the line. It doesn't seem
>>so far off to call the similar function by Fortran preprocessing.
> You are right about the history, but wrong about what now happens.
> Decoding #if expressions requires a 'look-forward' into a later
> phase.
Well, C doesn't have the %GOTO that PL/I has, which would seem to
complicate preprocessing. Well, I just looked it up and only
forward %GOTO is allowed. %DO for loops, though the compiler knows
exactly which statements are in the loop.
I believe that at some point, many C compilers went to pipes to
avoid the intermediate file overhead. I do know that the Hercules
project, trying to get gcc to run on S/370, found that it wouldn't
compile in less than 16MB. (Well, the OS takes up some, but I
believe that even without the OS it still wouldn't fit.) What is
it doing with all that memory? It would seem to be keeping things
in memory that previously would have gone to disk.
I remember when 300K was considered big for a compiler, and
now 16M is considered reasonable.
> If I recall correctly, C99 introduced an obscure aspect
> by which another aspect of the compilation could affect the action
> of the preprocessor, but I forget the details now. There were just
> SO many subtle problems in C99 :-(
So far, I haven't been very interested in C99.
> Only REAL experts (and I mean in C arcana, not Fortran) can use
> the C preprocessor safely in C code, and all of the ones I know of
> also know better than to do it.
Well, you do learn early to put ()'s around all the arguments
and also the whole macro result.
> Most people get away with it, because simple uses in combination
> with a C90 compiler switch are fairly safe. But every now and
> then they come unstuck, and have difficulty believing what they
> are told when they consult a real expert.
Oh, C99 specific? Hmm.
-- glen
viper-2
>
> The early C compilers did it with a separate program, writing
> an intermediate file, such that the term "pre-processor" had
> a specific meaning. Most now don't work that way, but it is
> still considered a preprocessor, as the processing happens
> before the compilation part sees the line. It doesn't seem
> so far off to call the similar function by Fortran preprocessing.
>
Only discovered a few months ago that Fortran used the C preprocessor
myself. When programming in C I'd taken the #includes pretty much for
granted without exploring the power of the preprocessor. So now I've
discovered the magic of the -D switch at compile time to alter Fortran
source code. I kind of expected Fortran to use a Fortran
preprocessor.:-)
agt
Richard Maine
> Only discovered a few months ago that Fortran used the C preprocessor
> myself.
"Fortran", unqualified like that, which generally means the language,
doesn't. Some particular Fortran compilers do. In fact, it is reasonably
common, but it still isn't what "Fortran" does.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Tim Prince
> viper-2<a...@codeartnow.com> wrote:
>
>> Only discovered a few months ago that Fortran used the C preprocessor
>> myself.
>
> "Fortran", unqualified like that, which generally means the language,
> doesn't. Some particular Fortran compilers do. In fact, it is reasonably
> common, but it still isn't what "Fortran" does.
>
by Fortran standard) requires some cpp syntax, but it's not "the" C
pre-processor, in the sense of a pre-processor which works with current
C or C++. gfortran does offer an actual C89 compatible pre-processor,
called tradcpp. Except for the small extent to which OpenMP specifies
pre-processing, there's no standard for cpp-like pre-processing in
Fortran compilers, and it's entirely possible to avoid it.
--
Tim Prince
steve
gfortran does no preprocessing to handle OpenMP.
If gfortran is invoked with -fopenmpi and an
OpenMP directive is found in the code, gfortran
simply processes that directive.
--
steve
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> [ C preprocessing ]
>
>> Most people get away with it, because simple uses in combination
>> with a C90 compiler switch are fairly safe. But every now and
>> then they come unstuck, and have difficulty believing what they
>> are told when they consult a real expert.
>
>Oh, C99 specific? Hmm.
No.
C99 makes it worse, but the problems are there in C90 and even K&R.
For a trivial example, consider a string that contains backslashes
or trigraph sequences. However, it's the more subtle gotchas that
catch people - how many people do YOU know who are experts on the
minutiae of both the C and Fortran standards? :-)
Regards,
Nick Maclaren.
Tim Prince
#ifdef _OPENMP
...
#endif
(specified as available by OpenMP standard) is needed frequently,
although not always, and that seems likely to depend on pre-processing.
As Steve points out, OpenMP usually performs its own expansion of
!$omp directives independent of cpp-like pre-processing.
viper-2
> "Fortran", unqualified like that, which generally means the language,
> doesn't. Some particular Fortran compilers do. In fact, it is reasonably
> common, but it still isn't what "Fortran" does.
Thanks for reminding me. At some point I'll need to find out what
other compilers work for C-Graph, besides G95 and Gfortran.
BTW, please add the C-preprocessor (for some Fortran compilers) to my
list of "discoveries" on the Happy New Year thread.:-)
agt
viper-2
> > Only discovered a few months ago that Fortran used the C preprocessor
> > myself.
>
> "Fortran", unqualified like that, which generally means the language,
> doesn't. Some particular Fortran compilers do. In fact, it is reasonably
> common, but it still isn't what "Fortran" does.
>
I've included a note on the webpage for C-Graph 2.0:
<https://sites.google.com/site/codeartnow/code/download/c-graph-1/c-
graph-version-2-preview#note1>
Thanks again.
agt
gmail-unlp
Replying to myself just to make a closure... I think...
I've changed every Fortran
INCLUDE '<filename>'
by
#include "<filename>"
using sed, basically. Then,
gfortran -cpp -E
and, later
gfortran -c
and everything seems to work ok. I remember
...
>> It doesn't seem
>> so far off to call the similar function by Fortran preprocessing.
...
> I'm quite near this line of thinking, but I have to take into
> account steve and Dan answers/suggestions.
and, so far, at least gfrotran seems to compile Fortran INCLUDE as if
preprocessing #include... ok, ok, I think I know differences, it's
just that the result is the same, at the end.
Just a minor comment: some INCLUDE lines have comments after ! and the
compiler works ok, only when compiling such lines with #include the
compiler shows a warning.
Thank you all,
Fernando.
Richard Maine
> and, so far, at least gfrotran seems to compile Fortran INCLUDE as if
> preprocessing #include... ok, ok, I think I know differences, it's
> just that the result is the same, at the end.
Sometimes it is the same - but not always. If you think of them as being
the same, you will probably end up being one of the multiple people who
have posted here about their confusions.
The one thing I think it most important to watch for is mixing the two
forms. As long as you stick to only one, you might be ok. But if you
indiscriminately mix the two without thinking about the difference, then
it is likely to eventually bite you.
Mostly, this is because the #include stuff really is done by
preprocessing, with emphasis on the "pre" part. So any #include that is
in a file included by the Fortran include won't get processed because
that #include is not encountered until later - during the Fortran
include processing. Anyway, that's the most usual problem.
Your observation about the ! comments generating a warning with #include
is because those lines are not processed by the Fortran compiler. The
Fortran compiler might invoke the preprocessor for you, but in the end
it is a C preprocessor, which doesn't know about Fortran. If you want to
use a non-Fortran preprocessor, you need to follow its rules. The !
comment is a Fortran thing.
steve
NO, No, no! If you invoke gfortran to use the C pre-processor, the
C pre-processor copies the input to a file (or pipe or into memory
depends on the option combination). When it hits a C pre-processing
directive, the C pre-processor does whatever that directive would
do as-if it were a C program and it sends the result to the file
(or pipe or into memory). Once the entire file has been pre-
processed,
the Fortran compiler starts at the beginning of the pre-processed
code.
OTOH, if the code has a Fortran INCLUDE line, and gfortran
is not invoked to use the C pre-processor, then gfortran
starts to compile file. When it hits the INCLUDE, gfortran
opens the file in INCLUDE line and start to process that
file as-if the contents of that file were well included at
that location in the original file. Once gfortran completes
processing the file in the INCLUDE line, it picks up at
the next line in the original file.
> Just a minor comment: some INCLUDE lines have comments after ! and the
> compiler works ok, only when compiling such lines with #include the
> compiler shows a warning.
Is '!' a valid character within the C programming language to
denote a comment?
--
steve
gmail-unlp
Waw! take it easy...
And thank you again,
Fernando.
gmail-unlp
> gmail-unlp <ftine...@gmail.com> wrote:
> > and, so far, at least gfrotran seems to compile Fortran INCLUDE as if
> > preprocessing #include... ok, ok, I think I know differences, it's
> > just that the result is the same, at the end.
>
> Sometimes it is the same - but not always. If you think of them as being
> the same, you will probably end up being one of the multiple people who
> have posted here about their confusions.
Well, I think that in this particular case, i.e.
Fortran INCLUDE
preprocessor #include
are never the same (if you think otherwise, look at steve's post...),
I just wrote... well... what I wrote, the text is near this place...
And yes, I post here about my confusions, I think this is exactly the
reason why I post, in fact. And thank you, your post and explanations
usually lead me to understand Fortran issues/definitions/etc. I
usually tend to follow the rules, and this "processing" is forced by
some non-complete development tools I'm using with a medium-sized
legacy project. Otherwise, I would not use the cpp at all, I would
like to maintain "pure" Fortran at least regarding INCLUDEs.
Thanks again,
Fernando.
Uno
> Well, I think that in this particular case, i.e.
>
> Fortran INCLUDE
> preprocessor #include
>
> are never the same (if you think otherwise, look at steve's post...),
> I just wrote... well... what I wrote, the text is near this place...
>
> And yes, I post here about my confusions, I think this is exactly the
> reason why I post, in fact. And thank you, your post and explanations
> usually lead me to understand Fortran issues/definitions/etc. I
> usually tend to follow the rules, and this "processing" is forced by
> some non-complete development tools I'm using with a medium-sized
> legacy project. Otherwise, I would not use the cpp at all, I would
> like to maintain "pure" Fortran at least regarding INCLUDEs.
I never use fortran's INCLUDE, although I realize that it's part of the
syntax. The motivation to use it in C might be
#include <stdio.h>
int main(void)
{
printf("Ducks were good.\n");
return 0;
}
C wouldn't know what to do with the printf call without the prototype in
stdio.h. In fortran, the intrinsics are already there:
print *, "Tigers were better."
endprogram
--
Uno
With fortran, the intrinsics are already in the food