gfortran problem

"rudra" <bnrj.rudra@gmail.com> wrote in message
news:a8c03bf2-6445-4373-b3c3-96aa2c269c7d@e6g2000prf.googlegroups.com...

> dear friends, the problem is solved. i have found(i guess ) the
> apperent problem. in my coeff.f90, it is declared as:

> subroutine  coefficient(istart,lorbit,nrec,nsite,nma
x,nn,cmat,dmat)
>  real(8),dimension(nmax,lorbit)::h1,h2,h3


> etc

> when i changed  this array declaration to allocatable array, it is
> done.

> but can anyone plz tell me, even the declaration as above is
> completely valid, why it was giving error?

On a whole-array assignment to h1, h2, or h3, if the expr is not
conformable with the variable, the program is nonconforming and
if the Fortran processor is not capable of performing shape
matching, memory may be overwritten.  If h1, h2, and h3 are
declared ALLOCATABLE, they will be allocated or reallocated to
the conforming shape on whole-array assignment if they didn't
conform or weren't allocated before the assignment.

If you have any whole-array assignment statements with any of
these as the variable, print out the shape of the expr they are
assigned to and check to see if it is [nmax, lorbit] in each case.

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

On Wed, 2 Apr 2008 07:54:10 -0600, "James Van Buskirk" <not_valid@comcast.ne
t>
wrote:

> If h1, h2, and h3 are
>declared ALLOCATABLE, they will be allocated or reallocated to
>the conforming shape on whole-array assignment if they didn't
>conform or weren't allocated before the assignment.

This is a F2003 feature not supported by all compilers.  Intel Fortran DOES
support it, but you have to specify the /assume:realloc_lhs (-assume
realloc_lhs) option to get it, otherwise no automatic reallocation is done.

I touched upon this in a recent blog post
(http://softwareblogs.intel.com/2008...when-i-do-this/)

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/pe...cetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran

On Wed, 2 Apr 2008 10:13:47 -0600, "James Van Buskirk" <not_valid@comcast.ne
t>
wrote:

>I already sent that in to Paul.  The assignments to x1 and x2 look
>like they are sailing through just fine but the program dies on the
>first assignment to x in the memory leak test loop.  Does ifort like
>the above or is there some kind of problem with my code?

ifort doesn't seem to properly allocate the "parts" subcomponent.  We'll loo
k
into that.

>BTW, that /assume:realloc_lhs switch seems dopey to me.  The
>descriptor for the lhs array has to be touched to get the array's
>address, so all of the extents should be in cache.  Also if the code
>were valid with the switch not in force, then any branches executed
>in testing for shape matching ought to get really good prediction
>rates, no?  So then why should the test to check whether the lhs
>should be reallocated slow down the program appreciably?  I mean,
>more than a percent or two, and if Intel cared about performance
>gains of that size there are code transformations they could
>implement in less than a day that could get them that much.

It's potentially a lot of extra code, especially with nested types as in you
r
example, with lots of branches.  This can cause trouble for optimization. I'
ve
seen other customers praise us for making this an option.

>One observation I have made, inclusive of compilers in ifort's
>lineage, is that while core f77 operations may be almost reasonably
>optimized, the hidden operations required by f90 et seq. such as
>array copies, or here possibly shape matching, get implemented in
>a style that is almost as bad as interpreted code.  I speculate
>that the shape matching that ifort does in this case may be code
>that could be cleaned up a bit with overall throughput enhancement.
>If so the switch could be eliminated so that standard-conformance
>would be nearer in default settings.

It's certainly true that doing a good job optimizing "F90" constructs is not
 a
given in compilers, but compiler writers in general have learned how to do
this incrementally over time.  I'd make the generalization that new features
are not likely to be well optimized at first introduction, especially if the
y
don't match an existing idiom that the compiler already recognizes (for
example, loop fusion with array assignments.)

It's more important to us to get the behavior correct first, and worry about
optimization later.  We do think about performance initially as well, but
sometimes there is invention required to optimize a new construct and that
often comes later.  ifort, just as an example, does much better for
assignments of derived types with nested allocatable arrays now than it did
four years ago.

>For e.g., the following code:
>
>C:\gfortran\test\allocate_assign>type note7_35.f90
>program note7_35
>   implicit none
>   character, allocatable :: name*(:)
>
>Oops, maybe I got the syntax wrong a little there, but you recall
>the point of this note: the two lines of output should differ under
>the standard but would not if the /assume:realloc_lhs switch were
>not in effect.

I don't know about gfortran, but ifort doesn't yet support allocatable
character variables.  We're working on it.

One thing I am asking the ifort developers for is a single switch that says
"turn on all the options required for F2003 semantics".  Right now, you have
to throw a bunch of seemingly unrelated switches to do that.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/pe...cetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran

Steve Lionel wrote:
(someone wrote)
 

> It's potentially a lot of extra code, especially with nested types as in y
our
> example, with lots of branches.  This can cause trouble for optimization. 
I've
> seen other customers praise us for making this an option.

It might have been a mistake in Fortran 2003 to automatically do
reallocation on assignment.  It would have been more Fortran-like
to have to ask for it when needed.  Maybe in many cases the compiler
will figure out that it isn't needed, but not all.

I might not have minded something like

X=reallocate(A+B)

for a reallocating assignment, or maybe, in the spirit of pointer
assignment, a special assignment operator.

X <= A+B

or in the spirit of ALGOL:

X := A+B

(snip)
> It's certainly true that doing a good job optimizing "F90" constructs is n
ot a
> given in compilers, but compiler writers in general have learned how to do
> this incrementally over time.  I'd make the generalization that new featur
es
> are not likely to be well optimized at first introduction, especially if t
hey
> don't match an existing idiom that the compiler already recognizes (for
> example, loop fusion with array assignments.)

I have for some years now believed that compilers usually do about
as well as DO loops with simple array assignment, but often worse
than DO loops with more complicated array assignment.  Especially
the use of temporary arrays which may or may not be needed.
It seems that this might be less true as compilers get better.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> It might have been a mistake in Fortran 2003 to automatically do
> reallocation on assignment.  It would have been more Fortran-like
> to have to ask for it when needed.

That was debated quite actively in J3/WG5 when the decision was made. I
happen to agree with the way it came out. To me, that is part of what
makes variable-length strings in f2003 "just work" like people
intuitively expect (that is once compilers implement that part).

One point that I found convincing was that it was inconsistent and
confusing that without that feature, allocatables automatically
reallocated when they were allocatable components, but not when the
top-level object was allocatable.

There were lots of arguments as to why allocatable components
automatically reallocate. Without that, intrinsic assignment of objects
with allocatable components is pretty much unuseable. In any case, such
automatic allocation of components was already part of Fortran (via the
TR). So some of us thought that it would be rather un-Fortran-like to
make non-components act differently.

Of course, disagree if you like. I'm sure some other people also
disagree; some did at least at some points during the J3/WG5 debates. I
did want to point out, though, that this was extensively debated. It was
not just thrown in without discussion of the pros and cons.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

In-Reply-To: <1ierub7.9cizot7rvm5uN%nospam@see.signature>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: < H_6dne4A678Jn2nanZ2dnUVZWhednZ2d@comcast
.com>
Lines: 36
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 76.22.21.241
X-Trace: sv3- rVA8wXlJiykJmvsq0wvI1je4UsHksEtp+OlsOPsg
tjxAcCJnt32T7ysVh+MwpqE
lmYa1WggPKZF6R/p!cMTqNTxy/C+B8ABsX3KxoOZhXn3MQiT7K1UlFtB1/XIReyz6z5osy25zCJk
 7muxiuA5pmD036iGB!YqiCWMDN94RjVyhpL8Usqq
YVprIT
X-Complaints-To: abuse@comcast.net
X-DMCA-Complaints-To: dmca@comcast.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.38
Bytes: 3151
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:175560

Richard Maine wrote:

> glen herrmannsfeldt wrote:
 

> That was debated quite actively in J3/WG5 when the decision was made. I
> happen to agree with the way it came out. To me, that is part of what
> makes variable-length strings in f2003 "just work" like people
> intuitively expect (that is once compilers implement that part).

> One point that I found convincing was that it was inconsistent and
> confusing that without that feature, allocatables automatically
> reallocated when they were allocatable components, but not when the
> top-level object was allocatable.
(snip)

Realizing that it is not going to change, I might have suggested
the REALLOCATABLE attribute (which implies ALLOCATABLE) where
it would be automatic, and not for normal ALLOCATABLE.
Only two more letters to say you want the extra complications.
ALLOCATABLE components might then automatically have this
extra attribute.

I might also have allowed, for such variables, an ALLOCATE
without a DEALLOCATE that would copy the old data as appropriate.

Thanks for the historical notes.

The Fortran-like comment regarding features that slow down
programs even when the extra feature is not needed.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> I might also have allowed, for such variables, an ALLOCATE
> without a DEALLOCATE that would copy the old data as appropriate.

In which case, you would have to define what the "as appropriate" bit
meant. See prior posts in this forum for much argument about that. I'm
sure you could come up with one... but getting agreement on it is a
different matter. Whatever scheme you came up with would have some
people arguing that it was wrong.

The "interesting" cases are ones that have rank 2 or more, or where the
lower bound changes. Of course, one could try to just disallow such
cases, but then you'll find people disagreeing about that also.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Steve Lionel wrote:
 
>
> ifort doesn't seem to properly allocate the "parts" subcomponent.  We'll l
ook
> into that.

It turns out that the problem occurs only when the right-hand side
contains a structure constructor with allocatable array components in
the type.  In this case, ifort doesn't do the assignment properly.
We'll fix it.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/pe...cetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran