Dear Sirs,
I have ifort (IFORT) 12.1.3 20120212 on the Linux Debian server, and I would to suppress error message with runtime-checking flags.
The short F90 testing program is attached.
First, I got the code code execution proper :
:~/work/programming/various/floating_invalid/.ifort -i8 -g -O0 test.F90 test.F90(8): remark #7960: The floating overflow condition was detected while evaluating this operation; the result is an Infinity. [1.7976931348623157E+308]
Hello everybody,
I am interested in numerical problems and am trying the evaluate version of the Intel Fortran compiler.
I have been an old Fortran 77 user and I would like to switch back to fortran, since now it also adheres to most of the modern programming paradigms.
I am running the evaluate version of the Intel® Fortran Composer XE 2013 for OS X*, on my MacBookPro6,2; i5 2.4 GHz with 4GB RAM. I have tried the famous 'hello world' on XCode using a .f90 extension and it compiled and had been executed successfully.
After i installed Fortran Compiller for Linux XW 2011 and tried to compile a sample code a see this message:
:/opt/intel/composer_xe_2013.0.079/Samples/en_US/Fortran/vec_samples$ ifort matvec.f90
ifort: error while loading shared libraries: libintelremotemon.so: cannot open shared object file: No such file or directory
Looking for a solution, i unistalled the software and re installed in an other PC, with the next results
I am using ifort V13:
mac:~/bmad/bmad_dist/test> ifort --version
ifort (IFORT) 13.0.1 20121010
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
Running on OSX 10.7.4:
mac:~/bmad/bmad_dist/test> uname -a
Darwin rrsdhcp-10-32-35-37.redrover.cornell.edu 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
The test code to see the problem:
test_mod.f90:
--------------------
module test_mod
integer, save :: k2_4_row
end module
Hello,
with a program similair to the following example I ran into a very confusing problem:
A polymorphic array of pointers (containers with a reference "ptr" pointing to a polymorphic "obj"-type) is allocated and initialized. Then, calling a type-bound array valued function from any referenced "obj" in that array behind the first causes a segmentation fault, unless the array elements are accessed in a loop with index starting by 1.
More details are given below the code.
Dear forum,
Compiling and linking the following simple code with openmp options produces a crash:
Compiling and linking options: -L/opt/intel/composerxe-2013_update2.2.146/mkl/lib/intel64 -Wl,--start-group -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -Wl,--end-group -openmp -lpthread
program hello
implicit none
integer, parameter :: n=2000
real (kind=8),dimension (n,n) :: a,b,c
integer :: i,j
call random_number(a)
call random_number(b)
j=n/4
!$omp PARALLEL DO
Hi. I encounterd the classical error severe (174): SIGSEGV, segmentation fault occurred when i call the lapack subroutine GESDD on my fortran (90) program with the ifort composer 2013 Linux.
!! Decomposition en valeurs singulieres
M = Factor_long*taille; N = 2*N_Emetteurs_CBFM
Allocate( AA(M,N), S(MIN(M,N)),U(M,M),VT(N,N), WW(MIN(M,N)-1))
AA = Epatch; call GESDD(AA,S,U=U, VT=VT, JOBZ='A')
Results on :
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Hello,
the ifort compiler (version 13.1.0) refuses to compile the following code:
program t type b integer :: s end type b integer :: v type(b) :: x !$omp atomic capture v = x%s x%s = x%s+1 !$omp end atomic stop end program t
giving the following error message:
I have a routine that is called within a parallel loop. Among others, it is doing an internal WRITE to a string that is thread private.
Anyway this WRITE is causing program crashes ("double free or corruption") when running with multiple threads. So I must assume that WRITE is not thread safe, which is to be expected for file I/O but not for internal WRITE's. Can anybody confirm or comment ? Compiler version is 11.1.056.
