difference between g77 and gfortran
Jinson...@gmail.com
I am trying to compile a old fortran package using gfortran. the
compilation is ok, however, the results may be something wrong. If i
use g77, it give correct results.
the command i used is:
gfortran -Wall -fno-automatic -finit-local-zero *.for -o a.exe
g77 -Wall -fno-automatic -finit-local-zero *.for -o b.exe
the message i think will help to solve the problem are pasted below.
for the source code is about 10,000 lines, i cannot paste it here.
Thanks in advance,
Jinsong
--------------
a.exe give results:
i am entering inter: itrmax = 0
i will start here: jalp = 0 frst = T
i will go back: jalp = 0 frst= T
i will go back: jalp = 0 frst= T
i will go back: jalp = 1 frst= F
i will go back: jalp = 2 frst= T
i will go back: jalp = 1 frst= F
i will go back: jalp = 2 frst= T
i will go back: jalp = 1 frst= F
i will go back: jalp = 2 frst= T
i will go back: jalp = 1 frst= F
i will go back: jalp = 2 frst= T
i will go back: jalp = 1 frst= F
i will go back: jalp = 2 frst= T
i am leaving iter: itrmax = 200
i am entering inter: itrmax = 0
i will start here: jalp = 0 frst = T
b.exe give results:
i am entering into iter: itrmax = 0
i will start here: jalp = 0 frst = T
i will go back: jalp = 0 frst = T
i will go back: jalp = 0 frst = T
i will go back: jalp = 1 frst = F
i will go back: jalp = 2 frst = F
i will go back: jalp = 3 frst = F
i will go back: jalp = 4 frst = F
i will go back: jalp = 5 frst = F
i will go back: jalp = 6 frst = F
i am leaving iter: itrmax = 200
i am entering into iter: itrmax = 200
i will start here: jalp = 6 frst = T
i will go back: jalp = 1 frst = F
i will go back: jalp = 2 frst = F
Jinson...@gmail.com
gfortran --version
GNU Fortran (GCC) 4.4.0 20080603 (experimental) [trunk revision
136333]
Copyright (C) 2008 Free Software Foundation, Inc.
f77 --version
GNU Fortran (GCC) 3.4.6 [FreeBSD] 20060305
Copyright (C) 2006 Free Software Foundation, Inc.
Thanks,
Jinsong
Gib Bogle
The error is in line 6827.
Richard Maine
> I am trying to compile a old fortran package using gfortran. the
> compilation is ok, however, the results may be something wrong. If i
> use g77, it give correct results.
>
> the command i used is:
>
> gfortran -Wall -fno-automatic -finit-local-zero *.for -o a.exe
>
> g77 -Wall -fno-automatic -finit-local-zero *.for -o b.exe
>
> the message i think will help to solve the problem are pasted below.
I'm sorry, but no, that gives pretty close to zero information useful
for such debugging.
The only thing at all useful I notice is the switches to disable
automatic variables and to initialize variables to zero. The need sof
these switches suggests that the code is nonstandard in at least those
regards, which might suggest that it is nonstandard in others as well.
I realize that, even if accurate, that isn't of much concrete help, but
I don't think you are going to get much more useful from the data given.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Jinson...@gmail.com
>
> The only thing at all useful I notice is the switches to disable
> automatic variables and to initialize variables to zero. The need sof
> these switches suggests that the code is nonstandard in at least those
> regards, which might suggest that it is nonstandard in others as well.
>
Thank you very much for your reply. And you are right. The code is
nonstandard.
When I add ``save'' to some subroutines, it seems to give same results
as the g77 give. however, i am confused about the gfortran's option ``-
fno-automatic''. if i correctly understand, it should same as that one
of g77. I don't know why there's some difference.
Regards,
Jinsong
Steven G. Kargl
"Jinson...@gmail.com" <Jinson...@gmail.com> writes:
> When I add ``save'' to some subroutines, it seems to give same results
> as the g77 give. however, i am confused about the gfortran's option ``-
> fno-automatic''. if i correctly understand, it should same as that one
> of g77. I don't know why there's some difference.
You do realize that g77 and gfortran have absolutely nothing
in common. The options may have the same names and intended
purpose, but gfortran is a much more complicated piece of
software due to the increased complexity of Fortran 95 over
Fortran 77.
Given your experience with -fno-automatic and -finit-local-zero,
you may want to drop those option, add -Wall, and actually fix
your code.
--
steve
Tobias Burnus
wrote:
> "Jinsong.Z...@gmail.com" <Jinsong.Z...@gmail.com> writes:
> > When I add ``save'' to some subroutines, it seems to give same results
> > as the g77 give. however, i am confused about the gfortran's option ``-
> > fno-automatic''. if i correctly understand, it should same as that one
> > of g77. I don't know why there's some difference.
Can you give an example for a subroutine where an explicit SAVE works
and -fno-automatic doesn't?
> You do realize that g77 and gfortran have absolutely nothing
> in common. The options may have the same names and intended
> purpose, but gfortran is a much more complicated piece of
> software due to the increased complexity of Fortran 95 over
> Fortran 77.
As Steve already wrote: g77 and gfortran have no (or essentially no?)
code in common.
However, I think the option should do what you want:
-fno-automatic
Treat each program unit (except those marked as
RECURSIVE) as if the "SAVE" statement were specified
for every local variable and array referenced in it.
Does not affect common blocks. (Some Fortran
compilers provide this option under the name -static
or -save.) The default, which is -fautomatic, uses
the stack for local variables smaller than the value
given by -fmax-stack-var-size. Use the option
-frecursive to use no static memory.
for completeness, g77's manpage has:
-fno-automatic
Treat each program unit as if the "SAVE" statement
was specified for every local variable and array
referenced in it. Does not affect common blocks.
(Some Fortran compilers provide this option under
the name -static.)
Tobias
Jinson...@gmail.com
wrote:
>
> You do realize that g77 and gfortran have absolutely nothing
> in common. The options may have the same names and intended
> purpose, but gfortran is a much more complicated piece of
> software due to the increased complexity of Fortran 95 over
> Fortran 77.
>
Thanks for your comments.
> Given your experience with -fno-automatic and -finit-local-zero,
> you may want to drop those option, add -Wall, and actually fix
> your code.
>
I have used -Wall, however, it dose not give me any warnings. For I am
new to Fortran, I don't have enough experience to deal with such
complicated problems that I meet when I try to deal with old Fortran
program.
Any way, thanks again.
Jinsong
Jinson...@gmail.com
>
> Can you give an example for a subroutine where an explicit SAVE works
> and -fno-automatic doesn't?
>
Because it's a large old program, all code together exceed 10,000
lines. For different input, different subroutines are executed. I
don't know how to reduce the code. If anyone is interested in it, I
could sent it to his mailbox.
>
> However, I think the option should do what you want:
>
> -fno-automatic
> Treat each program unit (except those marked as
> RECURSIVE) as if the "SAVE" statement were specified
> for every local variable and array referenced in it.
> Does not affect common blocks. (Some Fortran
> compilers provide this option under the name -static
> or -save.) The default, which is -fautomatic, uses
> the stack for local variables smaller than the value
> given by -fmax-stack-var-size. Use the option
> -frecursive to use no static memory.
>
> for completeness, g77's manpage has:
>
> -fno-automatic
> Treat each program unit as if the "SAVE" statement
> was specified for every local variable and array
> referenced in it. Does not affect common blocks.
> (Some Fortran compilers provide this option under
> the name -static.)
>
From the manpage, I think -fno-automatic in g77 and gfrotran should do
the same things, however, at least, in my code, the -fno-automatic in
gfortran seems not work.
Steven G. Kargl
"Jinson...@gmail.com" <Jinson...@gmail.com> writes:
> On Oct 14, 12:45 am, Tobias Burnus <bur...@net-b.de> wrote:
>>
>> Can you give an example for a subroutine where an explicit SAVE works
>> and -fno-automatic doesn't?
>>
> Because it's a large old program, all code together exceed 10,000
> lines. For different input, different subroutines are executed. I
> don't know how to reduce the code. If anyone is interested in it, I
> could sent it to his mailbox.
You can send me the code and whatever input data files you have.
I can't promise anything.
Since you say it's old code, you might want to run it through
ftnchek (a free program), which checks Fortran 77 program for
synatx and semantics.
>> However, I think the option should do what you want:
>>
>> -fno-automatic
>> Treat each program unit (except those marked as
>> RECURSIVE) as if the "SAVE" statement were specified
>> for every local variable and array referenced in it.
>> Does not affect common blocks. (Some Fortran
>> compilers provide this option under the name -static
>> or -save.) The default, which is -fautomatic, uses
>> the stack for local variables smaller than the value
>> given by -fmax-stack-var-size. Use the option
>> -frecursive to use no static memory.
>>
>> for completeness, g77's manpage has:
>>
>> -fno-automatic
>> Treat each program unit as if the "SAVE" statement
>> was specified for every local variable and array
>> referenced in it. Does not affect common blocks.
>> (Some Fortran compilers provide this option under
>> the name -static.)
>>
> From the manpage, I think -fno-automatic in g77 and gfrotran should do
> the same things, however, at least, in my code, the -fno-automatic in
> gfortran seems not work.
I suspect your problem is more complicated than whether -fno-automatic
is set or not. In another response, you say:
When I add ``save'' to some subroutines, it seems to give same
results as the g77 give. however, i am confused about the gfortran's
option ``-fno-automatic''. if i correctly understand, it should
same as that one of g77. I don't know why there's some difference.
You have never actually stated what those differences are.
--
steve
Jinson...@gmail.com
wrote:
>
> > Because it's a large old program, all code together exceed 10,000
> > lines. For different input, different subroutines are executed. I
> > don't know how to reduce the code. If anyone is interested in it, I
> > could sent it to his mailbox.
>
> You can send me the code and whatever input data files you have.
> I can't promise anything.
>
I will sent it to you soon. Thanks!
> Since you say it's old code, you might want to run it through
> ftnchek (a free program), which checks Fortran 77 program for
> synatx and semantics.
>
I have run it through spay from plusFort for Linux, so I think the
code would be readable.
>
> I suspect your problem is more complicated than whether -fno-automatic
> is set or not. In another response, you say:
>
> When I add ``save'' to some subroutines, it seems to give same
> results as the g77 give. however, i am confused about the gfortran's
> option ``-fno-automatic''. if i correctly understand, it should
> same as that one of g77. I don't know why there's some difference.
>
> You have never actually stated what those differences are.
>
I don't know how to state the problem. With the specific input files,
gfortran gave same result whether I add the ``-fno-automatic'' or not.
If I add ``SAVE'' to some subroutines, gfrotran gave same result with
that of g77 with ``-fno-automatic''.
Jinsong
Steven G. Kargl
I don't understand. Are you saying that gfortran and g77 always
agree when use the same input file? If the answer is yes, then
why are you concerned with whether you need -fno-automatic or not?
If the executables produced by gfortran and g77 give different
results for the same input file, then what are those differences?
--
steve
--
steve
Jinson...@gmail.com
wrote:
>
> I don't understand. Are you saying that gfortran and g77 always
> agree when use the same input file? If the answer is yes, then
> why are you concerned with whether you need -fno-automatic or not?
>
> If the executables produced by gfortran and g77 give different
> results for the same input file, then what are those differences?
>
For the same input file, the executable produced by gfortran and g77
should give same results.
Now, if no ``SAVE'' added to code, g77 could give correct result,
however gfortran dose not. In this situation, -fno-automatic is given
to both g77 and gfortran.
if added ``SAVE'', -fno-automatic is not necessary for both gfortran
and g77. It indicated that -fno-automatic in gfortran do the different
thing and not like what said in the manpage.
I hope I make me understood.
Regards,
Jinsong
Steven G. Kargl
"Jinson...@gmail.com" <Jinson...@gmail.com> writes:
> On Oct 14, 1:01 pm, ka...@REMOVE.apl.washington.edu (Steven G. Kargl)
> wrote:
>>
>> I don't understand. Are you saying that gfortran and g77 always
>> agree when use the same input file? If the answer is yes, then
>> why are you concerned with whether you need -fno-automatic or not?
>>
>> If the executables produced by gfortran and g77 give different
>> results for the same input file, then what are those differences?
>>
Aargh!
> For the same input file, the executable produced by gfortran and g77
> should give same results.
Do the executables produce the same exact result?
If the answer is no, what are the exact differences?
> Now, if no ``SAVE'' added to code, g77 could give correct result,
What do you mean by "could"? "Could" g77 give the wrong result?
> however gfortran dose not.
You have provided no evidence that gfortran gives a wrong result.
Please explicitly tell us what the correct result is and what the
wrong result is!
> In this situation, -fno-automatic is given
> to both g77 and gfortran.
> if added ``SAVE'', -fno-automatic is not necessary for both gfortran
> and g77. It indicated that -fno-automatic in gfortran do the different
> thing and not like what said in the manpage.
> I hope I make me understood.
No, I do not understand!
What are the differences? I mean tell me exactly what are the
differences! What is the difference in the output files?
g77 and gfortran are completely different compilers. The
actions of -fno-automatic may differ for some reason. Maybe
gfortran (or g77) can't determine if a variable should have the
SAVE attribute applied under the -fno-automatic flag. I can't
read your mind. You have to tell us exactly what the right answer
is, what the expected answer is, and what you consider to be the
wrong answer.
Have you run the code through ftnchek? I suspect, but can't prove,
you have several common errors (such as default real literal constants
initializing double precisions, abuse of the equivalence statement,
using unitialized variables, argument mismatches in subroutines).
--
steve
Jinson...@gmail.com
wrote:
>
> No, I do not understand!
oops, i am sorry.
>
> What are the differences? I mean tell me exactly what are the
> differences! What is the difference in the output files?
>
> g77 and gfortran are completely different compilers. The
> actions of -fno-automatic may differ for some reason. Maybe
> gfortran (or g77) can't determine if a variable should have the
> SAVE attribute applied under the -fno-automatic flag. I can't
> read your mind. You have to tell us exactly what the right answer
> is, what the expected answer is, and what you consider to be the
> wrong answer.
>
For the specific input file, I know its result, and it's same as the
output of g77 with options ``-fno-automatic -finit-local-zero''. But
gfortran give a different results.
> Have you run the code through ftnchek? I suspect, but can't prove,
> you have several common errors (such as default real literal constants
> initializing double precisions, abuse of the equivalence statement,
> using unitialized variables, argument mismatches in subroutines).
>
No, I don't have run the code through ftnchek. the common errors what
you said seems acceptable to g77.
I just downloaded ftncheck, and run the code through it. It give me so
many warnings! It's a difficult task for me to eliminate all of them.
Maybe, it could give me more experience on Fortran.
Thanks,
Jinsong
JB
> For the specific input file, I know its result, and it's same as the
> output of g77 with options ``-fno-automatic -finit-local-zero''. But
> gfortran give a different results.
I think the question is, how do you know that the 'correct' result is
the correct one?
>> Have you run the code through ftnchek? I suspect, but can't prove,
>> you have several common errors (such as default real literal constants
>> initializing double precisions, abuse of the equivalence statement,
>> using unitialized variables, argument mismatches in subroutines).
>>
>
> No, I don't have run the code through ftnchek. the common errors what
> you said seems acceptable to g77.
You seem to labor under the assumption that if the thing compiles, then
it must be correct, and any differences must be due to compiler bugs.
Unfortunately, however much we might wish otherwise, reality is not that
simple.
Most compilers are pretty good about standard conforming code (which of
course doesn't mean that the results are 'correct' e.g. due to
programming mistakes such as assuming FP computations produces bit-exact
results), but once you give the standard the proverbial finger anything
more or less semi-random might happen. Sure, through trial and error you
might get something to 'work', but that's not a guarantee it will work
the same way, or at all, in another environment.
> I just downloaded ftncheck, and run the code through it. It give me so
> many warnings! It's a difficult task for me to eliminate all of them.
> Maybe, it could give me more experience on Fortran.
Fixing these warnings is probably a good start if you wish g77 and
gfortran to produce the same and hopefully correct results.
Of course, it could still be a bug in gfortran (or g77), but with the
information you have provided it's impossible to say. Though my guess
would be that it's some non-standardism that just happens to behave
differently in gfortran than in g77 (caveat emptor, see above).
--
JB
Jinson...@gmail.com
> On 2008-10-14, Jinsong.Z...@gmail.com <Jinsong.Z...@gmail.com> wrote:
>
> I think the question is, how do you know that the 'correct' result is
> the correct one?
I don't think it's a question. The code is old enough, and the result
have been tested in a widely way. Thus I know the correct result.
>
> You seem to labor under the assumption that if the thing compiles, then
> it must be correct, and any differences must be due to compiler bugs.
> Unfortunately, however much we might wish otherwise, reality is not that
> simple.
>
I don't assume the differences is compiler bugs. I just confused by
the same options provided by two compilers, and I think they should do
the same thing. However, I may be fault.
> Most compilers are pretty good about standard conforming code (which of
> course doesn't mean that the results are 'correct' e.g. due to
> programming mistakes such as assuming FP computations produces bit-exact
> results), but once you give the standard the proverbial finger anything
> more or less semi-random might happen. Sure, through trial and error you
> might get something to 'work', but that's not a guarantee it will work
> the same way, or at all, in another environment.
>
> Fixing these warnings is probably a good start if you wish g77 and
> gfortran to produce the same and hopefully correct results.
>
> Of course, it could still be a bug in gfortran (or g77), but with the
> information you have provided it's impossible to say. Though my guess
> would be that it's some non-standardism that just happens to behave
> differently in gfortran than in g77 (caveat emptor, see above).
>
I absolutely agree with you. The code is old enough, and not coded by
professional programmer, there are many common errors as what steve
have pointed. I just hope to compile it under Linux, using both g77
and gfortran. I will try my best to fix those warnings, and hope the
both would give same and correct results.
Jinsong
user1
>
> if added ``SAVE'', -fno-automatic is not necessary for both gfortran
> and g77. It indicated that -fno-automatic in gfortran do the different
> thing and not like what said in the manpage.
>
>
It seems that your main observation is that -fno-automatic does not work as
advertised with gfortran ? It also seems that sgk has trouble believing this. It
would be nice if we could find a test case to demonstrate it.
Do you get the correct result with "SAVE"'s added to the code with both
compilers ? (g77 and gfortran)
Are you running linux ? Although gfortran has progressed enormously the last
year or so, I still largely prefer the Sun F95 compiler on linux. Since Sun is
making the Sun Studio package free for linux users, I am surprised that I have
not read much about their F95 compiler on this forum.
Jinson...@gmail.com
> Jinsong.Z...@gmail.com wrote:
>
>
> It seems that your main observation is that -fno-automatic does not work as
> advertised with gfortran ? It also seems that sgk has trouble believing this. It
> would be nice if we could find a test case to demonstrate it.
>
Yes.
> Do you get the correct result with "SAVE"'s added to the code with both
> compilers ? (g77 and gfortran)
>
For the specific input file, added ``SAVE'' to the code will give
correct result with both compilers. Because it's a large old package,
I don't tested fully with different input files.
> Are you running linux ? Although gfortran has progressed enormously the last
> year or so, I still largely prefer the Sun F95 compiler on linux. Since Sun is
> making the Sun Studio package free for linux users, I am surprised that I have
> not read much about their F95 compiler on this forum.
Yes, I am running Linux, however, I don't install Sun Studio. I tested
Sun F95 once under a solaris workstation.
Tobias Burnus
wrote:
> > It seems that your main observation is that -fno-automatic does not work as
> > advertised with gfortran ? It also seems that sgk has trouble believing this. It
> > would be nice if we could find a test case to demonstrate it.
>
> Yes.
Indeed, a test case would be great. For a simple test, e.g.
subroutine foo()
integer :: i
i = 5
end
the option -fno-automatic works correctly. With default options, the -
fdump-tree-original looks as follows (this is a C-like representation
of the internal structure):
foo ()
{
integer(kind=4) i;
i = 5;
}
and with an explicit SAVE or with -fno-automatic it is as follows
(note the "static"):
static integer(kind=4) i;
Thus this part works.
One possibility would be to dump the tree (-fdump-tree-original) once
with -fno-automatic and once with manually added SAVE and check for
the differences; as manual SAVEs work and -fno-automatic doesn't there
should be differences in the dump.
Question: Does -fno-automatic with manually added SAVEs work? If not
it might be that too much is SAVEd instead of too little.
Tobias
dpb
> On Oct 14, 5:06 pm, JB <f...@bar.invalid> wrote:
>> On 2008-10-14, Jinsong.Z...@gmail.com <Jinsong.Z...@gmail.com> wrote:
>>
>> I think the question is, how do you know that the 'correct' result is
>> the correct one?
>
> I don't think it's a question. The code is old enough, and the result
> have been tested in a widely way. Thus I know the correct result.
That the code (apparently) relies on compiler switches and as you say
produces many warnings w/ ftnchek implies there's lots of room for even
an old code to have bugs.
Therefore, I wouldn't be so confident in presuming any answer you have
is the "correct result".
...
> I don't assume the differences is compiler bugs. I just confused by
> the same options provided by two compilers, and I think they should do
> the same thing. However, I may be fault.
Yes, you "may be" at fault w/ that assumption, too. You've been told
quite a number of times that you're comparing to different compilers
with completely different implementations and to presume that they are
identical in behavior with regards to how they implement a
_NON_Standard-specified switch is simply an unjustified (and
unjustifiable) assumption.
...
>> Fixing these warnings is probably a good start if you wish g77 and
>> gfortran to produce the same and hopefully correct results.
...
Yes. Fixing the code so that it doesn't rely on such switches is a very
good objective and has at least a reasonable chance of producing an
executable that operates the same w/ both compilers.
--
Jinson...@gmail.com
>
> One possibility would be to dump the tree (-fdump-tree-original) once
> with -fno-automatic and once with manually added SAVE and check for
> the differences; as manual SAVEs work and -fno-automatic doesn't there
> should be differences in the dump.
Thank you for your suggestion, and I will try to do it later.
>
> Question: Does -fno-automatic with manually added SAVEs work? If not
> it might be that too much is SAVEd instead of too little.
>
Yes, it works with -fno-automatic and manually added SAVEs.
Jinsong
Steven G. Kargl
user1 <us...@example.net> writes:
> Jinson...@gmail.com wrote:
>>
>> if added ``SAVE'', -fno-automatic is not necessary for both gfortran
>> and g77. It indicated that -fno-automatic in gfortran do the different
>> thing and not like what said in the manpage.
>>
>
> It seems that your main observation is that -fno-automatic does not work as
> advertised with gfortran ? It also seems that sgk has trouble believing this. It
> would be nice if we could find a test case to demonstrate it.
>
I'm not having trouble believing that a difference exists. What
I've asked for and Jinsong has yet to provide is to actually see
what the difference is. If the "correct answer" is 1.234567 and g77
give this number and gfortran gives 1.234566, then there isn't
a difference (assuming default real kind). The last digit isn't
significant.
Jinsong has already stated that ftnchek reveals hundreds of warnings.
I'm guessing we'll find a boat load of stupid user tricks such as
use of uninitialized variables (clearly, a problem!), equivalence abuse,
comparison of FP values for equality, single precision literal constants
instead of double precision, type mismatch of actual and dummy arguments,
etc.
I'll also note that after Jinsong offered to send the code to anyone
interested and I responded to the offer, I still haven't seen the code :(
--
steve
user1
> In article <gd1vrk$hss$1...@registered.motzarella.org>,
> user1 <us...@example.net> writes:
>> Jinson...@gmail.com wrote:
>>> if added ``SAVE'', -fno-automatic is not necessary for both gfortran
>>> and g77. It indicated that -fno-automatic in gfortran do the different
>>> thing and not like what said in the manpage.
>>>
>> It seems that your main observation is that -fno-automatic does not work as
>> advertised with gfortran ? It also seems that sgk has trouble believing this. It
>> would be nice if we could find a test case to demonstrate it.
>>
>
> I'm not having trouble believing that a difference exists. What
> I've asked for and Jinsong has yet to provide is to actually see
> what the difference is. If the "correct answer" is 1.234567 and g77
> give this number and gfortran gives 1.234566, then there isn't
> a difference (assuming default real kind). The last digit isn't
> significant.
>
Perhaps Jinsong can tell us more about the differences he seees.
I'd wager that it is more like a NaN or Inf instead of 1.234567, or a
hard crash. That's the kind of stuff I got when trying to build the F90
version of mopac unsucessfully with gfortran, discussed in a previous
thread.
( Btw, I now have successful builds of F90 mopac with the Sun and Intel
compilers. )
Richard Maine
> I'm not having trouble believing that a difference exists. What
> I've asked for and Jinsong has yet to provide is to actually see
> what the difference is. If the "correct answer" is 1.234567 and g77
> give this number and gfortran gives 1.234566, then there isn't
> a difference (assuming default real kind). The last digit isn't
> significant.
Yes. I think mostly this isn't going is get resolved without someone
actually looking at the specific code (and the results). There is far to
much generalization here. To add more to that generalization... :-(
Many kinds of things should not show up as differences between the
compiler switches and explicit SAVE. Since explicit SAVE allegedly gets
the "right" results, that would seem to majorly narrow the search. I
wouldn't expect that to cause rounding differences, for example. Sure, I
could be wrong, but it wouldn't be high on my list. A bug in the
implementation of -fno-automatic is one possibility that has been
mentioned. That isn't the only possibility consistent with the (very
meager) data, however.
For example, if there is any recursion (nonstandard in f77, but some
codes use it anyway), explicit SAVE might well be validly different from
the compiler switch. Odds of that seem a bit low for several reasons,
but probably not zero.
But mostly, I am just noting how futile the thread is. I don't think it
is going anywhere useful until actual code and results are shown. Yes, I
read the reasons why it isn't. Nonetheless, without it, I don't think
there are going to be useful answers.
Phillip Helbig---remove CLOTHES to reply
nos...@see.signature (Richard Maine) writes:
> Steven G. Kargl <ka...@REMOVE.apl.washington.edu> wrote:
>
> > I'm not having trouble believing that a difference exists. What
> > I've asked for and Jinsong has yet to provide is to actually see
> > what the difference is. If the "correct answer" is 1.234567 and g77
> > give this number and gfortran gives 1.234566, then there isn't
> > a difference (assuming default real kind). The last digit isn't
> > significant.
>
> Many kinds of things should not show up as differences between the
> compiler switches and explicit SAVE. Since explicit SAVE allegedly gets
> the "right" results, that would seem to majorly narrow the search. I
> wouldn't expect that to cause rounding differences, for example. Sure, I
> could be wrong, but it wouldn't be high on my list.
I haven't been following this thread, so the following might be
worthless.
Presumably, the code should produce the same results with and without
SAVE, but there is a difference in the last digit, which looks like a
rounding issue. (If not, stop reading here.)
Here is a general question perhaps related to the above. If I
initialise a variable at the declaration and then SAVE it (initialising
it now implies SAVE, right?), this is in some way distinct from an
assignment statement with the same value. Could the different ways
these are handled lead to rounding issues, perhaps involving implicit
conversion (whether required/allowed by the standard or not)?
Richard Maine
<hel...@astro.multiCLOTHESvax.de> wrote:
> Presumably, the code should produce the same results with and without
> SAVE, but there is a difference in the last digit, which looks like a
> rounding issue. (If not, stop reading here.)
No, there was no suggestion of that being the case. That was only an
example that Steve gave of something that wouldn't count as a
difference.
> Here is a general question perhaps related to the above. If I
> initialise a variable at the declaration and then SAVE it (initialising
> it now implies SAVE, right?), this is in some way distinct from an
> assignment statement with the same value. Could the different ways
> these are handled lead to rounding issues, perhaps involving implicit
> conversion (whether required/allowed by the standard or not)?
Basically, no.
glen herrmannsfeldt
(snip)
> Here is a general question perhaps related to the above. If I
> initialise a variable at the declaration and then SAVE it (initialising
> it now implies SAVE, right?), this is in some way distinct from an
> assignment statement with the same value. Could the different ways
> these are handled lead to rounding issues, perhaps involving implicit
> conversion (whether required/allowed by the standard or not)?
There are cases where compile time expression evaluation gives
different results from run time evaluation. There are a variety
of reasons that can happen. Add it to the list of reasons not
to compare floating point values for equality.
(The first one I saw was a failed attempt to find the pentium
FDIV bug, when the test expression was evaluated at compile
time without using the floating point instructions.)
-- glen
Jinson...@gmail.com
wrote:
>
> I'm not having trouble believing that a difference exists. What
> I've asked for and Jinsong has yet to provide is to actually see
> what the difference is. If the "correct answer" is 1.234567 and g77
> give this number and gfortran gives 1.234566, then there isn't
> a difference (assuming default real kind). The last digit isn't
> significant.
No, it's not about digit.
>
> I'll also note that after Jinsong offered to send the code to anyone
> interested and I responded to the offer, I still haven't seen the code :(
>
i send the code to you yesterday, however, I may get a error address
from your post. if you did not receive it yet, please send your email
address to my mailbox as my post displayed. i will sent the code to
you as soon as possible.
Thanks again,
Jinsong
James Van Buskirk
news:1ioslu7.1fa4bkl1gwmcteN%nos...@see.signature...
> For example, if there is any recursion (nonstandard in f77, but some
> codes use it anyway), explicit SAVE might well be validly different from
> the compiler switch. Odds of that seem a bit low for several reasons,
> but probably not zero.
I tried a few possibilities:
C:\gfortran\clf\mystery>type mystery.f90
module mod1
implicit none
private t1
type t1
real :: x = 3.0
end type t1
contains
! Recursive procedure
recursive function fun1a(x)
real x,y,fun1a
fun1a = y
y = x
end function fun1a
recursive function fun1b(x)
save
real x,y,fun1b
fun1b = y
y = x
end function fun1b
! User-defined type with default initialization
function fun2a(x)
real x,fun2a
type(t1) y
fun2a = y%x
y = t1(x)
end function fun2a
function fun2b(x)
real x,fun2b
type(t1) y
save
fun2b = y%x
y = t1(x)
end function fun2b
! Allocatable local variable
function fun3a(x)
real x,fun3a
real, allocatable :: y(:)
if(allocated(y)) then
fun3a = 1
deallocate(y)
else
fun3a = 2
end if
allocate(y(nint(x)))
y = 42
end function fun3a
function fun3b(x)
real x,fun3b
real, allocatable :: y(:)
save
if(allocated(y)) then
fun3b = 1
deallocate(y)
else
fun3b = 2
end if
allocate(y(nint(x)))
y = 42
end function fun3b
! Automatic data object
function fun4a(x)
real x,fun4a
real y(nint(exp(3.0)))
! real y(minval([nint(exp(3.0))]))
fun4a = y(1)
y = x
end function fun4a
function fun4b(x)
real x,fun4b
real y(nint(exp(3.0)))
! real y(minval([nint(exp(3.0))]))
save
fun4b = y(1)
y = x
end function fun4b
end module mod1
program test
use mod1
implicit none
real x
x = 1
x = fun1a(x)+fun1b(x)
x = 2
write(*,'(3(a,f0.0))') 'x = ', x, ', fun1a(x) = ', fun1a(x), &
', fun1b(x) = ', fun1b(x)
x = 1
x = fun2a(x)+fun2b(x)
x = 2
write(*,'(3(a,f0.0))') 'x = ', x, ', fun2a(x) = ', fun2a(x), &
', fun2b(x) = ', fun2b(x)
x = 1
x = fun3a(x)+fun3b(x)
x = 2
write(*,'(3(a,f0.0))') 'x = ', x, ', fun3a(x) = ', fun3a(x), &
', fun3b(x) = ', fun3b(x)
x = 1
x = fun4a(x)+fun4b(x)
x = 2
write(*,'(3(a,f0.0))') 'x = ', x, ', fun4a(x) = ', fun4a(x), &
', fun4b(x) = ', fun4b(x)
end program test
C:\gfortran\clf\mystery>gfortran -fno-automatic -std=f95
mystery.f90 -omystery
C:\gfortran\clf\mystery>mystery
x = 2., fun1a(x) = ., fun1b(x) = 1.
x = 2., fun2a(x) = 3., fun2b(x) = 1.
x = 2., fun3a(x) = 1., fun3b(x) = 1.
x = 2., fun4a(x) = 1., fun4b(x) = 1.
The first line of output looks like an I/O bug. It's rather surprising
that -fno-automatic implies SAVE of allocatables but not user-defined
types with default initialization. I didn't find that out from the
documentation. The automatic data object stuff seems especially
problematic. As written, y should be an automatic data object in
f95 since its shape is given by a specification expression which is
not an initialization expression. Switching to f03:
! Automatic data object
function fun4a(x)
real x,fun4a
! real y(nint(exp(3.0)))
real y(minval([nint(exp(3.0))]))
fun4a = y(1)
y = x
end function fun4a
function fun4b(x)
real x,fun4b
! real y(nint(exp(3.0)))
real y(minval([nint(exp(3.0))]))
save
fun4b = y(1)
y = x
end function fun4b
We get:
C:\gfortran\clf\mystery>gfortran -fno-automatic -std=f2003
mystery.f90 -omystery
mystery.f90: In function 'fun4b':
mystery.f90:85: internal compiler error: in gfc_trans_auto_array_allocation,
at
fortran/trans-array.c:4078
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Getting rid of the SAVE works,
! Automatic data object
function fun4a(x)
real x,fun4a
! real y(nint(exp(3.0)))
real y(minval([nint(exp(3.0))]))
fun4a = y(1)
y = x
end function fun4a
function fun4b(x)
real x,fun4b
! real y(nint(exp(3.0)))
real y(minval([nint(exp(3.0))]))
! save
fun4b = y(1)
y = x
end function fun4b
end module mod1
C:\gfortran\clf\mystery>gfortran -fno-automatic -std=f2003
mystery.f90 -omystery
C:\gfortran\clf\mystery>mystery
x = 2., fun1a(x) = ., fun1b(x) = 1.
x = 2., fun2a(x) = 3., fun2b(x) = 1.
x = 2., fun3a(x) = 1., fun3b(x) = 1.
x = 2., fun4a(x) = 1., fun4b(x) = 2.
But notice that the two identical functions now have different
outputs!
Note: this is an old version of gfortran:
C:\gfortran\clf\mystery>gfortran -v
Built by Equation Solution (http://www.Equation.com).
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../gcc-4.4-20080613-mingw/configure --host=x86_64-pc-mingw32 --
build=x86_64-unknown-linux-gnu --target=x86_64-pc-mingw32 --prefix=/home/gfortra
n/gcc-home/binary/mingw32/native/x86_64/gcc/4.4-20080613 --with-gmp=/home/gfortr
an/gcc-home/binary/mingw32/native/x86_64/gmp --with-mpfr=/home/gfortran/gcc-home
/binary/mingw32/native/x86_64/mpfr --with-sysroot=/home/gfortran/gcc-home/binary
/mingw32/cross/x86_64/gcc/4.4-20080613 --with-gcc --with-gnu-ld --with-gnu-as
--
disable-shared --disable-nls --disable-tls --enable-languages=c,fortran --enable
-libgomp --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.4.0 20080613 (experimental) (GCC)
Maybe newer versions behave differently.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Steven G. Kargl
user1 <us...@example.net> writes:
> Steven G. Kargl wrote:
>
> Perhaps Jinsong can tell us more about the differences he seees.
>
> I'd wager that it is more like a NaN or Inf instead of 1.234567, or a
> hard crash. That's the kind of stuff I got when trying to build the F90
> version of mopac unsucessfully with gfortran, discussed in a previous
> thread.
Well, mopac requires -fno-automatic and -finit-local-zero among
other options to compile with gfortran, so I'm willing to wager
that mopac could use some significant work. The adage, "Garbage
in, Garbage out," seems to apply to Jinsong's code and mopac.
--
steve
Dr Ivan D. Reid
wrote in <_v-dnU-IIaTcwWjV...@comcast.com>:
Can't speak to Jinsong's code, but last time I worked on MOPAC
it was still a mess of F77 and earlier. I'm not likely to go back to it,
I'm working at many orders of magnitude more energy these days... ;-)
It was a good benchmark, though -- optimising perylene (C20H12) from my
initial guess used to take exactly 20 minutes on a 80486-33 using MS-Fortran.
These days it's seconds on anything modern...
DUMP=20.0M T=2.0H pm3 pulay SHIFT=5.0 EF precise
Perylene
XX 0.0000000 0 0.000000 0 0.000000 0 0 0 0
XX 1.0000000 0 0.000000 0 0.000000 0 1 0 0
C 1.0000000 0 90.000000 0 0.000000 0 1 2 0 0.0390
C 1.4000000 1 60.000000 0 0.000000 1 3 1 2 -0.0844
C 1.4000000 1 120.000000 1 0.000000 1 4 3 1 -0.0445
C 1.4000000 1 120.000000 1 0.000000 1 5 4 3 -0.0727
C 1.4000000 1 120.000000 1 0.000000 1 6 5 4 -0.0619
C 1.4000000 1 120.000000 1 0.000000 1 7 6 5 -0.1305
C 1.4000000 1 120.000000 1 180.000000 1 3 4 5
C 1.4000000 1 120.000000 1 0.000000 1 9 3 4
C 1.4000000 1 120.000000 1 0.000000 1 10 9 3
C 1.4000000 1 120.000000 1 0.000000 1 11 10 9
C 1.4000000 1 120.000000 1 180.000000 1 8 7 6
C 1.4000000 1 120.000000 1 0.000000 1 13 8 7
C 1.4000000 1 120.000000 1 0.000000 1 14 13 8
C 1.4000000 1 120.000000 1 0.000000 1 15 14 13
C 1.4000000 1 120.000000 1 180.000000 1 5 4 3
C 1.4000000 1 120.000000 1 0.000000 1 17 5 4
C 1.4000000 1 120.000000 1 0.000000 1 18 17 5
C 1.4000000 1 120.000000 1 180.000000 1 6 7 8
C 1.4000000 1 120.000000 1 0.000000 1 20 6 7
C 1.4000000 1 120.000000 1 0.000000 1 21 20 6
H 1.1000000 1 120.000000 1 180.000000 1 9 3 4
H 1.1000000 1 120.000000 1 180.000000 1 10 9 3
H 1.1000000 1 120.000000 1 180.000000 1 11 10 9
H 1.1000000 1 120.000000 1 180.000000 1 13 8 7
H 1.1000000 1 120.000000 1 180.000000 1 14 13 8
H 1.1000000 1 120.000000 1 180.000000 1 15 14 13
H 1.1000000 1 120.000000 1 180.000000 1 17 5 4
H 1.1000000 1 120.000000 1 180.000000 1 18 17 5
H 1.1000000 1 120.000000 1 180.000000 1 19 18 17
H 1.1000000 1 120.000000 1 180.000000 1 20 6 7
H 1.1000000 1 120.000000 1 180.000000 1 21 20 6
H 1.1000000 1 120.000000 1 180.000000 1 22 21 20
--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
Tobias Burnus
> x = 2., fun1a(x) = ., fun1b(x) = 1.
>
I filled a bugreport (PR 37834).
> It's rather surprising
> that -fno-automatic implies SAVE of allocatables but not user-defined
> types with default initialization.
Indeed and "ifort -save" and NAG "f95 -save" also do this.
(Actually, the SAVE is implied but afterwards the default
initialization happens unconditionally again.)
I filled PR 37835.
I currently don't have to time to look at the other items, I'll do so
later.
Tobias
Ken.Fa...@gmail.com
While this is an interesting piece of code,
in some respects, in both fun1a/fun1b and
fun4a/fun4b, you reference y before it has
been defined, no? So did you really have
any expectations on what the output should
be?? I didn't see any flag to initialize
local variables to zero or similar.
(Granted the one I/O bug...)
-Ken
glen herrmannsfeldt
> On Oct 14, 7:53 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:
(snip)
>>! Recursive procedure
>> recursive function fun1a(x)
>> real x,y,fun1a
>>
>> fun1a = y
>> y = x
>> end function fun1a
>> recursive function fun1b(x)
>> save
>> real x,y,fun1b
>>
>> fun1b = y
>> y = x
>> end function fun1b
(snip)
>> x = 1
>> x = fun1a(x)+fun1b(x)
>> x = 2
>> write(*,'(3(a,f0.0))') 'x = ', x, ', fun1a(x) = ', fun1a(x), &
>> ', fun1b(x) = ', fun1b(x)
(snip)
>>C:\gfortran\clf\mystery>gfortran -fno-automatic -std=f95
>>mystery.f90 -omystery
>>C:\gfortran\clf\mystery>mystery
>>x = 2., fun1a(x) = ., fun1b(x) = 1.
>>x = 2., fun2a(x) = 3., fun2b(x) = 1.
>>x = 2., fun3a(x) = 1., fun3b(x) = 1.
>>x = 2., fun4a(x) = 1., fun4b(x) = 1.
(snip)
> While this is an interesting piece of code,
> in some respects, in both fun1a/fun1b and
> fun4a/fun4b, you reference y before it has
> been defined, no? So did you really have
> any expectations on what the output should
> be?? I didn't see any flag to initialize
> local variables to zero or similar.
> (Granted the one I/O bug...)
Well, the first call references y before it has
been defined, but the returned value isn't used.
Technically, I suppose that is illegal, but the cases
where he prints the output are after y has been defined.
Unless the compiler optimizes out the first call to
fun1a and fun1b...
-- glen
Richard Maine
>
> Well, the first call references y before it has
> been defined, but the returned value isn't used.
>
> Technically, I suppose that is illegal, but the cases
> where he prints the output are after y has been defined.
I wouldn't call that a technicality. I'd say it was just plain illegal,
as much as anything else. One could technically apply "technically" to
any valid statement about the language, but I take the connotation to be
that this particular restriction doesn't really "count".
You can might well find compilers that will refuse to compile it. And
you might also find systems where it will abort at run-time
(particularly with maximum debugging options turned on.) I'd say those
make it quite a bit more than a technicality.
James Van Buskirk
news:212ec401-161f-41ff...@40g2000prx.googlegroups.com...
> On Oct 15, 4:53 am, "James Van Buskirk" <not_va...@comcast.net> wrote:
> > It's rather surprising
> > that -fno-automatic implies SAVE of allocatables but not user-defined
> > types with default initialization.
> Indeed and "ifort -save" and NAG "f95 -save" also do this.
> (Actually, the SAVE is implied but afterwards the default
> initialization happens unconditionally again.)
The description in my admittedly old version of ifort documentation
allows for different semantics for ifort /Qsave and gfortran
-fno-automatic. The former says only that it saves all variables in
static allocation except local variables within a recursive routine
and variables declare as AUTOMATIC. This is not the same as treating
every program unit except those marked as RECURSIVE as if the SAVE
statement were specified for every local variable and array
referenced in it. For example ifort leaves open the possibility
of reinitializing instances of user-defined types with default
initialization and gfortran does not. This on the one hand permits
standard-conforming code to behave the same way with /Qsave specified
whereas the change should be detectable for -fno-automatic but on
the other hand creates an ambiguity as to whether ifort actually does
leave the semantics of standard-conforming code intact as it doesn't
say whether it does or not in the documentation.
It might be useful for the gfortran team to compare with ifort and
determine whether they want to maintain semantics of standard-conforming
code before considering failure to change semantics to be a bug. Of
course the documentation would have to be rewritten if the decision
were made to change the behavior. Sometimes it's just so difficult to
rewrite the documentation that a documented bad behavior gets left
intact. For example in the original f90 standard, non-advancing I/O
was specified to advance on format reversion due to a carry-over from
f77 that had no non-advancing I/O. I imagine everyone tries to write
non-advancing I/O taking for granted that format reversion also does
not advance to the next record and indeed early f90 compilers behaved
in just this way. However the simply-worded standard says otherwise
and rather than fix this bug in the standard the compilers got 'fixed'
so that now format reversion is just useless in conjunction with non-
advancing I/O.
> I currently don't have to time to look at the other items, I'll do so
> later.
Thanks for taking the time to examine these issues, Tobias.
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>Well, the first call references y before it has
>>been defined, but the returned value isn't used.
>>Technically, I suppose that is illegal, but the cases
>>where he prints the output are after y has been defined.
> I wouldn't call that a technicality. I'd say it was just plain illegal,
> as much as anything else. One could technically apply "technically" to
> any valid statement about the language, but I take the connotation to be
> that this particular restriction doesn't really "count".
There may have been machines that wouldn't initialize the
parity bits if in such case, but most now don't even have
parity bits.
> You can might well find compilers that will refuse to compile it. And
> you might also find systems where it will abort at run-time
> (particularly with maximum debugging options turned on.) I'd say those
> make it quite a bit more than a technicality.
I agree with those. WATFIV will abort some at run time, though
I am not sure about this case. WATFIV has the interesting feature
that printing out uninitialized values doesn't abort but prints out
UUUUUUUUU (appropriate field width) instead. In the example given,
neither of those happened, though.
One could do something like:
! Recursive procedure
recursive function fun1a(x)
real x,y,fun1a
if(x.ne.999.) fun1a = y
y = x
end function fun1a
and call it the first time with 999. before the
call to actually set the appropriate value.
It isn't so obvious that this doesn't change what the
program was designed to test, though.
-- glen
James Van Buskirk
> I wouldn't call that a technicality. I'd say it was just plain illegal,
> as much as anything else. One could technically apply "technically" to
> any valid statement about the language, but I take the connotation to be
> that this particular restriction doesn't really "count".
> You can might well find compilers that will refuse to compile it. And
> you might also find systems where it will abort at run-time
> (particularly with maximum debugging options turned on.) I'd say those
> make it quite a bit more than a technicality.
The original context of the thread was gfortran -fno-automatic
-finit-local-zero. I was simply too lazy to type in the latter
switch into my command lines but I would have if I encountered some
kind of abort during compilation or execution. Given this switch
the code was legal within extensions. Now, if -fno-automatic tries
to give automatic data objects the SAVE attribute as in
subroutine sub(n)
integer n
real automatic_data_object(n)
end subroutine sub
that would be a problem but is not directly contradicted by the
gfortran documentation.
Gib Bogle
> But mostly, I am just noting how futile the thread is. I don't think it
> is going anywhere useful until actual code and results are shown. Yes, I
> read the reasons why it isn't. Nonetheless, without it, I don't think
> there are going to be useful answers.
>
I still maintain that the error is in line 6827. ;-)
Richard Maine
Yes, I had noticed and understood your reply. You appear to be saying
the same thing that I did, but you say it more concisely and elegantly.
:-)
Jan Vorbrüggen
> is going anywhere useful until actual code and results are shown. Yes, I
> read the reasons why it isn't. Nonetheless, without it, I don't think
> there are going to be useful answers.
Nah. His very first post included the output of both the g77 and
gfortran variants, and it was obvious from that that this is an
interative code, and that the process converges qualitatively
differently for the two versions. Quite consistent with SAVEd vs
non-SAVEd variables.
Jan
paul.rich...@gmail.com
> Indeed and "ifort -save" and NAG "f95 -save" also do this.
> (Actually, the SAVE is implied but afterwards the default
> initialization happens unconditionally again.)
> I filled PR 37835.
I just committed the fix for this on mainline gcc and will backport to
gcc-4.3 in a week.
Thanks to James and Tobias for condensing this problem.
Paul
Richard Maine
"fix".
Tobias Burnus <bur...@net-b.de> wrote:
> On Oct 15, 4:53 am, "James Van Buskirk" <not_va...@comcast.net> wrote:
> > It's rather surprising
> > that -fno-automatic implies SAVE of allocatables but not user-defined
> > types with default initialization.
>
> Indeed and "ifort -save" and NAG "f95 -save" also do this.
> (Actually, the SAVE is implied but afterwards the default
> initialization happens unconditionally again.)
> I filled PR 37835.
I'm not so convinced that this is surprising. I can see some sense to
it.
In the large majority of cases prior to the introduction of default
initialization, adding the SAVE attribute cannot change the meaning of
standard conforming code. Recursive procedures are the main exception;
they might even be the only one. Very recently I recall being surprised
by actually seeing an example that did not involve recursion... but I've
managed to forget the trick involved. I do recall it as the first
correct example of such a thing I had ever seen.
However, adding the SAVE attribute to an object with default
initialization can easily change the meaning of standard conforming
code.
Thus a command-line switch that SAVEs most variables is "innocuous" in
that it can make some nonstandard code work, but it doesn't break
standard-conforming code.
If, however, you make that switch apply to objects with default
initialization, you can break standard-conforming code, which is to say
that the compiler is non-conforming with that switch in those cases.
You might want to think a bit about whether that's really what you want.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
James Van Buskirk
> Tobias Burnus <bur...@net-b.de> wrote:
Yes, and this sort of consideration applies to PR 37836 as well:
if under the -std=gnu switch minval([nint(exp(3.0))]) is not
considered an initialization expression (for example because it
hasn't yet been implemented in gfortran's initialization expression
evaluator) then the empty SAVE statement shouldn't be applied to it
so that the example wouldn't create a problem.
I have had a little more fun with my example of
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/324af2e3b9af4e3f?hl=en
C:\gcc_mingw64a\clf\test_version>type test3.f90
module test_version
implicit none
private
public is_f2003_recursive
public is_f2003_default_initialization
public is_f2003_allocatable
type default_initialization_type
logical :: core = .FALSE.
end type default_initialization_type
type allocatable_component
integer, allocatable :: core(:)
end type allocatable_component
contains
function is_f2003_recursive()
logical is_f2003_recursive
integer aux_output
call aux1(1, aux_output)
is_f2003_recursive = aux_output > 1
end function is_f2003_recursive
recursive subroutine aux1(depth, output)
integer depth
integer output
integer test(int(1.0))
save
test = 0
if(depth > 0) then
call aux1(depth-1, output)
end if
test = test+1
output = test(1)
end subroutine aux1
function is_f2003_default_initialization()
logical is_f2003_default_initialization
call aux2(is_f2003_default_initialization)
call aux2(is_f2003_default_initialization)
end function is_f2003_default_initialization
subroutine aux2(result)
logical result
type(default_initialization_type) test(int(1.0))
save
result = test(1)%core
test = default_initialization_type(.TRUE.)
end subroutine aux2
function is_f2003_allocatable()
logical is_f2003_allocatable
call aux3(is_f2003_allocatable)
call aux3(is_f2003_allocatable)
end function is_f2003_allocatable
subroutine aux3(result)
logical result
type(allocatable_component) test(int(1.0))
save
result = allocated(test(1)%core)
if(.NOT. allocated(test(1)%core)) then
allocate(test(1)%core(1))
end if
end subroutine aux3
end module test_version
program test
use test_version
implicit none
write(*,'(a)',advance='no') 'Test with recursive procedure: '
write(*,'(a)') trim(merge('Version is f2003', &
'Version is f95 ', &
is_f2003_recursive()))
write(*,'(a)',advance='no') 'Test with default initialization: '
write(*,'(a)') trim(merge('Version is f2003', &
'Version is f95 ', &
is_f2003_default_initialization()))
write(*,'(a)',advance='no') 'Test with allocatable component: '
write(*,'(a)') trim(merge('Version is f2003', &
'Version is f95 ', &
is_f2003_allocatable()))
end program test
C:\gcc_mingw64a\clf\test_version>x86_64-pc-mingw32-gfortran
test3.f90 -otest3
C:\gcc_mingw64a\clf\test_version>test3
Test with recursive procedure: Version is f2003
Test with default initialization: Version is f2003
Test with allocatable component: Version is f2003
I wanted to test this with -std=f95 but gfortran then refused the
part with allocatable components. I couldn't find a switch that
enforces f95 + TR 15881. As explained earlier gfortran fails the
test with only the recursive procedure with -std=f95 as does ifort
with /stand:f95 and I suspect most compilers can be made to fail
similar tests. It seems that an empty SAVE statement is quite a
loose cannon, just as much as compiler switches that sort of give
almost every program unit almost the equivalent of an empty SAVE
statement.
This seems to me to be a problem with the Fortran standard that
hasn't been very deeply explored as yet and in fact is virtually
unfixable. Even to instrument a compiler to detect borderline
cases and issue a warning would be difficult if the compiler
considered that accepting some specification expressions as
initialization expressions was a harmless extension.
A user probably wouldn't want to create a borderline case if he
had an inkling of the issues involved so a warning would be a
good thing, but it might be too expensive for the vendor to do it.