Quantcast
Channel: Intel® Software - Intel® Fortran Compiler for Linux* and macOS*
Viewing all 2746 articles
Browse latest View live

Valgrind error with very simple program

$
0
0

The following simple program

Program Main
  implicit none
  write(*,*) "123"
End Program

gives some errors when run through valgrind.

Here is the output

$ ifort -v
ifort version 16.0.2

$ ifort -g main.f90

$ valgrind -v --track-origins=yes --leak-check=full ./a.out
==25729== Memcheck, a memory error detector
==25729== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==25729== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==25729== Command: ./a.out
==25729==
--25729-- Valgrind options:
--25729--    -v
--25729--    --track-origins=yes
--25729--    --leak-check=full
--25729-- Contents of /proc/version:
--25729--   Linux version 4.4.2-301.fc23.x86_64 (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) ) #1 SMP Tue Feb 23 19:00:38 UTC 2016
--25729--
==25729==
==25729== TO CONTROL THIS PROCESS USING vgdb (which you probably
==25729== don't want to do, unless you know exactly what you're doing,
==25729== or are doing some strange experiment):
==25729==   /usr/lib64/valgrind/../../bin/vgdb --pid=25729 ...command...
==25729==
==25729== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==25729==   /path/to/gdb ./a.out
==25729== and then give GDB the following command
==25729==   target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=25729
==25729== --pid is optional if only one valgrind process is running
==25729==
--25729-- REDIR: 0x4019b90 (ld-linux-x86-64.so.2:strlen) redirected to 0x3809e2b1 (???)
--25729-- Reading syms from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so
--25729-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
==25729== WARNING: new redirection conflicts with existing -- ignoring it
--25729--     old: 0x04019b90 (strlen              ) R-> (0000.0) 0x3809e2b1 ???
--25729--     new: 0x04019b90 (strlen              ) R-> (2007.0) 0x04c2bce0 strlen
--25729-- REDIR: 0x40198f0 (ld-linux-x86-64.so.2:index) redirected to 0x4c2b880 (index)
--25729-- REDIR: 0x4019b10 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c2cd90 (strcmp)
--25729-- REDIR: 0x401a850 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c2ffb0 (mempcpy)
--25729-- Reading syms from /usr/lib64/libm-2.22.so
--25729-- Reading syms from /usr/lib64/libpthread-2.22.so
--25729-- Reading syms from /usr/lib64/libc-2.22.so
--25729-- Reading syms from /usr/lib64/libgcc_s-5.3.1-20151207.so.1
--25729--    object doesn't have a symbol table
--25729-- Reading syms from /usr/lib64/libdl-2.22.so
--25729-- REDIR: 0x53e2de0 (libc.so.6:strcasecmp) redirected to 0x4a2372e (_vgnU_ifunc_wrapper)
--25729-- REDIR: 0x53de670 (libc.so.6:strcspn) redirected to 0x4a2372e (_vgnU_ifunc_wrapper)
--25729-- REDIR: 0x53e50d0 (libc.so.6:strncasecmp) redirected to 0x4a2372e (_vgnU_ifunc_wrapper)
--25729-- REDIR: 0x53e0b00 (libc.so.6:strpbrk) redirected to 0x4a2372e (_vgnU_ifunc_wrapper)
--25729-- REDIR: 0x53e0e90 (libc.so.6:strspn) redirected to 0x4a2372e (_vgnU_ifunc_wrapper)
--25729-- REDIR: 0x53e256b (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a2372e (_vgnU_ifunc_wrapper)
--25729-- REDIR: 0x53e0810 (libc.so.6:rindex) redirected to 0x4c2b560 (rindex)
--25729-- REDIR: 0x53d7900 (libc.so.6:malloc) redirected to 0x4c28c7f (malloc)
--25729-- REDIR: 0x53deb10 (libc.so.6:strlen) redirected to 0x4c2bc20 (strlen)
--25729-- REDIR: 0x53e9b40 (libc.so.6:strchrnul) redirected to 0x4c2fae0 (strchrnul)
--25729-- REDIR: 0x53d83f0 (libc.so.6:calloc) redirected to 0x4c2aa02 (calloc)
--25729-- REDIR: 0x477140 (NONE:_intel_fast_memcpy) redirected to 0x4c2e4a0 (_intel_fast_memcpy)
==25729== Conditional jump or move depends on uninitialised value(s)
==25729==    at 0x47C46D: __intel_sse2_strcpy (in /home/Tests/a.out)
==25729==    by 0x446CA0: for__open_proc (in /home/Tests/a.out)
==25729==    by 0x4338BC: for__open_default (in /home/Tests/a.out)
==25729==    by 0x40900D: for_write_seq_lis (in /home/Tests/a.out)
==25729==    by 0x4026ED: MAIN__ (main.f90:5)
==25729==    by 0x40266D: main (in /home/Tests/a.out)
==25729==  Uninitialised value was created by a stack allocation
==25729==    at 0x446B5D: for__open_proc (in /home/Tests/a.out)
==25729==
==25729== Conditional jump or move depends on uninitialised value(s)
==25729==    at 0x47C46D: __intel_sse2_strcpy (in /home/Tests/a.out)
==25729==    by 0x42C6F5: for__add_to_lf_table (in /home/Tests/a.out)
==25729==    by 0x4484F3: for__open_proc (in /home/Tests/a.out)
==25729==    by 0x4338BC: for__open_default (in /home/Tests/a.out)
==25729==    by 0x40900D: for_write_seq_lis (in /home/Tests/a.out)
==25729==    by 0x4026ED: MAIN__ (main.f90:5)
==25729==    by 0x40266D: main (in /home/Tests/a.out)
==25729==  Uninitialised value was created by a stack allocation
==25729==    at 0x446B5D: for__open_proc (in /home/Tests/a.out)
==25729==
 123
--25729-- REDIR: 0x53d7c60 (libc.so.6:free) redirected to 0x4c29d79 (free)
==25729==
==25729== HEAP SUMMARY:
==25729==     in use at exit: 32 bytes in 1 blocks
==25729==   total heap usage: 8 allocs, 7 frees, 12,751 bytes allocated
==25729==
==25729== Searching for pointers to 1 not-freed blocks
==25729== Checked 242,248 bytes
==25729==
==25729== LEAK SUMMARY:
==25729==    definitely lost: 0 bytes in 0 blocks
==25729==    indirectly lost: 0 bytes in 0 blocks
==25729==      possibly lost: 0 bytes in 0 blocks
==25729==    still reachable: 32 bytes in 1 blocks
==25729==         suppressed: 0 bytes in 0 blocks
==25729== Reachable blocks (those to which a pointer was found) are not shown.
==25729== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==25729==
==25729== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
==25729==
==25729== 1 errors in context 1 of 2:
==25729== Conditional jump or move depends on uninitialised value(s)
==25729==    at 0x47C46D: __intel_sse2_strcpy (in /home/Tests/a.out)
==25729==    by 0x42C6F5: for__add_to_lf_table (in /home/Tests/a.out)
==25729==    by 0x4484F3: for__open_proc (in /home/Tests/a.out)
==25729==    by 0x4338BC: for__open_default (in /home/Tests/a.out)
==25729==    by 0x40900D: for_write_seq_lis (in /home/Tests/a.out)
==25729==    by 0x4026ED: MAIN__ (main.f90:5)
==25729==    by 0x40266D: main (in /home/Tests/a.out)
==25729==  Uninitialised value was created by a stack allocation
==25729==    at 0x446B5D: for__open_proc (in /home/Tests/a.out)
==25729==
==25729==
==25729== 1 errors in context 2 of 2:
==25729== Conditional jump or move depends on uninitialised value(s)
==25729==    at 0x47C46D: __intel_sse2_strcpy (in /home/Tests/a.out)
==25729==    by 0x446CA0: for__open_proc (in /home/Tests/a.out)
==25729==    by 0x4338BC: for__open_default (in /home/Tests/a.out)
==25729==    by 0x40900D: for_write_seq_lis (in /home/Tests/a.out)
==25729==    by 0x4026ED: MAIN__ (main.f90:5)
==25729==    by 0x40266D: main (in /home/Tests/a.out)
==25729==  Uninitialised value was created by a stack allocation
==25729==    at 0x446B5D: for__open_proc (in /home/Tests/a.out)
==25729==
==25729== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

So, the code being so trivial, I guess that these are false positive.

I am correct ?

Is there a way to get ride of them ?

Thanks


Using Intel Fortran in Amazon AWS EC2 instances

$
0
0

Do Intel Fortran and C++ compilers work in Amazon AWS EC2 instances? What is the best type of license to purchase for use in EC2 instances? Any advice would be greatly appreciated.

Pointer assignment

$
0
0

 

 

Hi,

I am working on profiling and optimising an application. The application is written in Fortran 2003 and I am using the Intel ifort (IFORT) 16.0.0 20150815 version to build. I have two questions.

In the my profile the following code which has assignment of a pointer takes more than 10 secs (total application runs for 200 seconds). The profile of this function increases with number of threads. The compiler seems to be doing more than just pointer assignment.  

My profile shows prominently a function __intel_ssse3_rep memcpy ( or _wordcopy_fwd_aligned ) when compiled with O3 (or O1) optimisation option. What is happening here?

function get_master_dofmap(self,cell) result(map)
  implicit none
  class(master_dofmap_type), target, intent(in) :: self
  integer,                           intent(in) :: cell
  integer, pointer                              :: map(:)

  map => self%dofmap(:,cell)
  return
end function get_master_dofmap

 

Also I see that for calls to functions with pointers to array as arguments, the compiler warns that temporary arrays are created.

forrtl: warning (406): fort: (1): In call to COORDINATE_JACOBIAN, an array temporary was created for argument #6

subroutine coordinate_jacobian(ndf, ngp_h, ngp_v, chi_1, chi_2, chi_3, diff_basis, jac, dj)
!-------------------------------------------------------------------------------
! Compute the Jacobian J^{i,j} = d chi_i / d \hat{chi_j} and the 
! derterminant det(J)
!-------------------------------------------------------------------------------

integer,          intent(in)  :: ndf, ngp_h, ngp_v
real(kind=r_def), intent(in)  :: chi_1(ndf), chi_2(ndf), chi_3(ndf)
real(kind=r_def), intent(in)  :: diff_basis(3,ndf,ngp_h,ngp_v)
real(kind=r_def), intent(out) :: jac(3,3,ngp_h,ngp_v)
real(kind=r_def), intent(out) :: dj(ngp_h,ngp_v)
call coordinate_jacobian( ndf, &
                              1,   &
                              1,   &
                              chi_cell(1,:), &
                              chi_cell(2,:), &
                              chi_cell(3,:), &
                              dgamma, &
                              jac, &
                              dj)

How can I avoid them?

MAX,MIN,ABS,MOD functions for long integer

$
0
0

Hello

Is there any counterpart to the Fortran functions MAX,MIN,ABS,MOD which would return a long integer (integer(8)) number upon return

Thanks

Adam

 

iostat 31 on write

$
0
0

Hi,

I am migrating a legacy fortran program from HP UX f90 to Redhat Linux using the ifort compiler.  The program is throwing an error on the first attempt to write to a direct access file on the linux version. iostat is 31. The output file is opened without error. The program runs correctly on UNIX.  I’ve managed to isolate the code into a small test program provided below.  What is causing this error?  Please help, I've been struggling with this for a couple of days now.

      program wtf
c     test program to isolate iostat=31 error when writing to idu on Linux using ifort
      integer idu,ierr,ipos
      integer buffsizebytes
      parameter (buffsizebytes=8)
      real rnum
      idu=37
c     open the output file
      open (idu,file='P5904.ft37',access='direct',recl=buffsizebytes,
     +form='unformatted',iostat=ierr)
      if (ierr.ne.0) then
        write (6,*)'Error ',ierr,' opening P5904.ft37'
        stop
      endif
      inquire(unit=idu,nextrec=ipos)
      rnum = 1.0
      write(unit=idu,err=999,iostat=ierr) rnum
      if(iostat == 0) then
        write(6,*) 'write to ',idu,' at position ',ipos,' successful!'
      endif
      goto 1000
  999 write(6,*) 'Error writing to ',idu,'. iostat=',ierr
 1000 end

 

Confusion with FORTRAN 2008 OO

$
0
0

The more I use F08 object orientation, the more confused I get... I was pretty sure I had tested this previously with Intel compiler and it worked (about 4 years ago) but now it refuses to!

Imagine a simple linked list implementation:

TYPE :: List_T
  CLASS(List_T), POINTER :: next => null()
  CLASS(List_T), POINTER :: prev => null()

  CONTAINS
    PROCEDURE, PUBLIC :: insert  => ListInsert
    PROCEDURE, PUBLIC :: first   => ListFirst
    PROCEDURE, PUBLIC :: last    => ListLast
    PROCEDURE, PUBLIC :: found   => ListFound
    PROCEDURE, PUBLIC :: append  => ListAppend
    PROCEDURE, PUBLIC :: print   => ListPrint
    FINAL :: ListFree
END TYPE List_T

SUBROUTINE ListAppend(this,new)
  CLASS(List_T), INTENT(INOUT), TARGET  :: this
  CLASS(List_T), INTENT(IN),    POINTER :: new
  ! do stuff here
END SUBROUTINE ListAppend

Then I create a type ExtList_T which extends List_T. I don't want to redefine the "append" function because it is exactly the same, I just want to inherit it. But then if I try something like

TYPE(ExtList_T), POINTER  :: instance1
TYPE(ExtList_T), POINTER  :: instance2

ALLOCATE(instance1)
ALLOCATE(instance2)
! put stuff inside each
CALL instance1%append(instance2)

Intel Compiler complains "error #6633: The type of the actual argument differs from the type of the dummy argument.   [INSTANCE2]"

gfortran compiles that fine. Am I doing something conceptually wrong? Isn't downcasting like that allowed in Fortran?

Problem with structure constructor

$
0
0

ifort produces an error compiling the following code:

module m
 implicit none

 type, abstract :: c_a
 end type c_a

 type, extends(c_a), abstract :: c_b
 !type, abstract :: c_b ! removing the ancestor solves the problem
  real, pointer :: x => null()
 end type c_b

 type, extends(c_b) :: t_c
  logical :: l
 end type t_c

end module m

program p
 use m
 implicit none

 real, target :: r
 ! renaming/removing the variable x solves the problem
 type(t_c),  parameter   :: x = t_c( l=.false. )
 class(c_b), allocatable :: y

  allocate( y , source=t_c( l=.true. , x=r ) )

  select type(y); type is(t_c)
  write(*,*) "y%l = ", y%l
  end select

end program p

$ ifort test.f90 -o test
test.f90(27): error #6593: The number of expressions in a structure constructor differs from the number of components of the derived type.   [C_B]
  allocate( y , source=t_c( l=.true. , x=r ) )

I am using ifort Version 16.0.2.181 Build 20160204

The code is correct as far as I can tell, and gfortran compiles it.

Also, notice that altering the code as indicated in the comments makes the problem disappear - or at least the symptoms.

Marco

Dependency Generation Issues

$
0
0

We have a fairly complicated piece of software with thousands of files, multiple libraries/executables/build configurations (many implemented with #ifdef blocks), and a mixture of F77/F90/F2003 code (some of it 20+ years old) with hundreds of common blocks and dozens of modules.  I'm trying to improve our build system on Linux.  I'm using Intel Composer XE 2013 (we may be switching to 2016 soon) and GNU Make from GCC 4.4.7.  I've run into a few problem that I'll list below.

1) We have a build order generator written in perl that deals with the module dependencies, but I'd like to use the ifort dependency generation to determine the build order.  If I run, for example, "ifort -P -gen-dep=file.d file.F90" (along with all of our include paths, preprocessor definitions, etc.) It does generate dependency files with rules for objects, includes, etc. but it doesn't create rules for *.mod file dependencies (even if I use the -module option).  If I don't use the -P option, it does generate the *.mod make rules, but usually bombs during compilation because it can't find *.mod.  Is there a way to generate module dependency rules with ifort without actually compiling?

2) When generating dependency Make rules for #include files and *.mod files, the targets of the rules do not have absolute paths, which breaks Make's dependency trees. Example:

!   file "BLOCK.CMN"
INTEGER i
COMMON / CBLOCK / i

!   file file.F90
MODULE MOD_A
   IMPLICIT NONE
   INTEGER a
CONTAINS
   SUBROUTINE set(aIN,iIN)
#include "BLOCK.CMN"
      INTEGER, INTENT(IN) :: aIN, iIN
      a = aIN
      i = iIN
   END SUBROUTINE set
END MODULE MOD_A

If the previous file is compiled with the command...

ifort -c -I/path/to/includes -module /path/to/mod/files -gen-dep -o /path/to/objects/file.o /path/to/source/file.F90

... it generates the following Make rules...

file.o : /path/to/includes/BLOCK.CMN
mod_a.mod: /path/to/source/file.F90
/path/to/objects/file.o : /path/to/source/file.F90

... instead of ...

/path/to/objects/file.o : /path/to/includes/BLOCK.CMN
/path/to/mod/files/file.mod : /path/to/source/file.F90
/path/to/objects/file.o : /path/to/source/file.F90

If I understand it correctly, Make won't resolve the fact that "/path/to/objects/file.o" is the same as "file.o". The problem this causes is that you can modify "BLOCK.CMN" and nothing will get rebuilt.

I can probably provide an full working example if needed. Thanks!


More Polymorphic Pointers - Upcasting

$
0
0

Hello there once again,

I have been playing with some upcasting (and downcasting) with Fortran's polymorphism these days, but I am not really sure about what is allowed.

I am basically creating a derived type ExtList_T which extends List_T. The pointers are downcast and then upcast again - or return a nullpointer in case it is not possible to upcast. The part of interest is:

TYPE(ExtList_T), POINTER  :: instance1
TYPE(ExtList_T), POINTER  :: instance2
CLASS(ExtList_T), POINTER  :: ptr_ext
CLASS(List_T), POINTER  :: ptr_lst

(...)

ptr_ext => Cast_ExtList(instance1%last())

PRINT *,"Worked? ",ASSOCIATED(ptr_ext)

ptr_lst => instance1%last()
ptr_ext => Cast_ExtList(ptr_lst)

PRINT *,"Worked? ",ASSOCIATED(ptr_ext)

I expected it to print "Worked?   T" in both occasions, but only the second one gets printed properly with Intel Fortran. gfortran prints the expected result in both cases.

The sample code follows attached.
Thanks in advance for your attention!

AttachmentSize
Downloadapplication/octet-streammini.f901.16 KB
Downloadapplication/octet-streamminimain.f90740 bytes

Sequential WRITE with variable record length

$
0
0

I have been trying to read and write some files in Fortran, but my knwoledge on IO is pretty limited. I have been opening the file with

OPEN(NEWUNIT=file_unit, FILE=filename, STATUS='replace', IOSTAT=file_status, &
                         ACTION='write', ACCESS='sequential', FORM="unformatted")

and writes are in a loop with

WRITE(file_unit, IOSTAT=file_status) var1,var2,var3...

That's all fine for writing and I get no errors. The problem is that I don't know the size of the records; the type of the variables var1 var2 and var3 MAY change between writes. When trying to read, I open the file in exactly the same way, but when I try to read

CHARACTER(LEN=1024) :: longbuf

(...)

READ(file_unit, IOSTAT=file_status) longbuf

I get IOSTAT=67 although it does read the file properly: It reads only "one record" and stores it in the longbuf variable. After going through all the records in the file it gives me the proper EOF IOSTAT which is -1.

My question is, am I doing this in the best way? What does the IOSTAT 67 stand for? I've seen that there is a IS_IOSTAT_EOF function in F2003, are there other similar intrinsic?

Thanks in advance!

C++ Code written in VS2010 is working in Linux but not in windows

$
0
0

Hi

I am working on VS2010 mixed-programing and use the Intel Compiler / VisualStudio (Intel Parallel 2015) to compile my project in VS 2010.

#include <conio.h>
#include <string.h>

//#define readfile readfile_

extern void readfile(char*, int*);

int main()
{
    int n, count;
    char Fname[9];
    char Name[10];

    strcpy(Fname,"AMIN.for");
    fprintf( stderr, "%s\n", Fname);

    readfile( Fname, &n , strlen (Fname));
    fprintf( stderr, "n = %d\n", n);
//  fprintf( stderr, "%s\n", Name);
    getch();
    return 0;
}
subroutine - Lib fortran:

      subroutine readfile( fname1, m )
      character fname1*(*)
      integer m
      integer iounit,i
      iounit=15
      write(*,*) fname1
c10   format (a9)
      open(iounit,file = fname1,action='read')
      read (iounit,*) m
c20    format (i10)
      write(*,*) m
      close(iounit)
      return
      end subroutine

My program is compiling on Linux but not compiling in windows(VS) I don't know what happen exactly. Thanks 

AttachmentSize
Downloadimage/pngScreenshot (51).png188.2 KB

Mixed Language linking capitalization

$
0
0

Dear fellow developers,

I've recently came across a compilation problem when using the HDF5 library with the Intel compiler suite (ifort 16.0). I'm using a rather complex setup on Ubuntu 14.04:

What I did
1) Install MPICH using the Intel compilers
2) Install HDF5 using the Intel compilers with MPICH wrappers
3) Install PETSc using the MPICH compilers and telling PETSc where HDF5
is located
4) Trying to compile my application with the PETSc makefile. That Fails :(

I'm pretty sure that I link against the 4 libraries from HDF5 in the correct order. The location to the shared objects are given with -L and even as -Wl,rpath.

However, I get a bunch of these messages:

/nethome/storage/raid4/m.diehl/DAMASK/code/HDF5_Utilities.f90:58:
undefined reference to `h5lib_MP_h5open_f_'

even though the verbose compiler command
-Wl,--verbose
tells that it finds the libraries:

attempt to
open /opt//hdf5-1.8.16/Intel/16.0/MPICH/3.2/lib/libhdf5hl_fortran.so
succeeded
-lhdf5hl_fortran
(/opt//hdf5-1.8.16/Intel/16.0/MPICH/3.2/lib/libhdf5hl_fortran.so)

Inspecting the library with readelf shows that the missing references are in there:

readelf -Ws /opt/hdf5-1.8.16/Intel/16.0/MPICH/3.2/lib/libhdf5_fortran.so | grep -i h5lib_MP_h5open_f_'
   916: 0000000000024600    80 FUNC    GLOBAL DEFAULT   12 h5lib_mp_h5open_f_'
   969: 0000000000024600    80 FUNC    GLOBAL DEFAULT   12 h5lib_mp_h5open_f_'

What puzzles me is the capitalization: The linker is searching for all lowercase functions, except for the added "_MP_". However in the library, only small letters are used.

Did anyone encounter similar problems (not only related to HDF5) before? I assume linking is case sensitive due to its strong connection to C/C++ rather than to Fortran. HDF5 is written in C.

P.S using the GNU compiler suite (v 5.3) in exactly the same order works fine

 

 

subroutine argument real to integer conversion

$
0
0

Hey,

I am migrating a legacy HP UX f90 program to a Linux Intel ifort program.  There is a call to a subroutine where one of the actual arguments is an integer array output from the subroutine but the subroutine dummy argument is a real array.  This works fine on the legacy unix program but does not work when I try it on Linux. It compiles and runs but when the code later tries to use a value from this integer array, the value is wrong which ultimately causes an error found during a check. I tried to find a compiler option to allow this conversion to work with ifort but I had no luck.  Is there such an option?  Thanks!

Sub call where the loc array is of type integer.

        call ntran(idr(ilt),2,4096,loc(1,1,1,1,ilt),lerr,22)

Sub declaration where the ARRAY array is of type real and dynamically sized in ntran.  Array is populated in ntran and passed back to the calling program.

      SUBROUTINE NTRAN(IU,IOP,NW,ARRAY,LERR,IWAIT)                            

 

will -heap-arrays flag be ignored if -openmp is used?

$
0
0

Will -heap-arrays flag be ignored if -openmp is used for compilation?

BTW, will -heap-array cause any issue with thread-safety?

 

Thanks, 

Installation and environment variables.

$
0
0

I use an iMac running OSX 10.11.4. I have Xcode and Command Line Tools installed.Yesterday I installed IntelŪ Parallel Studio XE 2015 Composer Edition for Fortran OS X evaluation. The installation appeared to be successful. 

As I understand it, I am required to set environment variables. At the command line I entered: which ifort. This gave the location as:

/opt/intel/composer_xe_2015.3.187/bin

However: 

source /opt/intel/composer_xe_2015.3.187/bin/compilervars.csh intel64

and

./opt/intel/composer_xe_2015.3.187/bin/compilervars.csh intel64

produces  line 35: syntax error: unexpected end of file.

What am I required to do? Should I have a licence? No licence was sent to me.


Using a different floating point model for offload section

$
0
0

Hi,

I am working on an application, where we can specify all the compiler flags, floating point models (eg -fp-model source etc.) etc, in the Macros file.

In the code, I am offloading a certain section to the Xeon Phi. Is it possible to use a different floating point model for this computation on Xeon Phi?

For example, say the Macros file has the flag -fp-model source, and I want to use -fp-model fast=2 -fimf-precision=high for the computation on Xeon Phi.

 

Thanks,

Amlesh

Silent truncation of character parameters

$
0
0

There appears to be a silent truncation of character parameters under certain circumstances.  This may be related to some internal limit.  However, I do not get any warning for this truncation.

Sample code:

! Silent truncation of character parameters
! integer, parameter :: huge_2 = 7197_2  ! still ok with 7196
  integer, parameter :: huge_2 = huge(0_2)
  character(    huge_2      ), parameter :: u = 'abc'
  character(    huge(0_2)   ), parameter :: v = 'abc'
  character(int(huge(0_2),4)), parameter :: w = 'abcdef'
  character(    huge(0_2)   )            :: b = 'abc'
  integer, parameter :: huge_1 = huge(0_1)
  character(    huge_1      ), parameter :: x = 'abc'
  character(    huge(0_1)   ), parameter :: y = 'abc'
  character(    huge(0_1)+0 ), parameter :: z = 'abcdef'
  character(    huge(0_1)   )            :: a = 'abc'
  print*, huge_2, len(u), len(v), len(w), len (b)
  print*, huge_1, len(x), len(y), len(z), len (a)
end

This prints:

 

% ifort -V
Intel(R) Fortran Compiler XE for applications running on IA-32, Version 15.0.5.223 Build 20150805
% ./a.out
       32767           3           3           6       32767
         127         127         127         127         127

I'd expected 32767 for all columns of the first line.  There appears to be a limit as indicated in the above code sample.

I'm not going to argue that the above code is very useful, but it might be helpful to generate some warning for the user.

 

OpenMP Collapse(n)

$
0
0

Intel Compiler looks to be behaving oddly for the loop structure below when compared to GCC. 

!$OMP DO collapse(3) private(l,j,k)

DO l=1,n

    DO k=1,n

      DO j=1,n

                        a (j,k,l)=a(j,k,l)*b(j,k,l)

                ENDDO

         ENDDO  

ENDDO

!$OMP END DO

I am using the vectorization flags (-xavx).

Are there any Best Known Methods when using the 'collapse' clause with Intel Fortran Compilers with Vectorization?

Regards,

Sid

 

unlimited polymorphic parameter and transfer intrinsic

$
0
0

Trying to use polymorphism with the transfer intrinsic, I ran into a behaviour that I don't understand.

With the following test program, i get the following output :

storage req. size =           16

text = h!O�p!O��

If I replace "class default" with "class is (str)", I get the expected :

storage req. size =           16

text = hello !

Am I doing something wrong ?

Thanks !

Franck

module polymorphic

   character(len=1), private, dimension(:), allocatable :: storage

   type  str
       character(len=16) :: text
   end type str

contains
   subroutine store(arg)
      implicit none

      class(*), intent(in)      :: arg

      integer   :: i_size
      type(str) :: probe

      select type (arg)
!         class is (str)
         class default
            i_size = size(transfer(arg,storage))
            write (*,*) ' storage req. size = ',i_size
            allocate(storage(i_size))
            storage = transfer(arg,storage)

            probe = transfer(storage, probe)
            write (*,*) 'text = ', probe%text
     end select
   end subroutine store

end module polymorphic


program test_polymorphic
  use polymorphic

  type(str) :: input
  input%text = 'hello !'

  call store(input)

end program test_polymorphic

 

updated Xcode and Fortran, now have loader problem

$
0
0

I am trying to compile a code with a makefile that worked fine until today. Today I updated Xcode to v7.3, then installed the latest version of Fortran Composer 2016 ('which ifort' yields /opt/intel//compilers_and_libraries_2016.2.146/mac/bin/intel64/ifort). The code compiles but I get the following loader error:

ld: file not found: @rpath/libimf.dylib for architecture x86_64

This is a new one for me --- what the heck is @rpath? I can't find libimf.dylib (otool says it doesn't exist). Your help is greatly appreciated!

Viewing all 2746 articles
Browse latest View live


Latest Images

<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>