Home > Archive > Fortran > July 2004 > Problems with intel fortran compiler version 8
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Problems with intel fortran compiler version 8
|
|
|
| I have found two problems with the NASA overflow code using Intel Fortran
8 for linux. I'm using the latest version (just updated today) and have
posted my problems to premier.intel.com. Item number 1 concerns reading
a namelist file.
Here is the test program :
PROGRAM FPREAD
C
C All procs do some initialization, global master reads
C MPIINP namelist input.
C
C Called by: OVERRU.
C
C Calls: none.
C
IMPLICIT NONE
CHARACTER*150 OFILENAME
INTEGER*4 ILEN
INTEGER*4 JMETHOD, KMETHOD, LMETHOD, JCHUNK
INTEGER*4 KCHUNK, LCHUNK
INTEGER*4 FINEPART(5,10)
INTEGER*4 SHARZONE(5,10)
C
C
NAMELIST/MPIINP/ JMETHOD,KMETHOD,LMETHOD,
& JCHUNK ,KCHUNK ,LCHUNK,
& FINEPART,SHARZONE
C
INTEGER N,I
OFILENAME = 'over.1.14procs.inp'
ILEN = INDEX(OFILENAME,' ')-1
OPEN(5,FILE=OFILENAME(1:ILEN),STATUS='OL
D')
C
C Defaults for method and chunk size.
C
JMETHOD = 4
KMETHOD = 4
LMETHOD = 4
JCHUNK = 10
KCHUNK = 10
LCHUNK = 10
C
C
READ(*,MPIINP,END=120,ERR=110)
C
C Write a summary of the 'MPI' input parameters.
C
WRITE(*,1) JMETHOD,KMETHOD,LMETHOD,JCHUNK,KCHUNK,LC
HUNK
1 FORMAT(/' MPI PARAMETERS ($MPIINP)'/
& 4X,'J DIRECTION SOLVER (JMETHOD) = ',I5/
& 4X,'K DIRECTION SOLVER (KMETHOD) = ',I5/
& 4X,'L DIRECTION SOLVER (LMETHOD) = ',I5/
& 4X,'J DIRECTION CHUNK SIZE (JCHUNK ) = ',I5/
& 4X,'K DIRECTION CHUNK SIZE (KCHUNK ) = ',I5/
& 4X,'L DIRECTION CHUNK SIZE (LCHUNK ) = ',I5)
WRITE(6,*) FINEPART
WRITE(6,*) SHARZONE
GOTO 130
C
110 CONTINUE
WRITE(*,"(' ** ERROR ** ERROR READING NAMELIST $MPIINP')")
GOTO 130
120 WRITE(*,"(' ** ERROR ** EOF $MPIINP')")
130 CONTINUE
STOP
END
and here is my namelist input :
$MPIINP
FINEPART= 2, 3, 1, 1,
5, 3, 1, 1,
7, 1, 2, 1,
4, 2, 1, 1,
3, 2, 1, 1,
SHARZONE= 1, 1,
2, 6,
$END
If I change the * (preconnected unit) to a 5 it works. If I run it the
way it is, it hangs. It works correctly under Intel 7 and Portland
group.
I'm also getting a segfault using an automatic array. I'm running on a
workstation with 2GB memory, so it shouldn't be a memory size. Linux
version is Redhat 7.3. This program also works under Intel 7 and
Portland Group.
Here is the auto program :
Program auto
n = 5000
m = 500
print *,n*m
call sub1(n,m)
stop
end
Subroutine sub1(n,m)
Dimension a(n,m)
call sub2(a,n,m)
return
end
Subroutine sub2(a,n,m)
dimension a(n,m)
do i=1,n
do j=1,m
a(i,j) = 0.0
enddo
enddo
return
end
Maybe I just don't understand how automatic arrays work.
If anyone can shed any information on the problems I'm having, I would
appreciate it.
BB
The Boeing Company
| |
| Richard Maine 2004-06-28, 4:11 pm |
| BB <mail@mail.com> writes:
> Item number 1 concerns reading a namelist file.
Nothing obvious jumped out at me on that one. I didn't
study it carefully.
> I'm also getting a segfault using an automatic array. I'm running on a
> workstation with 2GB memory, so it shouldn't be a memory size.
[code elided]
The code looks fine (and niceely simple) to me. I think you are using
the feature fine. The "usual" (and very common) problem with
automatic arrays is that many systems have insanely small default
limits on stack size. Combine that with the fact that the "natural"
implementation of automatic arrays is to put them on the stack,
and you get problems. Some compilers put automatic arrays
elsewhere in order to avoid this problem.
The simplest solution is to override the default stack size limit.
To do that, use "limit stack un" for [t]csh, or
"ulimit -s unlimited" for bash. I think I got those right.
Put those in the appropriate initialization file.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Andy Mai 2004-06-28, 4:11 pm |
| >Here is the auto program :
>
> Program auto
> n = 5000
> m = 500
> print *,n*m
> call sub1(n,m)
> stop
> end
> Subroutine sub1(n,m)
> Dimension a(n,m)
> call sub2(a,n,m)
> return
> end
> Subroutine sub2(a,n,m)
> dimension a(n,m)
> do i=1,n
> do j=1,m
> a(i,j) = 0.0
> enddo
> enddo
> return
> end
It looks like you may need to do an "unlimit" command before running
the executable. See:
http://support.intel.com/support/pe.../fortran/linux/
for more information.
Andy Mai
| |
|
| On Mon, 28 Jun 2004 10:08:10 -0700, Andy Mai wrote:
>
> It looks like you may need to do an "unlimit" command before running the
> executable. See:
>
> http://support.intel.com/support/pe.../fortran/linux/
>
> for more information.
>
> Andy Mai
Did the ulimit -s unlimited (under bash) and it did not help.
BB
| |
| Toon Moene 2004-06-28, 4:11 pm |
| BB wrote:
> Here is the auto program :
>
> Program auto
> n = 5000
> m = 500
> print *,n*m
> call sub1(n,m)
> stop
> end
> Subroutine sub1(n,m)
> Dimension a(n,m)
> call sub2(a,n,m)
> return
> end
> Subroutine sub2(a,n,m)
> dimension a(n,m)
> do i=1,n
> do j=1,m
> a(i,j) = 0.0
> enddo
> enddo
> return
> end
>
> Maybe I just don't understand how automatic arrays work.
It works for me (g77-3.3.4 on Debian testing as of yesterday):
toon@book:~/g77-bugs$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
toon@book:~/g77-bugs$ g77 -O2 bb.f
toon@book:~/g77-bugs$ ./a.out
2500000
toon@book:~/g77-bugs$ g77 -v
Reading specs from /usr/lib/gcc-lib/powerpc-linux/3.3.4/specs
Configured with: ../src/configure -v
--enable- languages=c,c++,java,f77,pascal,objc,ada
--prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
--disable-multilib powerpc-linux
Thread model: posix
gcc version 3.3.4 (Debian)
This is on a 256 Mbyte Powerbook G4.
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
| |
|
| On Mon, 28 Jun 2004 at 17:08 GMT, Andy Mai (aka Bruce)
was almost, but not quite, entirely unlike tea:
>
> It looks like you may need to do an "unlimit" command before running
> the executable. See:
s/unlimit/ulimit/
> http://support.intel.com/support/pe.../fortran/linux/
Unfortunately, I came across a problem that looks very much like a
stack size problem - I had several local arrays that ended up adding
to 4 MB or so.
But those suggestions, and suggestions to play with thread limits
elsewhere (I am not using threads though) never helped.
I've always had `ulimit -s unlimited` in my startup scripts, and my
program still SIGSEGVs.
Unfortunately, the code is too big, complex, and ugly to post.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
If a train station is a place where a train stops, what's a workstation?
| |
| Richard Edgar 2004-06-29, 8:57 am |
| BB wrote:
> Did the ulimit -s unlimited (under bash) and it did not help.
I have found in the past that some versions of the Intel compiler, when
combined with certain compiler options (static linking IIRC) don't work
correctly with these ulimit commands. I posted something to the Intel
support forums about this a few months ago. The solution was to use a
later version of the compiler.
HTH,
Richard
| |
| Steve Lionel 2004-06-29, 4:09 pm |
| On Mon, 28 Jun 2004 16:08:45 GMT, BB <mail@mail.com> wrote:
>I have found two problems with the NASA overflow code using Intel Fortran
>8 for linux. I'm using the latest version (just updated today) and have
>posted my problems to premier.intel.com. Item number 1 concerns reading
>a namelist file.
Your program opens unit 5 and reads from unit *. These are not necessarily
the same units, and in Intel Fortran, they are not. Some implementations may
allow this, others may not. The standard certainly does not imply that this
should work. Please use the same unit number consistently.
>I'm also getting a segfault using an automatic array. I'm running on a
>workstation with 2GB memory, so it shouldn't be a memory size. Linux
>version is Redhat 7.3. This program also works under Intel 7 and
>Portland Group.
This program declares a 10MB automatic array. In some compilers, including
ifc 7.1, these are created on the heap. In Intel Fortran 8, they are created
on the stack. You need to be sure that your stack is large enough (I found
20MB to be sufficient.)
ulimit may or may not actually raise the stack limit sufficiently, depending
on the particular Linux implementation used, system installation parameters,
phase of the moon, etc. You can try the "limit" command to see what it
actually got set to. Try setting a specific large value rather than trying
for "unlimited".
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Dr Chaos 2004-06-29, 4:09 pm |
| On Tue, 29 Jun 2004 10:52:14 +0200, Richard Edgar <rge21@astro.su.se> wrote:
> BB wrote:
>
>
> I have found in the past that some versions of the Intel compiler, when
> combined with certain compiler options (static linking IIRC) don't work
> correctly with these ulimit commands. I posted something to the Intel
> support forums about this a few months ago. The solution was to use a
> later version of the compiler.
>
> HTH,
>
> Richard
I encountered another strange problem with some versions of the
Intel fortran 8 and odd crashes with memory allocation.
Namely that I was using the generic 'i386' versions of glibc (as installed
in an RPM package). When I replaced them with the 'i686' glibc
package the problem went away.
Try that.
| |
| Simon Geard 2004-07-04, 10:04 am |
| BB wrote:
> I have found two problems with the NASA overflow code using Intel Fortran
> 8 for linux. I'm using the latest version (just updated today) and have
> posted my problems to premier.intel.com. Item number 1 concerns reading
> a namelist file.
>
> Here is the test program :
>
>
> PROGRAM FPREAD
> C
> C All procs do some initialization, global master reads
> C MPIINP namelist input.
> C
> C Called by: OVERRU.
> C
> C Calls: none.
> C
> IMPLICIT NONE
>
> CHARACTER*150 OFILENAME
> INTEGER*4 ILEN
> INTEGER*4 JMETHOD, KMETHOD, LMETHOD, JCHUNK
> INTEGER*4 KCHUNK, LCHUNK
> INTEGER*4 FINEPART(5,10)
> INTEGER*4 SHARZONE(5,10)
>
> C
> C
> NAMELIST/MPIINP/ JMETHOD,KMETHOD,LMETHOD,
> & JCHUNK ,KCHUNK ,LCHUNK,
> & FINEPART,SHARZONE
> C
> INTEGER N,I
>
> OFILENAME = 'over.1.14procs.inp'
> ILEN = INDEX(OFILENAME,' ')-1
> OPEN(5,FILE=OFILENAME(1:ILEN),STATUS='OL
D')
>
> C
> C Defaults for method and chunk size.
> C
> JMETHOD = 4
> KMETHOD = 4
> LMETHOD = 4
> JCHUNK = 10
> KCHUNK = 10
> LCHUNK = 10
> C
> C
> READ(*,MPIINP,END=120,ERR=110)
> C
> C Write a summary of the 'MPI' input parameters.
> C
> WRITE(*,1) JMETHOD,KMETHOD,LMETHOD,JCHUNK,KCHUNK,LC
HUNK
> 1 FORMAT(/' MPI PARAMETERS ($MPIINP)'/
> & 4X,'J DIRECTION SOLVER (JMETHOD) = ',I5/
> & 4X,'K DIRECTION SOLVER (KMETHOD) = ',I5/
> & 4X,'L DIRECTION SOLVER (LMETHOD) = ',I5/
> & 4X,'J DIRECTION CHUNK SIZE (JCHUNK ) = ',I5/
> & 4X,'K DIRECTION CHUNK SIZE (KCHUNK ) = ',I5/
> & 4X,'L DIRECTION CHUNK SIZE (LCHUNK ) = ',I5)
> WRITE(6,*) FINEPART
> WRITE(6,*) SHARZONE
> GOTO 130
> C
> 110 CONTINUE
> WRITE(*,"(' ** ERROR ** ERROR READING NAMELIST $MPIINP')")
> GOTO 130
> 120 WRITE(*,"(' ** ERROR ** EOF $MPIINP')")
> 130 CONTINUE
> STOP
> END
>
> and here is my namelist input :
>
> $MPIINP
> FINEPART= 2, 3, 1, 1,
> 5, 3, 1, 1,
> 7, 1, 2, 1,
> 4, 2, 1, 1,
> 3, 2, 1, 1,
> SHARZONE= 1, 1,
> 2, 6,
> $END
>
> If I change the * (preconnected unit) to a 5 it works. If I run it the
> way it is, it hangs. It works correctly under Intel 7 and Portland
> group.
>
>
I have just tried this program with Intel Fortran8.0 compiler on linux
(Mandrake10) and I think it is working as it should. Haven't tried the other one
yet.
I did have to make two changes: ! instead of C for comments and to put the & on
the line ends rather than the beginning.
The hang is caused by the program waitng to read standard input, so if you run
it as ./fpread < over.1.14procs.inp then you'll find it works. In fortran90
there is nothing special about unit 5 or 6. * is used to denote the preconnected
stdin and stdout.
Simon Geard
|
|
|
|
|