Internal compiler error

[sdk0084]

Hi There
I am tring to compile wrf using intel fortran compiler v9.0 and it is crushing in the same time i have no problems to compile the wrf using pgi fortran compiler any help is wellcome

env settings:
source /opt/intel/fc/9.0/bin/ifortvars.sh
source /opt/intel/idb/9.0/bin/idbvars.sh

export FC=ifort
export FFLAGS="-g -O2 -mp -recursive"
export CPPFLAGS="-DpgiFortran"
export CC=gcc
export F90=ifort
export CXX=g++
export F90FLAGS="-g -O2 -mp -recursive"
export CXXFLAGS="-g -02"


ifort -c -real_size `expr 4 * 8` -FR -cm -w -I. -convert big_endian -mp -I../dyn_em -I../dyn_nmm -module ../main -I../external/io_netcdf -I../external/io_int -I../external/esmf_time_f90 -I../external -I../frame -I../share -I../phys -I../inc module_configure.f
ilio_malloc: out of memory -- e9b2bf4 bytes requested

fortcom: Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.

compilation aborted for module_configure.f (code 3)
make[2]: [module_configure.o] Error 3 (ignored)
rm -f module_machine.o

[Steven_L_Intel1]

Please report the problem to Intel Premier Support and be sure to include everything needed to reproduce the problem. You should also make sure that you are using the current version of the compiler from Intel Premier Support File Downloads.

[ddansereau]

I also have this issue - it has been turned into support - with a generic - we will get back to you response - but they never do. Can you get them to really look at things ?

Thanks

Dan

[Steven_L_Intel1]

As one of the support engineers who responds to issues, I would strongly disagree with your statement that we "never do" respond. What is your issue number? You will often get a generic acknowledgement, but you should get an actual follow-up within one business day - usually sooner.We look at ALL issues.

I would expect that your problem is not the same one in the original post, though the symptom may be the same.

[akrherz]

For anybody stumbling into this thread, you may want to check out:

https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/2007-January/023375.html

and

http://tornado.meso.com/wrf_forum/index.php?showtopic=1054

Both places appear to blame the Intel Compiler for this issue, allthough I had the same troubles with the PG compiler. Nothing is ever easy :)

[Steven_L_Intel1]

The latter thread has some good information, including a detailed response from Intel. I know that the compiler developers are very much engaged in working with WRF and some improvements have been added to the compiler recently in response. I encourage anyone having trouble using the Intel compiler with WRF, or any application, to contact Intel Premier Support.

[TimP]

I couldn't find any reply where anyone mentioned that ifort uses some of the same command line options as pgf90, but for entirely different purpose. Quoting from a 1 minute Google search

pgf90 -mp    Interpret OpenMP pragmas

This looks to me like ifort -openmp
True, a compiler shouldn't hang or break simply because it is given
options appropriate to another compiler, but I'm mystified how this 
thread goes on for months, seemingly implying that ifort is broken 
because it doesn't use the same options as pgf90.
ifort -mp is somewhat broken since 9.0, aside from the fact that it
doesn't mean OpenMP.  It's more like "use x87 code and avoid unsafe 
optimizations" but in combination with -ftz the meaning is inscrutable.

[Steven_L_Intel1]

Tim,

I admit I didn't look closely, but I didn't see that the use of -mp was itself an issue. The problem we know of with WRF is that it likes to call routines with lots (dozens or more) of multidimensional pointer arrays as arguments where the called routine expects a contiguous array. This means the compiler has to perform a run-time check on each array to see if it is really contiguous, and if not, make a copy. In the current compiler, this is all done in inline code and results in so much code that the optimizer sometimes can't deal with it.

One of the ways we're attacking this is to move the checking and copy code into a library routine, and in our testing, this helps a lot. There are still some issues and the compiler team is actively engaged in getting WRF to build and run successfully.