Prev: Fortran 77 parser
Next: The structure contains one or more misaligned fields
From: relaxmike on 4 Apr 2008 10:40
Hi fortran gurus !

After several hours of head-scratching, I found a strange behaviour
of my fortran compilers against arrays of size 0.
I reduced the problem to the source code below.

In fortran 90, one can allocate an array with a size of 0.
What I understand is that, on this zero-size array,
the "allocated" intrinsic answers "T" and the "size" intrinsic answers
0.
In my case, this situation appears because of a recursive function,
because the algorithm is based on a "divide and conquer" method.
What I do not understand is why the zero-size array of the following
code appears to be un-allocated only with gfortran compiler,
although I know that it really is allocated !

module testmod
type, public :: t_type
character(LEN=1), dimension(:), allocatable :: chars
end type t_type
contains
recursive function recursivefunc ( this ) result ( match )
type(t_type), intent(in) :: this
type(t_type) :: subpattern
logical :: thisalloc
integer :: thislength
logical :: match
thisalloc = allocated ( this % chars )
if ( .NOT. thisalloc ) then
write ( 6 , * ) "STOP with error !"
stop
endif
thislength = size ( this % chars )
if ( thislength == 0 ) then
match = .true.
return
endif
allocate ( subpattern % chars (0) )
match = recursivefunc ( subpattern )
end function recursivefunc
end module testmod

program testprog
use testmod
implicit none
type(t_type) :: this
logical :: match
allocate ( this % chars ( 10 ))
match = recursivefunc ( this )
print * , "match :", match
end program testprog

What I don't understand is that my code does not behave the
same with g95, gfortran and IVF 8.0.
With gfortran :

> gfortran test.f90 -o test.exe
> test.exe
STOP with error !

With g95 :

> g95 test.f90 -o test.exe
> test.exe
match : T

Intel Visual Fortran 8 exhibits the same behaviour as g95.

In fact, I don't really known what the fortran 90 standard says about
0-size arrays ?

Any help will be appreciated.

Best regards,

Michaël
From: Tobias Burnus on 4 Apr 2008 11:26
On Apr 4, 4:40 pm, relaxmike <michael.bau...(a)gmail.com> wrote:
> In fortran 90, one can allocate an array with a size of 0.
> What I understand is that, on this zero-size array,
> the "allocated" intrinsic answers "T" and the "size" intrinsic answers 0.
Yep.

> With gfortran :
> > gfortran test.f90 -o test.exe
> > test.exe
> STOP with error !

That is a known bug, which is unfortunately not yet fixed.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35719

* * *

Somehow, it is quite easy to run into compiler bugs with Fortran. A
colleague of mine, coming from computer science and being a friend of
C once complained: With C, if the compiler complains, it is a bug in
the program -- with Fortran one never knows whether it is bug in the
program or in the compiler. He continued then that it is not seldom to
encounter an internal compiler error with Fortran compilers, while it
is much harder to encounter one with C compilers.

I have to admit that this unfortunately matches my experience. I don't
know whether it is because of more high-level features (array
assignments etc.) or due to the smaller user base, or because he and I
are biased, but I really dislike the hacks one has to do in order to
work around compiler bugs. (Checking via a "./configure" script
whether a feature like, e.g., type(c_ptr) work is one thing, but
whether it really works or an internal compiler error is produced with
the big program, is another thing.)

(Another thing I dislike is clumsy code because of compilers which
still do not support all Fortran 95 features.)

Tobias,
who uses Fortran in physics and who works on the gfortran compiler as
hobby
From: James Van Buskirk on 4 Apr 2008 12:15
"Tobias Burnus" <burnus(a)net-b.de> wrote in message
news:9d7af86f-e21e-4ae5-8b81-ec639a68a855(a)m3g2000hsc.googlegroups.com...

> Somehow, it is quite easy to run into compiler bugs with Fortran. A
> colleague of mine, coming from computer science and being a friend of
> C once complained: With C, if the compiler complains, it is a bug in
> the program -- with Fortran one never knows whether it is bug in the
> program or in the compiler. He continued then that it is not seldom to
> encounter an internal compiler error with Fortran compilers, while it
> is much harder to encounter one with C compilers.

The obvious problem is the size of the language. It got bigger from
f77 to f90, from f90 to f95, and from f95 to f03. The increase in
size from f90 to f95 is often underestimated by those who haven't
tried to make f95 compilers work on specification expressions.
Although I like the new features and try to use them as they become
available, I worry that they just make it too expensive to write
an f03 compiler and that they tend to go against the grain of what
used to be the Fortran culture of handing the new kid a Fortran
manual and telling him to bootstrap himself to being a Fortran
programmer. It was a very common practice in the f66 and f77 days,
but starting with f90 there are more possibilities of indirect ideas
that take more subtlety of though to be able to use successfully or
even to understand why they are there in the language in the first
place. I worry that Fortran is taking a road towards being a
language that's expensive to write a compiler for and requires
expensive training to be able to really use its features and yet is
still denigrated by CS types (CS majors really are taught that
Fortran is FORTRAN 77 and to scoff at the mere mention of the
language.)

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


From: glen herrmannsfeldt on 4 Apr 2008 12:41
Tobias Burnus wrote:
(snip)

> Somehow, it is quite easy to run into compiler bugs with Fortran. A
> colleague of mine, coming from computer science and being a friend of
> C once complained: With C, if the compiler complains, it is a bug in
> the program -- with Fortran one never knows whether it is bug in the
> program or in the compiler. He continued then that it is not seldom to
> encounter an internal compiler error with Fortran compilers, while it
> is much harder to encounter one with C compilers.

K&R C and C89 are fairly simple languages. C99 seems to be
significantly more complicated, but still relatively simple.
Much of the work for C is done in the library, though optimizing
compilers may optimize some library calls.

Internal compiler errors in C compilers are likely fairly rare
Some other problems, such as optimizer bugs generating the
wrong code, might be less rare, but also less visible.

-- glen

From: Gordon Sande on 4 Apr 2008 13:21
On 2008-04-04 12:26:22 -0300, Tobias Burnus <burnus(a)net-b.de> said:

> On Apr 4, 4:40 pm, relaxmike <michael.bau...(a)gmail.com> wrote:
>> In fortran 90, one can allocate an array with a size of 0.
>> What I understand is that, on this zero-size array,
>> the "allocated" intrinsic answers "T" and the "size" intrinsic answers 0.
> Yep.
>
>> With gfortran :
>>> gfortran test.f90 -o test.exe
>>> test.exe
>> STOP with error !
>
> That is a known bug, which is unfortunately not yet fixed.
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35719
>
> * * *
>
> Somehow, it is quite easy to run into compiler bugs with Fortran. A
> colleague of mine, coming from computer science and being a friend of
> C once complained: With C, if the compiler complains, it is a bug in
> the program -- with Fortran one never knows whether it is bug in the
> program or in the compiler. He continued then that it is not seldom to
> encounter an internal compiler error with Fortran compilers, while it
> is much harder to encounter one with C compilers.
>
> I have to admit that this unfortunately matches my experience. I don't
> know whether it is because of more high-level features (array
> assignments etc.) or due to the smaller user base, or because he and I
> are biased, but I really dislike the hacks one has to do in order to
> work around compiler bugs. (Checking via a "./configure" script
> whether a feature like, e.g., type(c_ptr) work is one thing, but
> whether it really works or an internal compiler error is produced with
> the big program, is another thing.)
>
> (Another thing I dislike is clumsy code because of compilers which
> still do not support all Fortran 95 features.)

Can one ask, and hope for a straight answer, whether these are commercial
Fortran compilers or not?

The observation is that GCC is probably quite heavily used but that Gfortran
and G95 and much less well exercised. There is considerable less development
effort spent on the Fortran components of GCC than on the C related components.
If I understand it many of the GGC C developers are in fact full time
professional compiler writers paid by their organizations to contribute to
GCC while the Fortran components are being done by volunteers (as a hobby
like the signature below).

At one time the claim was that Fortran compilers had been "polished optically
flat" because of their demanding users. That would have been in the
days of F77.

> Tobias,
> who uses Fortran in physics and who works on the gfortran compiler as
> hobby


 |  Next  |  Last
Pages: 1 2 3
Prev: Fortran 77 parser
Next: The structure contains one or more misaligned fields