Treacherous Behavior of "gfortran" Compiler?
qquito
I use a "Power Mac G5", and "gfortran" compiler for my Fortran 90
codes. (The same compiler also compiles Fortran 95 and 03.)
Recently on two occasions, I attempted to treat the size of an array
as larger than it was defined at the beginning of my Fortran 90 code.
(This was a long code and was modified from an earlier one, and there
were many arrays whose sizes were defined by parameters given in the
same code, so the problem was not easily spotted simply by viewing the
source code.) In other words, it is like
..........................................
integer, parameter:: max=10
real:: a(max)
integer:: i
do i=1, 50
a(i)=float(i)*100.0
enddo
..........................................
The problem is that the "gfortran" compiler does NOT give me any error
information, nor do I get any error message when I run the job. It is
only when I look at the output data files that I notice the messy and
apparently wrong results. It took me quite a few attempts to find out
the problem.
Has anyone had similar problems? Is there anyway to let the "gfortran"
compiler report this problem?
Thank you for reading and replying!
--Roland
Thomas Koenig
> The problem is that the "gfortran" compiler does NOT give me any error
> information, nor do I get any error message when I run the job.
$ cat > foo.f90
integer, parameter:: max=10
real:: a(max)
integer:: i
do i=1, 50
a(i)=float(i)*100.0
enddo
end
$ gfortran -fbounds-check foo.f90
$ ./a.out
At line 7 of file foo.f90
Fortran runtime error: Array reference out of bounds for array 'a',
upper bound of dimension 1 exceeded (11 > 10)
Gordon Sande
It is not a bug as it is a feature. Not only of gfortran but of almost every
other Fortran since year zero. It is called efficient execution.
However most fortrans also have an ability to check subscripts. It just
requires that you enable the option.
The exceptions are a very few "student debugging" compilers which have the
option fixed on. They tend to have fast compilation to rather inefficient
generated code. For the typical Fortran application that would be a
source of major criticism.
In your case you need to RTFM. Not now but RIGHT NOW! The option and
several others will be there. There are other debugging options also
avaiable on many. But you need to RTFM. In case you do not catch the
drift I am suggesting that you learn to use the tool before complaining
about it.
qquito
option solves my problem. And I will definitely study the "gfortran"
manual to learn more about the compiler.
james...@att.net
> On 2008-05-04 15:26:35 -0300, qquito <qqu...@hotmail.com> said:
> > ..........................................
> > integer, parameter:: max=10
> > real:: a(max)
>
> > integer:: i
>
> > do i=1, 50
> > a(i)=float(i)*100.0
> > enddo
> > ..........................................
>
> > The problem is that the "gfortran" compiler does NOT give me any error
> > information, nor do I get any error message when I run the job. It is
> > only when I look at the output data files that I notice the messy and
> > apparently wrong results. It took me quite a few attempts to find out
> > the problem.
>
> > Has anyone had similar problems? Is there anyway to let the "gfortran"
> > compiler report this problem?
...
> It is not a bug as it is a feature. Not only of gfortran but of almost
> every other Fortran since year zero. It is called efficient execution.
>
> However most fortrans also have an ability to check subscripts. It just
> requires that you enable the option.
>
> The exceptions are a very few "student debugging" compilers which have the
> option fixed on. They tend to have fast compilation to rather inefficient
> generated code. For the typical Fortran application that would be a
> source of major criticism.
Well, that's not quite true anymore. In fact, not for quite a while.
In this case, the error can (and should) be caught at compile time.
And certainly all modern compilers should be able to move the proper
run-time test out of the loop where it will hardly be noticed. Sure,
it's possible to contrive examples of code where the run-time test is
still part of heavily executed code. And, sure, things it's possible
to contrive sometimes actually show up in real code. But unless you
have clear evidence that bounds checking is your bottleneck, it's
probably better to leave it on.
One thing that would occasionally be nice is some compiler directive
that selectively turned off bounds checking for just one statement.
Or, maybe even just one array for that one statement. Or (more
rarely) throughout the code for one array.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
Ron Ford
I finally realize what Gordon means when he uses this expression. He
means, read the Fortran manual. A good look at the language and good
documentation are here:
http://gcc.gnu.org/wiki/GFortran
I think you've got a second problem in that you impugned gfortran of
"treachery." Then the F might be FX Flipping out.
If you bother to familiarize yourself with gfortran.pdf, it might go a long
way to smoothing over such snafus.
--
Ron Ford
"Rush Limbaugh is a big fat idiot."
Gordon Sande
> On Sun, 4 May 2008 13:25:23 -0700 (PDT), qquito wrote:
>
>> Thank you, Gordon and Thomas, for your replies! The "-fbounds-check"
>> option solves my problem. And I will definitely study the "gfortran"
>> manual to learn more about the compiler.
>>
>>
>> On May 4, 2:42 pm, Gordon Sande <g.sa...@worldnet.att.net> wrote:
>
>>> In your case you need to RTFM. Not now but RIGHT NOW! The option and
>>> several others will be there. There are other debugging options also
>>> avaiable on many. But you need to RTFM. In case you do not catch the
>>> drift I am suggesting that you learn to use the tool before complaining
>>> about it.
>
> I finally realize what Gordon means when he uses this expression. He
> means, read the Fortran manual. A good look at the language and good
> documentation are here:
> http://gcc.gnu.org/wiki/GFortran
RTFM => Read The Fine Manual*
is a common usenet shorthand. It usually means that the poster would have
gotten an answer with less effort if he/she/it had bothered with such an
old fashioned activity. On occasion there are folks who, for obscure
reasons, have been known to provide misleading answers that involve massive
detours and other "longcuts". And then there are the folks who confidently
give a wrong answer. But then you get what you pay for. The joys of the
internet.
*In the case of C the meaning clearly can not be Read The Fortran Manual.
Some folks believe that the F is for some other common expletive.
Dan Nagle
On 2008-05-05 08:12:04 -0400, Gordon Sande <g.s...@worldnet.att.net> said:
> RTFM => Read The Fine Manual*
> Some folks believe that the F is for some other common expletive.
I try to think of it as the emphatic tense.
--
Cheers!
Dan Nagle
Ron Ford
> *In the case of C the meaning clearly can not be Read The Fortran Manual.
That might be the exact meaning for someone who deserves better than the
horrible C programming language. C.l.f. discusses the topic of C better
than clc.
> Some folks believe that the F is for some other common expletive.
Fortran and fine are not expletives. Unless, next time I bump my head I
say, "Jesus Fortran Christ!" I would vote for the initialism meaning: read
the fetchin manual.
--
Ron Ford
Kurt Kallblad
"Ron Ford" <r...@nowhere.net> wrote in message
news:18sdttls2copj$.3dxhnjzfidwz.dlg@40tude.net...
Way not "the fat manual" looking at the growing size of the
standard.
Kurt
Ron Ford
> "Ron Ford" <r...@nowhere.net> wrote in message
> news:18sdttls2copj$.3dxhnjzfidwz.dlg@40tude.net...
>> [23 quoted lines suppressed]
>
> Way not "the fat manual" looking at the growing size of the
> standard.
>
> Kurt
I think it's much more the flavor of rtfm that there is some hard copy of a
fortran reference for your implementation which "you," as the subject of
the imperative sentence, do best to consult. The odds of such a manual
existing is inversely proportional to your distance from nasa.
The fortran standard is available for any interested party, which makes it
different than say, the C++ standard. I would claim that the standard
itself is completely out of scope until at least a first reading of MR&C.
I make every excuse I can to read the standard, usually starting in the
glossary till I figure where I go next. Many who post here have their
fingerprints all over it. It's abstract, unlike manuals.
--
Ron Ford