Prev: Intel Fortran compiler for Windows crashing
Next: Are f.p. manipulation functions only used in initialization?
From: qquito on 4 May 2008 14:26
Dear Everyone:

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


From: Thomas Koenig on 4 May 2008 14:29
On 2008-05-04, qquito <qquito(a)hotmail.com> wrote:

> 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)
From: Gordon Sande on 4 May 2008 14:42
On 2008-05-04 15:26:35 -0300, qquito <qquito(a)hotmail.com> said:

> Dear Everyone:
>
> 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

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.






From: qquito on 4 May 2008 16:25
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...(a)worldnet.att.net> wrote:
> On 2008-05-04 15:26:35 -0300, qquito <qqu...(a)hotmail.com> said:
>
> 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.

From: jamesgiles on 4 May 2008 17:01
On May 4, 12:42 pm, Gordon Sande <g.sa...(a)worldnet.att.net> wrote:
> On 2008-05-04 15:26:35 -0300, qquito <qqu...(a)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
 |  Next  |  Last
Pages: 1 2
Prev: Intel Fortran compiler for Windows crashing
Next: Are f.p. manipulation functions only used in initialization?