gfortran problem
rudra
While the code is compiling very well in intel compiler, its showing
following error while compiling with gfortran just before the end of
run:
######### calculation over
*** glibc detected *** /matsc/students/Rudra/Recursion/Real/run.out:
double free or corruption (out): 0xb7f79008 ***
======= Backtrace: =========
/lib/libc.so.6[0x5efac1]
/lib/libc.so.6(cfree+0x90)[0x5f30f0]
/usr/lib/libgfortran.so.1(_gfortran_internal_free+0x21)[0x24e0c1]
/matsc/students/Rudra/Recursion/Real/run.out[0x804a075]
/matsc/students/Rudra/Recursion/Real/run.out[0x804af1b]
/matsc/students/Rudra/Recursion/Real/run.out[0x804af47]
/lib/libc.so.6(__libc_start_main+0xe0)[0x59c390]
/matsc/students/Rudra/Recursion/Real/run.out[0x8048751]
======= Memory map: ========
00110000-00111000 r-xp 00110000 00:00 0 [vdso]
00242000-002c1000 r-xp 00000000 08:07 4259911 /usr/lib/libgfortran.so.
1.0.0
002c1000-002c2000 rwxp 0007e000 08:07 4259911 /usr/lib/libgfortran.so.
1.0.0
00567000-00582000 r-xp 00000000 08:07 4859005 /lib/ld-2.7.so
00582000-00583000 r-xp 0001a000 08:07 4859005 /lib/ld-2.7.so
00583000-00584000 rwxp 0001b000 08:07 4859005 /lib/ld-2.7.so
00586000-006d9000 r-xp 00000000 08:07 2457626 /lib/libc-2.7.so
006d9000-006db000 r-xp 00153000 08:07 2457626 /lib/libc-2.7.so
006db000-006dc000 rwxp 00155000 08:07 2457626 /lib/libc-2.7.so
006dc000-006df000 rwxp 006dc000 00:00 0
006e1000-00708000 r-xp 00000000 08:07 2457630 /lib/libm-2.7.so
00708000-00709000 r-xp 00026000 08:07 2457630 /lib/libm-2.7.so
00709000-0070a000 rwxp 00027000 08:07 2457630 /lib/libm-2.7.so
00aaa000-00ab5000 r-xp 00000000 08:07 2457634 /lib/
libgcc_s-4.1.2-20070925.so.1
00ab5000-00ab6000 rwxp 0000a000 08:07 2457634 /lib/
libgcc_s-4.1.2-20070925.so.1
08048000-0804c000 r-xp 00000000 00:11 5112713 /matsc/students/Rudra/
Recursion/Real/run.out
0804c000-0804d000 rw-p 00003000 00:11 5112713 /matsc/students/Rudra/
Recursion/Real/run.out
0906e000-090b2000 rw-p 0906e000 00:00 0
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7f79000-b7fc1000 rw-p b7f79000 00:00 0
bf89f000-bf8b4000 rw-p bffea000 00:00 0 [stack]
Program received signal SIGABRT, Aborted.
0x00110402 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install gcc.i386
glibc.i686
(gdb) backtrace
#0 0x00110402 in __kernel_vsyscall ()
#1 0x005af690 in raise () from /lib/libc.so.6
#2 0x005b0f91 in abort () from /lib/libc.so.6
#3 0x005e79eb in __libc_message () from /lib/libc.so.6
#4 0x005efac1 in _int_free () from /lib/libc.so.6
#5 0x005f30f0 in free () from /lib/libc.so.6
#6 0x0024e0c1 in _gfortran_internal_free () from /usr/lib/
libgfortran.so.1
#7 0x0804a075 in coefficient_ (istart=@0xbf8b1eb4, lorbit=@0xbf8b1eac,
nrec=@0xbf8b1ea8, nsite=@0xbf8b1efc,
nmax=@0xbf8b1eb0, nn=@0xbf8b1ef8, cmat=0xbf8b1e50, dmat=0xbf8b1e08) at
coeff.f90:5
#8 0x0804af1b in MAIN__ () at main.f90:64
#9 0x0804af47 in main ()
(gdb)
can anybody tell me whats wrong? gfortran is working well elsewhere
Tobias Burnus
> *** glibc detected *** /matsc/students/Rudra/Recursion/Real/run.out:
> double free or corruption (out): 0xb7f79008 ***
> #6 0x0024e0c1 in _gfortran_internal_free () from /usr/lib/
> libgfortran.so.1
> #7 0x0804a075 in coefficient_ (istart=@0xbf8b1eb4, lorbit=@0xbf8b1eac,
> nrec=@0xbf8b1ea8, nsite=@0xbf8b1efc,
> nmax=@0xbf8b1eb0, nn=@0xbf8b1ef8, cmat=0xbf8b1e50, dmat=0xbf8b1e08) at
> coeff.f90:5
> #8 0x0804af1b in MAIN__ () at main.f90:64
> #9 0x0804af47 in main ()
> (gdb)
>
> can anybody tell me whats wrong? gfortran is working well elsewhere
Not without further information such as knowing how "coefficient" in
coeff.f90 looks like. If you use POINTER then it could well be a
programming error, if not it could be a gfortran bug.
Regarding the latter, it would like to know the system (target) and
the version of gfortran (run: gfortran -v).
Additionally, if you have "valgrind", run you program in valigrind.
This provides often a better clue where things go wrong. Sometimes
things go wrong but surface never or only much later. Run also the
ifort program in "valgrind", even though it does not crash it could
well have the same problem.
Tobias
rudra
its not a pointer, just an array.
and this is output of gfortran -v:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c+
+,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-
plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --
enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/
usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-
linux
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
Richard Maine
> On Mar 31, 10:05 pm, Tobias Burnus <bur...@net-b.de> wrote:
> > On Mar 31, 6:52 pm, rudra <bnrj.ru...@gmail.com> wrote:
> >
> > > can anybody tell me whats wrong? gfortran is working well elsewhere
> >
> > Not without further information such as knowing how "coefficient" in
> > coeff.f90 looks like. If you use POINTER then it could well be a
> > programming error, if not it could be a gfortran bug.
> its not a pointer, just an array.
...
I doubt you are going to get much useful help without showing the code.
Tobias suggested the possibility that coefficient might be a pointer as
just one possibility, but there are many others. It could even be from
other apparently unrelated places in the code. I dion't even see enough
here on which to base a speculation. That the code "works elsewhere"
isn't necessarily indicative of much.
As Tobias said, perhaps it is even a bug in gfortran, but no way that I
would draw such a conclusion (or any other) from the current lack of
data.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Greg Lindahl
rudra <bnrj....@gmail.com> wrote:
>*** glibc detected *** /matsc/students/Rudra/Recursion/Real/run.out:
>double free or corruption (out): 0xb7f79008 ***
This is often caused by overrunning the beginning or end of an
allocated array. Valgrind helps find these.
The Intel compiler uses a different method of getting the memory for
allocated arays, so it might not cause this bug to be exposed.
-- greg
rudra
without anysubroutine) the program is running fine. I have used the
same program, no change in calculatin...just all subroutines are puted
in main.
as soon as i am trying for a modularize version, its failling.
rudra
this is the first time i am even hearing the name valgrind......
what i can do?
valgrind --leak-check=yes ./run.out
==23137== Memcheck, a memory error detector.
==23137== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
al.
==23137== Using LibVEX rev 1732, a library for dynamic binary
translation.
==23137== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==23137== Using valgrind-3.2.3, a dynamic binary instrumentation
framework.
==23137== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et
al.
==23137== For more details, rerun with: -v
==23137==
==23137== Invalid read of size 8
==23137== at 0x8049806: coefficient_ (coeff.f90:93)
==23137== by 0x804AF26: MAIN__ (main.f90:64)
==23137== by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
Real/run.out)
==23137== Address 0x40E3F70 is 0 bytes after a block of size 285,768
alloc'd
==23137== at 0x4005525: malloc (vg_replace_malloc.c:149)
==23137== by 0x24E34C: (within /usr/lib/libgfortran.so.1.0.0)
==23137== by 0x24E468: (within /usr/lib/libgfortran.so.1.0.0)
==23137== by 0x24E4D0: _gfortran_internal_malloc (in /usr/lib/
libgfortran.so.1.0.0)
==23137== by 0x804899E: coefficient_ (coeff.f90:5)
==23137== by 0x804AF26: MAIN__ (main.f90:64)
==23137== by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
Real/run.out)
==23137==
==23137== Invalid write of size 8
==23137== at 0x804980F: coefficient_ (coeff.f90:93)
==23137== by 0x804AF26: MAIN__ (main.f90:64)
==23137== by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
Real/run.out)
==23137== Address 0x40E3F70 is 0 bytes after a block of size 285,768
alloc'd
==23137== at 0x4005525: malloc (vg_replace_malloc.c:149)
==23137== by 0x24E34C: (within /usr/lib/libgfortran.so.1.0.0)
==23137== by 0x24E468: (within /usr/lib/libgfortran.so.1.0.0)
==23137== by 0x24E4D0: _gfortran_internal_malloc (in /usr/lib/
libgfortran.so.1.0.0)
==23137== by 0x804899E: coefficient_ (coeff.f90:5)
==23137== by 0x804AF26: MAIN__ (main.f90:64)
==23137== by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
Real/run.out)
calculation done for orbital 1
calculation done for orbital 2
calculation done for orbital 3
calculation done for orbital 4
calculation done for orbital 5
calculation done for orbital 6
calculation done for orbital 7
calculation done for orbital 8
calculation done for orbital 9
calculation over
==23137==
==23137== ERROR SUMMARY: 6480 errors from 2 contexts (suppressed: 15
from 1)
==23137== malloc/free: in use at exit: 0 bytes in 0 blocks.
==23137== malloc/free: 4,397 allocs, 4,397 frees, 2,269,164 bytes
allocated.
==23137== For counts of detected errors, rerun with: -v
==23137== All heap blocks were freed -- no leaks are possible.
Gerry Ford
"rudra" <bnrj....@gmail.com> wrote in message
news:2f090017-b352-4eaf...@s19g2000prg.googlegroups.com...
> as suggested by tobious, i run valgrind with the following output. But
> this is the first time i am even hearing the name valgrind......
> what i can do?
> valgrind --leak-check=yes ./run.out
> ==23137== malloc/free: 4,397 allocs, 4,397 frees, 2,269,164 bytes
> allocated.
> ==23137== For counts of detected errors, rerun with: -v
> ==23137== All heap blocks were freed -- no leaks are possible.
If this isn't a core dump, then I don't know what is.
One thing nice about fortran is that it knows nothing of malloc.
I think you want to be in comp.unix.something. Actually what is that ng
called?
--
"I am waiting for them to prove that God is really American."
~~ Lawrence Ferlinghetti
fj
Look at the instruction coeff.f90:93 carefully : the problem occured
there ! But the origin of the problem is possibly somewhere else (a
wrong definition of an argument passed to the routine coef for
instance).
And please, as other guys said, show us your code (at least the
variable definition, the call statement to coef ...) else we cannot
help you efficiently.
Greg Lindahl
>==23137== at 0x8049806: coefficient_ (coeff.f90:93)
>==23137== by 0x804AF26: MAIN__ (main.f90:64)
>==23137== by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
>Real/run.out)
>==23137== Address 0x40E3F70 is 0 bytes after a block of size 285,768
At line 93 of coeff.f90, you read off the end of the array
coefficient(). You allocated it in line 5 of coeff.f90.
>==23137== Invalid write of size 8
>==23137== at 0x804980F: coefficient_ (coeff.f90:93)
>==23137== by 0x804AF26: MAIN__ (main.f90:64)
>==23137== by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
>Real/run.out)
>==23137== Address 0x40E3F70 is 0 bytes after a block of size 285,768
This is the same thing, only this time you wrote it instead of reading
it. Boom! You have corrupted memory.
If you run with the Intel compiler you'll probably see the same thing,
only you get lucky and don't corrupt the malloc arena. So you think
your program gives the right output... but...
-- greg
Greg Lindahl
Gerry Ford <ge...@nowhere.ford> wrote:
>One thing nice about fortran is that it knows nothing of malloc.
It is typical of Fortran implementations that allocating arrays uses
malloc() under the hood. You can see this by looking at the stack
traces that valgrind is printing. Understanding this helps when you
get bizarre crashes, because the effect of writing before or after
your array sometimes shows up as malloc()-detected memory corruption.
>I think you want to be in comp.unix.something. Actually what is that ng
>called?
Uh, comp.lang.fortran? We're usually a big tent around here. Too bad
there isn't a port of valgrind to Windows! Insufficient innovation on
the Windows platform, I guess.
-- g
Gerry Ford
"Greg Lindahl" <lin...@pbm.com> wrote in message
news:47f1e1f2$1...@news.meer.net...
> In article <1207022...@news.newsgroups.com>,
> Gerry Ford <ge...@nowhere.ford> wrote:
>
>>One thing nice about fortran is that it knows nothing of malloc.
>
> It is typical of Fortran implementations that allocating arrays uses
> malloc() under the hood. You can see this by looking at the stack
> traces that valgrind is printing. Understanding this helps when you
> get bizarre crashes, because the effect of writing before or after
> your array sometimes shows up as malloc()-detected memory corruption.
Could you see something in what he posted along these lines? I did notice
not only that the number of mallocs and the number of free's was equal, but
that he printed "mission accomplished" at the end.
>
>>I think you want to be in comp.unix.something. Actually what is that ng
>>called?
>
> Uh, comp.lang.fortran? We're usually a big tent around here. Too bad
> there isn't a port of valgrind to Windows! Insufficient innovation on
> the Windows platform, I guess.
I don't mean it like that. I've been writing functions that are native to
unix and was myself curious. I'm always interested in good usenet
territory. BTW, there's a traveler's spam advisory for c.l.c. It's a sorry
sight: tennis shoes, cheap flugs to london, sex for pedophiles. The good
news is that fortran doesn't have to go there.
--
"That this social order with its pauperism, famines, prisons, gallows,
armies, and wars is necessary to society; that still greater disaster
would ensue if this organization were destroyed; all this is said only
by those who profit by this organization, while those who suffer from it
- and they are ten times as numerous - think and say quite the contrary."
~~ Leo Tolstoy
Greg Lindahl
>> malloc() under the hood. You can see this by looking at the stack
>> traces that valgrind is printing. Understanding this helps when you
>> get bizarre crashes, because the effect of writing before or after
>> your array sometimes shows up as malloc()-detected memory corruption.
>Could you see something in what he posted along these lines? I did notice
>not only that the number of mallocs and the number of free's was equal, but
>that he printed "mission accomplished" at the end.
His original posting:
*** glibc detected *** /matsc/students/Rudra/Recursion/Real/run.out:
double free or corruption (out): 0xb7f79008 ***
> BTW, there's a traveler's spam advisory for c.l.c. It's a sorry
> sight: tennis shoes, cheap flugs to london, sex for pedophiles. The good
> news is that fortran doesn't have to go there.
The anal-retentive topic-guards put me off of c.l.c ages ago.
-- g
David Flower
Its often a good idea in cases like these to run on a compiler
(Salford FNT90) is a good example with a lot of checks in place. It
often picks up the error at the point that the damage occurs, rather
than when the program finally crashes. If Salford gives it a clean
bill of health, then a compiler bug is more likely
Dave Flower
Dick Hendrickson
As a general rule, if things work as a single program but fail when
you split it into subroutines, you've got a problem with arguments
not matching. The usual case is passing a single precision argument
to a double precision dummy argument, or vice versa. Most compilers
have some sort of argument checking option, try turning that on.
Or, put all of the subroutines in a module. That forces the compiler
to do some check at compile time and usually finds most argument
mismatch errors.
The single best piece of advice for a beginner is to use
IMPLICIT NONE and to put all subroutines into modules.
Dick Hendrickson
Craig Powers
> when I am running my fortran 90 code, i am getting an unusual problem.
> While the code is compiling very well in intel compiler, its showing
> following error while compiling with gfortran just before the end of
> run:
Does it run in ifort if you turn on checking, e.g. -check all or -check
bounds?
Steve Lionel
I suggest also adding "-gen-interface -warn interface".
--
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/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
rudra
apperent problem. in my coeff.f90, it is declared as:
subroutine coefficient(istart,lorbit,nrec,nsite,nmax,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?
glen herrmannsfeldt
> 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,nmax,nn,cmat,dmat)
> real(8),dimension(nmax,lorbit)::h1,h2,h3
> when i changed this array declaration to allocatable array, it is
> done.
If you aren't using ALLOCATE with it then it shouldn't
be ALLOCATABLE. If you are it must be either ALLOCATABLE
or POINTER. With only two lines of code it is hard to say
much more, though.
> but can anyone plz tell me, even the declaration as above is
> completely valid, why it was giving error?
There are many cases where a valid declaration used in the wrong
way will result in an error. This is especially true when calling
subroutines. The declaration not only has to be valid, but it
must match the declarations in the called/calling routine.
Many such errors are not noticed by the compiler and may cause
errors or just wrong results at run time.
-- glen
James Van Buskirk
> subroutine coefficient(istart,lorbit,nrec,nsite,nmax,nn,cmat,dmat)
> real(8),dimension(nmax,lorbit)::h1,h2,h3
> etc
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
Steve Lionel
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/03/31/doctor-it-hurts-when-i-do-this/)
James Van Buskirk
news:o997v351u4il6cnpg...@4ax.com...
> On Wed, 2 Apr 2008 07:54:10 -0600, "James Van Buskirk"
> <not_...@comcast.net>
> 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.
Yes, I saw that post and Paul Richard Thomas told me in email that
gfortran also supports allocation on assignment, although I may
have found a problem with gfortran's implementation:
C:\gfortran\test\allocate_assign>type allocate_assign.f90
! File: allocate_assign.f90
! Public domain 2008 James Van Buskirk
module mytypes
implicit none
type label
integer, allocatable :: parts(:)
end type label
type table
type(label), allocatable :: headers(:)
end type table
end module mytypes
program allocate_assign
use mytypes
implicit none
integer, parameter :: ik8 = selected_int_kind(18)
type(table) x1(2)
type(table) x2(3)
type(table), allocatable :: x(:)
integer i
integer j
integer k
integer m
integer(ik8) s
write(*,'(a)') 'assigning from x1'
x1 = [table([(label([(j,j=1,3)]),i=1,3)]), &
table([(label([(j,j=1,4)]),i=1,4)])]
write(*,'(a,i0)') 'size(x1) = ', size(x1)
do m = 1, size(x1)
write(*,'(a,i0,a,i0)') 'size(x1(',m,')%headers) =
',size(x1(m)%headers)
do i = 1, size(x1(m)%headers)
write(*,'(3(a,i0))') 'size(x1(',m,')%headers(',i,')%parts) =
',size(x1(
m)%headers(i)%parts)
write(*,'(a,i0,a,i0,a,100(i0:","))')
'x1(',m,')%headers(',i,')%parts =
', x1(m)%headers(i)%parts
end do
end do
write(*,'(a)') 'assigning from x2'
x2 = [table([(label([(j,j=1,4)]),i=1,4)]), &
table([(label([(j,j=1,5)]),i=1,5)]), &
table([(label([(j,j=1,6)]),i=1,6)])]
do m = 1, size(x2)
write(*,'(a,i0,a,i0)') 'size(x2(',m,')%headers) =
',size(x2(m)%headers)
do i = 1, size(x2(m)%headers)
write(*,'(3(a,i0))') 'size(x2(',m,')%headers(',i,')%parts) =
',size(x2(
m)%headers(i)%parts)
write(*,'(a,i0,a,i0,a,100(i0:","))')
'x2(',m,')%headers(',i,')%parts =
', x2(m)%headers(i)%parts
end do
end do
s = 0
do k = 1, 1000000000
write(*,*) k,s
x = x1
write(*,*) k,s
s = s+x(2)%headers(2)%parts(2)
write(*,*) k,s
x = x2
write(*,*) k,s
s = s+x(2)%headers(2)%parts(2)
end do
write(*,*) s
end program allocate_assign
! End of file: allocate_assign.f90
C:\gfortran\test\allocate_assign>C:\gcc_equation\bin\x86_64-pc-mingw32-gfortran
allocate_assign.f90 -oallocate_assign
C:\gfortran\test\allocate_assign>allocate_assign
assigning from x1
size(x1) = 2
size(x1(1)%headers) = 3
size(x1(1)%headers(1)%parts) = 3
x1(1)%headers(1)%parts = 1,2,3
size(x1(1)%headers(2)%parts) = 3
x1(1)%headers(2)%parts = 1,2,3
size(x1(1)%headers(3)%parts) = 3
x1(1)%headers(3)%parts = 1,2,3
size(x1(2)%headers) = 4
size(x1(2)%headers(1)%parts) = 4
x1(2)%headers(1)%parts = 1,2,3,4
size(x1(2)%headers(2)%parts) = 4
x1(2)%headers(2)%parts = 1,2,3,4
size(x1(2)%headers(3)%parts) = 4
x1(2)%headers(3)%parts = 1,2,3,4
size(x1(2)%headers(4)%parts) = 4
x1(2)%headers(4)%parts = 1,2,3,4
assigning from x2
size(x2(1)%headers) = 4
size(x2(1)%headers(1)%parts) = 4
x2(1)%headers(1)%parts = 1,2,3,4
size(x2(1)%headers(2)%parts) = 4
x2(1)%headers(2)%parts = 1,2,3,4
size(x2(1)%headers(3)%parts) = 4
x2(1)%headers(3)%parts = 1,2,3,4
size(x2(1)%headers(4)%parts) = 4
x2(1)%headers(4)%parts = 1,2,3,4
size(x2(2)%headers) = 5
size(x2(2)%headers(1)%parts) = 5
x2(2)%headers(1)%parts = 1,2,3,4,5
size(x2(2)%headers(2)%parts) = 5
x2(2)%headers(2)%parts = 1,2,3,4,5
size(x2(2)%headers(3)%parts) = 5
x2(2)%headers(3)%parts = 1,2,3,4,5
size(x2(2)%headers(4)%parts) = 5
x2(2)%headers(4)%parts = 1,2,3,4,5
size(x2(2)%headers(5)%parts) = 5
x2(2)%headers(5)%parts = 1,2,3,4,5
size(x2(3)%headers) = 6
size(x2(3)%headers(1)%parts) = 6
x2(3)%headers(1)%parts = 1,2,3,4,5,6
size(x2(3)%headers(2)%parts) = 6
x2(3)%headers(2)%parts = 1,2,3,4,5,6
size(x2(3)%headers(3)%parts) = 6
x2(3)%headers(3)%parts = 1,2,3,4,5,6
size(x2(3)%headers(4)%parts) = 6
x2(3)%headers(4)%parts = 1,2,3,4,5,6
size(x2(3)%headers(5)%parts) = 6
x2(3)%headers(5)%parts = 1,2,3,4,5,6
size(x2(3)%headers(6)%parts) = 6
x2(3)%headers(6)%parts = 1,2,3,4,5,6
1 0
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?
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.
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.
For e.g., the following code:
C:\gfortran\test\allocate_assign>type note7_35.f90
program note7_35
implicit none
character, allocatable :: name*(:)
character(*), parameter :: FIRST_NAME = 'Julius'
character(*), parameter :: SURNAME = 'No'
integer n
n = 10
allocate(name, SOURCE=repeat('x',n))
name = 'Dr. '//FIRST_NAME//' '//SURNAME
write(*,*) len(name), name
deallocate(name)
n = 10
allocate(name, SOURCE=repeat('x',n))
name(:) = 'Dr. '//FIRST_NAME//' '//SURNAME
write(*,*) len(name), name
end program note7_35
C:\gfortran\test\allocate_assign>C:\gcc_equation\bin\x86_64-pc-mingw32-gfortran
note7_35.f90 -onote7_35
note7_35.f90:3.35:
character, allocatable :: name*(:)
1
Error: Syntax error in character length specification at (1)
note7_35.f90:9.24:
allocate(name, SOURCE=repeat('x',n))
1
Error: Syntax error in ALLOCATE statement at (1)
note7_35.f90:14.24:
allocate(name, SOURCE=repeat('x',n))
1
Error: Syntax error in ALLOCATE statement at (1)
note7_35.f90:15.3:
name(:) = 'Dr. '//FIRST_NAME//' '//SURNAME
1
Error: Unclassifiable statement at (1)
note7_35.f90:10.7:
name = 'Dr. '//FIRST_NAME//' '//SURNAME
1
Error: Symbol 'name' at (1) has no IMPLICIT type
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.
Steve Lionel
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 look
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 your
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 they
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.
glen herrmannsfeldt
(someone wrote)
>>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 your
> 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 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 they
> 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
Richard Maine
> 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.
glen herrmannsfeldt
> glen herrmannsfeldt 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.
(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
Richard Maine
> 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.
Steve Lionel
>> 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 look
> 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.