I am now writing a makefile for a code not written by me. It uses 'MKL'. But the difficult part for me is that I do not know which 'lib' to include.
Now when I try to generate a executable file, errors are:
undefined reference to XXX
I know I do not link the correct MKL lib to the code since I do not know subroutine is include in which lib.
What should I do? I do not want to link all the 'lib' files in $(MKLROOT)/lib.
I noticed that when issuing the command ifort -v it then launches another process for gcc. Is that to be expected or somehow tied to the bootstrapping of the Intel compiler installation? I am noticing very long compile times and found that a single instance of "ifort -v" can take up to 1.4 seconds to return. This seems to be contributing to the long compilation times, since the "ifort -v" command should be doing a version check and an license check. Any help on this would be appreciated.
For example:
$> ps -ef
UID PID PPID CMD
user1 353858 353847 sshd:user1@pts/29
user1 353883 353858 -bash
user1 354023 353883 /bin/bash ./testLicCO.sh
user1 379778 354023 ifort -v
user1 379783 379778 gcc -m64 -v -E /tmp/ifortdummyy5Z9FK.c
Hi All,
Just started playing with coarrays, and have this simple program
! This looks at a simple coarray version of doing a numerical gradient
program CoarrayTest2
implicit none
real(8), allocatable:: cntl(:), grad(:)[:], gradF77(:)
real(8) fcn
integer n[*]
character (len=10) junk
if (this_image() == 1 ) then
write(*,*) 'Number of images: ', num_images()
write(*,'(a,$)') 'Enter size of vector: '
read(*,*) n
end if
sync all
n = n[1] ! pass n to all images
allocate ( cntl(n), grad(n)[*], gradF77(n) )
cntl = 0. ! initialize vector
call fcnAndGrad (n, cntl, fcn, grad)
gradF77 = grad
write(*,*) 'grad(', this_image(), ') = ', gradF77
stop
end program CoarrayTest2
subroutine fcnAndGrad (n, cntl, fcn, grad)
implicit none
integer n ! it appears that you don't have to define n as coarray in subprogram if not using?
real(8) cntl(n)
real(8) fcn
real(8) grad(n)[*]
! local declarations
real(8) delA, fcnDel, aHold
integer i, myImg, noImg
myImg = this_image()
noImg = num_images()
call fcnValue (n, cntl, fcn) ! get the value of fcn for nominal a
do i=myImg, n, noImg
delA = real(i)
aHold = cntl(i)
cntl(i) = cntl(i) + delA ! perturb a vector element
call fcnValue (n, cntl, fcnDel)
grad(i)[1] = (fcnDel - fcn)/delA ! only modify grad on image 1
cntl(i) = aHold
end do
sync all ! wait for all images to finish
grad = grad[1] ! broadcast completed gradient to all images
return
end subroutine fcnAndGrad
subroutine fcnValue (n, cntl, fcn)
implicit none
integer n
real(8) cntl(n), fcn
fcn = sum(cntl)**2
return
end subroutine fcnValueThis compiles and runs fine under Parallel Studio XE 2016 Update 2 under Windows, and it compiles fine under same version of PSXE for Linux, but when I run it (Centos 7, 3.10.0-229.4.2.el7.x86_64), it produces segment faults, suc as:
Number of images: 8 Enter size of vector: 1 forrtl: severe (174): SIGSEGV, segmentation fault occurred In coarray image 1 Image PC Routine Line Source a.out 0000000000480D85 Unknown Unknown Unknown a.out 000000000047E9A7 Unknown Unknown Unknown a.out 0000000000455354 Unknown Unknown Unknown a.out 0000000000455166 Unknown Unknown Unknown a.out 0000000000435276 Unknown Unknown Unknown a.out 00000000004051E0 Unknown Unknown Unknown libpthread.so.0 00007FE3F0099100 Unknown Unknown Unknown libicaf.so 00007FE3F05AC554 Unknown Unknown Unknown a.out 00000000004041D9 Unknown Unknown Unknown a.out 000000000040399E Unknown Unknown Unknown libc.so.6 00007FE3EFCEAB15 Unknown Unknown Unknown a.out 00000000004038A9 Unknown Unknown Unknown application called MPI_Abort(comm=0x84000000, 3) - process 0 Fatal error in MPI_Win_lock: Wrong synchronization of RMA calls , error stack: MPI_Win_lock(167)...: MPI_Win_lock(lock_type=235, rank=4, assert=0, win=0xa0000000) failed MPIDI_Win_lock(3068): Wrong synchronization of RMA calls forrtl: error (69): process interrupted (SIGINT) In coarray image 4 Image PC Routine Line Source a.out 0000000000480D85 Unknown Unknown Unknown a.out 000000000047E9A7 Unknown Unknown Unknown a.out 0000000000455354 Unknown Unknown Unknown a.out 0000000000455166 Unknown Unknown Unknown a.out 0000000000435276 Unknown Unknown Unknown a.out 0000000000405A2E Unknown Unknown Unknown libpthread.so.0 00007FAD7567B100 Unknown Unknown Unknown libpthread.so.0 00007FAD756776D3 Unknown Unknown Unknown libmpi_mt.so.4 00007FAD74982585 Unknown Unknown Unknown libmpi_mt.so.4 00007FAD747DC7FB Unknown Unknown Unknown libmpi_mt.so.4 00007FAD74800751 Unknown Unknown Unknown libmpi_mt.so.4 00007FAD74AA2316 Unknown Unknown Unknown libicaf.so 00007FAD75B91F45 Unknown Unknown Unknown libicaf.so 00007FAD75B8F0FB Unknown Unknown Unknown a.out 000000000040429A Unknown Unknown Unknown a.out 000000000040399E Unknown Unknown Unknown libc.so.6 00007FAD752CCB15 Unknown Unknown Unknown a.out 00000000004038A9 Unknown Unknown Unknown application called MPI_Abort(comm=0x84000000, 3) - process 3 Fatal error in MPI_Win_lock: Wrong synchronization of RMA calls , error stack: MPI_Win_lock(167)...: MPI_Win_lock(lock_type=235, rank=5, assert=0, win=0xa0000000) failed MPIDI_Win_lock(3068): Wrong synchronization of RMA calls
Completely trivial coarray programs do compile and run under the linux, just not the one above. I suspect I have violated some coarray standard, but I can't see it yet, and I'm not sure why it runs fine under Windows 10 version of PSXE 2016.
thanks!
I'm getting a buffer overflow detected segfault when reading from stdin via a pipe on centos7.2. Works on ubuntu 14.04. Works on both when compiled with gfortran. The ubuntu machines has the compiler installed. SELinux is enforcing but same result when permissive.
test program
program a implicit none integer :: b read(*,*) b print *,b stop end
Compiled with (also tried -assume old_unit_star with no difference)
ifort -O0 -debug -static a.f90
when run with
echo 1 | ./a.out
produces segfault
*** buffer overflow detected ***: ./a.out terminated ======= Backtrace: ========= [0x4a368b] [0x4d7552] [0x4d74ee] [0x4d6f09] [0x4a958c] [0x4e6628] [0x4d6f8c] [0x4d6eed] [0x44dbdf] [0x44daac] [0x44ec19] [0x43b8bd] [0x4059ea] [0x401128] [0x4010ae] [0x49844c] [0x400f97] ======= Memory map: ======== 00400000-0057e000 r-xp 00000000 00:2d 110493698 /m/work/kgore4/a.a/a.out 0077d000-00783000 rw-p 0017d000 00:2d 110493698 /m/work/kgore4/a.a/a.out 00783000-007a7000 rw-p 00000000 00:00 0 021ec000-0220f000 rw-p 00000000 00:00 0 [heap] 7f28195fe000-7f28195ff000 rw-p 00000000 00:00 0 7ffe6e79d000-7ffe6e7be000 rw-p 00000000 00:00 0 [stack] 7ffe6e7d1000-7ffe6e7d3000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source a.out 000000000047CE95 Unknown Unknown Unknown a.out 000000000047AAB7 Unknown Unknown Unknown a.out 000000000044C2F4 Unknown Unknown Unknown a.out 000000000044C106 Unknown Unknown Unknown a.out 000000000042AD76 Unknown Unknown Unknown a.out 00000000004012F0 Unknown Unknown Unknown a.out 0000000000497DA0 Unknown Unknown Unknown a.out 000000000049EE77 Unknown Unknown Unknown a.out 00000000004A3690 Unknown Unknown Unknown a.out 00000000004D7552 Unknown Unknown Unknown a.out 00000000004D74EE Unknown Unknown Unknown a.out 00000000004D6F09 Unknown Unknown Unknown a.out 00000000004A958C Unknown Unknown Unknown a.out 00000000004E6628 Unknown Unknown Unknown a.out 00000000004D6F8C Unknown Unknown Unknown a.out 00000000004D6EED Unknown Unknown Unknown a.out 000000000044DBDF Unknown Unknown Unknown a.out 000000000044DAAC Unknown Unknown Unknown a.out 000000000044EC19 Unknown Unknown Unknown a.out 000000000043B8BD Unknown Unknown Unknown a.out 00000000004059EA Unknown Unknown Unknown a.out 0000000000401128 Unknown Unknown Unknown a.out 00000000004010AE Unknown Unknown Unknown a.out 000000000049844C Unknown Unknown Unknown a.out 0000000000400F97 Unknown Unknown Unknown
strace seems to be the same until getpid is called where ubuntu returned 8283 and went on to read the 1 and \n. centos returned 1997017 and went straight into the error above. I wonder if that pid tried to go into a 16bit int? /proc/sys/kernel/pid_max is 4194303 on centos7 and 32768 on ubuntu.
The GNU Scientific Library contains functions not available in the MLK library. The GSL website is
http://www.gnu.org/software/gsl/
Is it possible to use the GSL with the Intel Fortran compiler? How?
Dear Intel developer,
The ifort 16 compiler (16.0.0 20150815) seems to generate non-standard conforming code, when a polymorphic type with an overriden operator is stored as a pointer within a derived type. The self containing example below demonstrates the issue for the comparison operator: the code calls the comparison operator of the basetype, instead of the extended one. Similar error happens if the assignment operator is overriden, so I guess, the problem is operator independent.
Best regards,
Bállint
module typedefs
implicit none
type :: Base
contains
procedure :: isEqualTo => Base_isEqualTo
generic :: operator(==) => isEqualTo
end type Base
type, extends(Base) :: Extended
integer :: data
contains
procedure :: isEqualTo => Extended_isEqualTo
end type Extended
contains
function Base_isEqualTo(this, other) result(isEqual)
class(Base), intent(in) :: this
class(Base), intent(in) :: other
logical :: isEqual
select type (other)
type is (Base)
isEqual = .true.
class default
isEqual = .false.
end select
print *, "Base_isEqualTo:", isEqual
end function Base_isEqualTo
function Extended_isEqualTo(this, other) result(isEqual)
class(Extended), intent(in) :: this
class(Base), intent(in) :: other
logical :: isEqual
select type (other)
type is (Extended)
isEqual = (this%data == other%data)
class default
isEqual = .false.
end select
print *, "Extended_isEqualTo:", isEqual
end function Extended_isEqualTo
end module typedefs
program test
use typedefs
implicit none
type :: BasePtr
class(Base), pointer :: ptr
end type BasePtr
type(Extended) :: myExt1, myExt2
logical :: isEqual
type(BasePtr), allocatable :: array(:)
myExt1%data = 1
myExt2%data = 1
allocate(array(2))
allocate(array(1)%ptr, source=myExt1)
allocate(array(2)%ptr, source=myExt2)
! This should invoke Extended_isEqualTo, but it calls Base_isEqualTo instead
isEqual = (array(1)%ptr == array(2)%ptr)
print *, "Main:", isEqual
end program test
Actually can contribute an answer for once ... so thought would share
After the m_fcompxe_2016.2.049.dmg update in February the IFORT plugin was working in my Xcode 7.2 setup, yay happy days
Upgrade to Xcode 7.3 came out couple of weeks ago, IFORT plugin went away, sadness
Tried repair and other options from the .dmg ... but still no Fortran rules in Xcode.
Finally found this and now have IFORT working in latest Xcode again
> pwd
/Library/Application Support/Developer
> ls -l
drwxr-xr-x 3 7795 wheel 102 Feb 18 13:18 7.2
> sudo cp -pr 7.2 7.3
> ls -l
drwxr-xr-x 3 7795 wheel 102 Feb 18 13:18 7.2
drwxr-xr-x 3 7795 wheel 102 Feb 18 13:18 7.3
restarted Xcode and have Fortran build rules again
Good morning.
I have a hybrid OpenMP/MPI code.
It compiles and runs successfully. I compile with:
mpiifort -qopenmp -mt_mpi
When I use option: -check stack, I get:
Boundary Run-Time Check Failure for variable 'cluster_$MMODEL'
forrtl: error (76): Abort trap signal
What is this telling me?
Do you need to see the source file? The complete error trace?
Thank you very much.
Hello,
my program uses namelists to read input parameters and it behaves nicely except if I want to include a "/" in a string. An example that works is a var=value line like this, that sets the name of a file for I/O.
atmoname = "atmosphere_RTI.h5"
But if I want to include a path for the file:
atmoname = "sim1/atmosphere_RTI.h5"
Then the namelist parsing stops at that "/" and the namelist reading is incorrect.
I tried by starting the namelist with $params [...] $end instead of the standard ¶ms [...] / , but it still chokes at reading the "/" in the string.
Thanks,
Ángel de Vicente
Hi,
I'm running a job on a cluster and I receive a segmentation fault error. In the past, using traceback, I had received indications on where it was happening, but now I don't get any line information.
mpif90 -extend-source -r8 -c -O2 -g -traceback -warn noalign 3dpic_full_mpi.f
mpif90 -o 3dpic_full_mpi.exe 3dpic_full_mpi.o -lsiloh5 -lhdf5_hl -lhdf5 -lsz -lz -lm -lrt -ldl -lstdc++ -O2 -g -traceback -mcmodel medium
Do I have to change something?
Thanks
GB
module one integer, parameter::a=1 end module module two use one integer, parameter::b=2*a end module program main use two use one print*, 'a=', a print*, 'b= ',b end program
The above code is fine for debugging and running. Pay attention that module one is both included in program main and module two. But this way of using module repeatedly is always oK?
I believe I may have discovered a bug in the ifort version 15.0.3 for Mac OSX regarding exponentiating a number of type complex. The following code evaluates
(a + bi)^(1 + 0i):
program test
implicit none
integer, parameter :: dp=selected_real_kind(15, 307)
complex(dp) :: quantity
complex(dp) :: power
complex(dp) :: computed_result
real(dp), parameter :: zero = 0.0_dp
real(dp), parameter :: half = 0.5_dp
real(dp), parameter :: one = 1.0_dp
continue
! Values that produce correct result
!quantity = (0.5_dp,0.5_dp)
!power = (1._dp,0._dp)
! Values that produce the incorrect result
quantity = (-2.183392967490150E-003_dp,-2.183392967490262E-019_dp)
power = (one,zero)
computed_result = (quantity)**power
write(*,*) "original value = ",quantity
write(*,*) "computed value = ",computed_result
if (aimag(quantity) /= aimag(computed_result)) then
write(*,*) "FAIL: original value and computed value are not equal"
else
write(*,*) "PASS: original value and computed value are equal"
end if
end program test
I would expect that exponentiating a complex number by one would always return the original number, but that does not appear to be the case here. The issue remains regardless of the precision used, but does appear to be dependent on the magnitude of the complex quantity. Is this a bug in the compiler, or am I misinterpreting how the expression is evaluated?
The Intel® Parallel Studio XE 2017 Beta program launched today! The Intel® Parallel Studio XE 2017 Beta product is packed with cool new features and a couple of new products as well. You can register for the beta program by clicking on the link: "Register for Beta Program"
For more details on the beta program please refer to Intel® Parallel Studio XE 2017 Beta Program site. We appreciate your interest on getting early access to Intel® Parallel Studio XE 2017 product suite and provide feedback to help shape our products.
At the product management meeting today, 1 April, it was decided that the Fortran compiler shall now be offered as part of the Intel® Multi Language XDK development suite. This announcement fulfills our commitment to Fortran developers that they will continue getting access to the latest platforms, and positions our Fortran offering inside the ML-XDK as a one-stop shop for users looking to do complex calculations on their phones.
An example of a possible use case:
Please join me in congratulating the team, who have done immense due diligence and foundation work to make this possible.
Dear Intel developer,
The ifort compiler (16.0.0 20150815) refuses to compile valid Fortran 2003 code if this contains overridden assignment in a polymorphic type. The self containing code below demonstrates the issue. The compiler stops with the error message
test.F90(59): error #6197: An assignment of different structure types is invalid. [MYEXT1] pExt1 = myExt1
although an assignment operator for the polymorphic variable pExt1 is defined. Other Fortran 2003 compilers seem to have no problems with it.
Best regards,
Bálint
module typedefs
implicit none
type :: Base
contains
procedure :: assignFrom => Base_assignFrom
generic :: assignment(=) => assignFrom
end type Base
type, extends(Base) :: Extended
integer :: data
contains
procedure :: assignFrom => Extended_assignFrom
end type Extended
contains
subroutine Base_assignFrom(this, other)
class(Base), intent(inout) :: this
class(Base), intent(in) :: other
select type (other)
type is (Base)
continue
class default
print *, "Wrong data type for Base%assignFrom"
error stop 1
end select
end subroutine Base_assignFrom
subroutine Extended_assignFrom(this, other)
class(Extended), intent(inout) :: this
class(Base), intent(in) :: other
select type (other)
type is (Extended)
this%data = other%data
class default
print *, "Wrong data type for Extended%assignFrom"
error stop 1
end select
end subroutine Extended_assignFrom
end module typedefs
program test
use typedefs
implicit none
type(Extended) :: myExt1
class(Base), pointer :: pExt1
myExt1%data = -1
allocate(pExt1, source=myExt1)
pExt1 = myExt1
select type (pExt1)
type is (Extended)
print *, "VALUE:", pExt1%data
class default
print *, "Unexpected type"
end select
end program test
We are looking to port some vms fortran to linux using ifort. We use global commons on vms side in the standard way (use a BLOCK DATA fortran program, then link it using an .OPT file with
PSECT=COMMON_NAME,SHR,RD,MOD
SYMBOL_VECTOR=(COMMON_NAME=PSECT)
We then install the common
$INSTALL
INSTALL> replace TEST_COMMON/SHARED/OPEN/WRITE
I cannot find an example of the equivalent to this idea using linux and ifort. Any help would be appreciated (like a link to a simple example would be swell). Thank you
I discovered a bug in my code where a subroutine was expecting an array of integer*8 as an argument and was being passed an array of integer*4 and bad things started happening in the latter half of the array. After fixing this I began to wonder why the compiler did not catch this and save me from a morning of debugging. I tried compiler flags -check all and -warn all and still got nothing. Is there a way to check for the correctness of argument types? I'm using ifort 16.0.0 for Linux.
Hi,
I would like to detect high values in my program like 1e30. (real*4 or real*8)
With -fpe0 compiler option, the limit to detect overflows are 1e39 (real*4) and 1e69(real*8). Is it possible to configure this limit in order to decrease it ?
Best Regrds
Thierry
I have encountered a strange issue with tracebackqq in combination with symlinks, which causes the stack trace to terminate abnormally.
Consider a file tracebacktest.f90:
program tracebacktest use ifcore, only: tracebackqq call tracebackqq() end program tracebacktest
which is compiled and run as follows:
ifort -traceback tracebacktest.f90 -o tracebacktest/a.out ln -s tracebacktest/a.out test ./test
This causes a "Stack trace terminated abnormally". Similarly, if the symlink is in the same folder, the Routine/Line/Source columns only list "Unknown":
ifort -traceback tracebacktest.f90 -o a.out ln -s a.out test ./test
I'm guessing this is a compiler issue, but please correct me if it is due to incorrect use of symlinks. I'm using ifort version 16.0.2 on Linux .
Hello all.
I am trying to compile some code that works with Intel Fortran v.14 in Windows, but this time with Intel Fortran v.15 in Linux. I have got an allocation error (forrtl: severe (151): allocatable array is already allocated) at a certain function line with an allocation. If I am not wrong the runtime error occurs the second time the function is called. Apparently the issue is solved by adding a deallocation previously. It is extrange for me as I expected a local scope behavior for that variable, declared inside the function.
Does it make sense? Different behaviour in something like this for different platforms? Note: I am not experienced in Linux. Maybe I missed something.
Thanks and regards.
PD: Piece of the code:
function laminate_constructor_simple(material, stack, name)
...
type(Lamina), dimension(:), allocatable :: materials
...
if (allocated(materials)) deallocate(materials) ! added to work with Linux RHEL Intel Fortran !
allocate(materials(1)) ! line giving the error in Linux, working fine in Windows