[WRF 3.5.1] **Internal compiler error: segmentation violation signal raised** with -O3 flag

[WRF 3.5.1] **Internal compiler error: segmentation violation signal raised** with -O3 flag

Dear Sirs!

While building WRF 3.5.1, I encountered following errors:

mpif90 -f90=ifort -o module_bl_temf.o -c -O3 -ip -fp-model precise -w 
-ftz -align all -fno-alias -FR -convert big_endian    -I../dyn_em
-I../dyn_nmm   -I/home/dotcoder/src/WRFV3/external/esmf_time_f90
-I/home/dotcoder/src/WRFV3/main -I/
home/dotcoder/src/WRFV3/external/io_netcdf
-I/home/dotcoder/src/WRFV3/external/io_int
-I/home/dotcoder/src/WRFV3/frame -I/home/dotcoder/src/WRFV3/share
-I/home/dotcoder/src/WRFV3/phys -I/home/dotcoder/src/WRFV3/chem
-I/home/dotcoder/src/
WRFV3/inc -I/usr/local/netcdf-4.3.1.1//include  -i4  module_bl_temf.f90
catastrophic error: **Internal compiler error: segmentation violation
signal raised** 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_bl_temf.f90 (code 1)
make[3]: [module_bl_temf.o] Error 1 (ignored)

There are no build errors with -O2 or -O1 optimization flags.

My system is RHEL 5.10 x86_64.

Intel Compiler Version:
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on
Intel(R) 64, Version 14.0.2.144 Build 20140120
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.
FOR NON-COMMERCIAL USE ONLY

Please, let me know, what more information I should provide.

Best regards,
MB

12 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

That should be sufficient information for us to reproduce this and get a bug report started.

Thank you for sending this to us.

ron

a bug report has been opened.  We will keep you informed of status with this bug.

ron

The same error for me.

WRF 3.4.1 on Centos 6.5 x86_64

mpif90 -f90=ifort -o module_bl_temf.o -c -O3 -w -ftz -align all -fno-alias -fp-model precise -FR -convert big_endian   -I../dyn_em -I../dyn_nmm   -I/usr/Build_WRF/WRFV3/external/esmf_time_f90  -I/usr/Build_WRF/WRFV3/main -I/usr/Build_WRF/WRFV3/external/io_netcdf -I/usr/Build_WRF/WRFV3/external/io_int -I/usr/Build_WRF/WRFV3/frame -I/usr/Build_WRF/WRFV3/share -I/usr/Build_WRF/WRFV3/phys -I/usr/Build_WRF/WRFV3/chem -I/usr/Build_WRF/WRFV3/inc -I/usr/Build_WRF/LIBRARIES/netcdf-intel/include  -i4  module_bl_temf.f90

catastrophic error: **Internal compiler error: segmentation violation signal raised** 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_bl_temf.f90 (code 1)
make[3]: [module_bl_temf.o] Error 1 (ignored)

 

Output of command mpif90 -V is:

Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.144 Build 20140120
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.
FOR NON-COMMERCIAL USE ONLY

GNU ld version 2.20.51.0.2-5.36.el6 20100205
/usr/Build_WRF/LIBRARIES/mpich-intel/lib/libmpich.so: file not recognized: File format not recognized

 

Same issue.

Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.144 Build 20140120
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.
FOR NON-COMMERCIAL USE ONLY

CentOS release 6.5 (Final)

 

I confirmed this internal error has been fixed. We expect the fix to be in the upcoming update to Composer XE 2013 SP1 (Update 3) tentatively planned for later this month. Until that time, as Meder noted, you may work around the error by dropping the optimization for this source file to -O2.

This is confirmed to be fixed in ifort Version 14.0.3.174 Build 20140422 (package l_fcompxe_2013_sp1.3.174.tgz).

Patrick
 

Many thanks Patrick!

I'm going to update from ifort 14.0.2.144 to 14.0.3.174.

1) In order to update it is necessary to remove the existing version, before to execute ./install.sh ?

2) If I don't remove the existing version, will it remain onto the disk (consuming disk space) or it will be replaced by the newer version (saving disk space) ?

Marco

The linux ifort install doesn't remove previous versions; they remain accessible by sourcing the compilervars script inside the installation, until you run the uninstall script.  Only the symlinks (normally in /opt/intel/) are replaced automatically.

Hello,
compilation of WRFDA 3.6 with last Intel Composer XE 2013 Version 14.0.3.174 Build 20140422 fails.
No problems with older version of compiler,  14.0.2 or 14.0.1.
First error it's with compilation of CRTM_MW_Water_SfcOptics.f90 module :

ifort   -c  -O2  -convert big_endian  -free  -assume byterecl   CRTM_VIS_Water_SfcOptics.f90
ifort   -c  -O2  -convert big_endian  -free  -assume byterecl   CRTM_VIS_Land_SfcOptics.f90
ifort   -c  -O2  -convert big_endian  -free  -assume byterecl   CRTM_IR_Ice_SfcOptics.f90
ifort   -c  -O2  -convert big_endian  -free  -assume byterecl   CRTM_IR_Snow_SfcOptics.f90
ifort   -c  -O2  -convert big_endian  -free  -assume byterecl   CRTM_IR_Water_SfcOptics.f90
ifort   -c  -O2  -convert big_endian  -free  -assume byterecl   CRTM_IR_Land_SfcOptics.f90
ifort   -c  -O2  -convert big_endian  -free  -assume byterecl   CRTM_MW_Ice_SfcOptics.f90
ifort   -c  -O2  -convert big_endian  -free  -assume byterecl   CRTM_MW_Snow_SfcOptics.f90
ifort   -c  -O2  -convert big_endian  -free  -assume byterecl   CRTM_MW_Water_SfcOptics.f90
CRTM_MW_Water_SfcOptics.f90(87): error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IVAR_TYPE]
  END TYPE iVar_type
-----------^
CRTM_MW_Water_SfcOptics.f90(87): error #6148: The name on this END TYPE statement is different from the name on the corresponding derived type statement   [IVAR_TYPE]
  END TYPE iVar_type
-----------^
CRTM_MW_Water_SfcOptics.f90(196): error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IVAR_TYPE]
    TYPE(iVar_type),              INTENT(IN OUT) :: iVar
---------^
CRTM_MW_Water_SfcOptics.f90(401): error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IVAR_TYPE]
    TYPE(iVar_type),              INTENT(IN)     :: iVar
---------^
CRTM_MW_Water_SfcOptics.f90(599): error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IVAR_TYPE]
    TYPE(iVar_type),              INTENT(IN)     :: iVar
---------^
CRTM_MW_Water_SfcOptics.f90(232): error #6404: This name does not have a type, and must have an explicit type.   [IVAR]
               iVar%FastemX_Var                       , &  ! Internal variable output
---------------^
CRTM_MW_Water_SfcOptics.f90(232): error #6460: This is not a field name that is defined in the encompassing structure.   [FASTEMX_VAR]
               iVar%FastemX_Var                       , &  ! Internal variable output
--------------------^
CRTM_MW_Water_SfcOptics.f90(255): error #6460: This is not a field name that is defined in the encompassing structure.   [LF_MWSSEM_VAR]
                 iVar%LF_MWSSEM_Var         )  ! Internal variable output
----------------------^
CRTM_MW_Water_SfcOptics.f90(267): error #6460: This is not a field name that is defined in the encompassing structure.   [DEH_DWINDSPEED]
                        iVar%dEH_dWindSpeed(i)   , & ! Output
-----------------------------^
CRTM_MW_Water_SfcOptics.f90(268): error #6460: This is not a field name that is defined in the encompassing structure.   [DEV_DWINDSPEED]
                        iVar%dEV_dWindSpeed(i)     ) ! Output
-----------------------------^
CRTM_MW_Water_SfcOptics.f90(267): error #6638: An actual argument is an expression or constant; this is not valid since the associated dummy argument has the explicit INTENT(OUT) or INTENT(INOUT) attribute.   [IVAR]
                        iVar%dEH_dWindSpeed(i)   , & ! Output
------------------------^
CRTM_MW_Water_SfcOptics.f90(268): error #6638: An actual argument is an expression or constant; this is not valid since the associated dummy argument has the explicit INTENT(OUT) or INTENT(INOUT) attribute.   [IVAR]
                        iVar%dEV_dWindSpeed(i)     ) ! Output
------------------------^
CRTM_MW_Water_SfcOptics.f90(434): error #6404: This name does not have a type, and must have an explicit type.   [IVAR]
               iVar%FastemX_Var                            , &  ! Internal variable input
---------------^
CRTM_MW_Water_SfcOptics.f90(462): error #6460: This is not a field name that is defined in the encompassing structure.   [DEH_DTS]
          SfcOptics_TL%Emissivity(i,2) = (iVar%dEH_dTs(i)*Surface_TL%Water_Temperature) + &
-----------------------------------------------^
CRTM_MW_Water_SfcOptics.f90(464): error #6460: This is not a field name that is defined in the encompassing structure.   [DEV_DTS]
          SfcOptics_TL%Emissivity(i,1) = (iVar%dEV_dTs(i)*Surface_TL%Water_Temperature) + &
-----------------------------------------------^
CRTM_MW_Water_SfcOptics.f90(635): error #6404: This name does not have a type, and must have an explicit type.   [IVAR]
               iVar%FastemX_Var                             , &  ! Internal variable input
---------------^
compilation aborted for CRTM_MW_Water_SfcOptics.f90 (code 1)

follows a plethora of errors.
I think it's a bug of the 'compiler update 3

 

Andrea

Andrea,

I've reported that CRTM bug to Intel as well with GEOS-5. I think they're still trying to duplicate it (it's due to a bad module compile early on, I think, so it requires a *lot* of prerequisite files...). It occurs with 14.0.3 and up (all Intel 15 as well). I have a "workaround" in the sense you avoid the bad iVar_type, but it is a compiler bug in my opinion.

Matt

Matt Thompson

Matt,

Any chance you could share your work around? 

 

Dylan

Leave a Comment

Please sign in to add a comment. Not a member? Join today