A lot of people are confused on this topic, and a lot has been said in this forum, for which I am grateful. Just when I think I understand it (sufficiently to get by), I run into examples that conflict with what I thought I knew. So I must rehash it again.

If a library project has subroutines SubA.f90, SubB.f90, ... and modules ModA.f90, ModB.f90, ... and these are all compiled into a file MyLib.lib, that file will contain object files SubA.obj, ..., ModA.obj, .... The build procedure will also create compiled module object files ModA.mod, ModB.mod, .... that are not contained in MyLib.lib. For these routines to be used by outsiders, I must distribute MyLib.lib and all of the .mod files, and provide instructions to make .lib accessible to their linker and the .mod accessible to their compiler. There are several ways to do this. It can get unwieldy and confusing. In spades sometimes, e.g. if you need to deal with debug and release combinations.

Now I come upon some discussion, and some direct experience, of cases that defy this understanding. I will try to guess some situations that may behave so.

Q1. Suppose the library contains a subroutine SubX that USEs a module ModX. If a client's outside program has a CALL SubX, is it correct to assume this gives his program access to all of the variables and procedures in ModX? This would seem logical, at least regarding the statements in SubX, because all of the compiler needs have already been performed in the creation of SubX.obj. But how about statements in the remainder of the program? What about procedures other than the one that calls ModX? 

Q2. Now consider a slightly different case: the library has a module ModY that CONTAINS a module procedure SubY. If a client program makes a call to SubY, will that also suffice? (I think not, since the program must first USE the module to gain access to the subroutine.)

Q3. Finally, suppose a library has a module ModZ and a simple subroutine called GetModZ that consists of the single line USE ModZ. Then if a client's program has the line CALL GetModZ () wherever it would normally have USE ModZ, would this provide the module access? Could this be a simpler way than distributing the .mod file to a client and providing a method for his compiler to access it? (I'm not seriously considering this, just trying to understand how things work--and it might be worth tinkering with.) 

Dear all,

I have the C++ dynamic linked library built by VS2012+Intel C++ 14.0, the dynamic linked library is called by Fortran main program.

Currently there are some problems in the C++ code and I need to locate it. However, the bug can't be reproduced in Debug mode but in Release mode, I can't get to know where the crash happened. I have set /Zi option in 'C/C++' and /DEBUG option in 'Linker', but the output message is as follows:

forrtl: severe (157): Program Exception - access violation



Image              PC                Routine            Line        Source

CSGlib.dll         000007FEEF57DF1E  Unknown               Unknown  Unknown



CSGlib.dll         000007FEEF57DB5F  Unknown               Unknown  Unknown



CSGlib.dll         000007FEEF57D78D  Unknown               Unknown  Unknown



fem.exe            000000013FD6F26E  ELEMENT_mp_LOCALM       20494  datatype.f90

fem.exe            000000013FDE82ED  ELEMENT_mp_TESTME       20389  datatype.f90

fem.exe            000000013FF1DFEF  LOGGING3D..0             4600  main.f90



fem.exe            000000013FEFE700  MAIN_PARALLEL             240  main.f90



fem.exe            000000013FE8C02D  MAIN__                     39  main.f90



fem.exe            00000001429799B6  Unknown               Unknown  Unknown



fem.exe            0000000140950D88  Unknown               Unknown  Unknown



kernel32.dll       000000007775652D  Unknown               Unknown  Unknown



ntdll.dll          000000007798C541  Unknown               Unknown  Unknown

where fem.exe is the Fortran main program and CSGlib.dll is the C++ dynamic linked library. I can get to know the crash location of Fortran code but can't get to know the location of C++ code.

What do I miss in project settings?

original post is here:

https://software.intel.com/en-us/forums/topic/517867

Thanks,

Zhanghong Tang

Does the Intel Fortran compiler have Fortran wrappers for getenv and setenv subroutines? If so, which link flag should I use to obtain them?

I'm very frustrated by this error. Not only is it a feature for Fortran 2003 and it is 2014, but it keeps me from being able to file read using namelist for a derived type that contains any allocatable elements or types containing allocatable elements even if I'm not assigning anything to those fields in the namelist read.

Is there a workaround/fix other than creating a second type without the allocatable elements and transferring them post-read?

!==================================================
!
! Compile and run using:
!  ifort optional-bug.f90
!  ./a.out
!==================================================
program option
  implicit none

  real, target  :: at, dt
  real, pointer :: ap, dp

  at = 10; dt = 40

  ap => at
  dp => dt
  dp => null()              ! Uncommenting this line crashes

  print*, 'before ap, dp', ap, dp

  call mysub(ap, dp)

  print*, 'after ap, dp', ap, dp

  contains

    subroutine mysub(aa, dd)

      real :: aa
      real :: dd

      aa = 1000.*aa
      print*, ' Inside mysub aa = ', aa

    end subroutine mysub

end program option

Dear Intel users,

I have a strange behaviour with a PRIVATE variable. I'm using Intel Ifort 14.01

My program has many lines of code, so I report a snippet that summarize the situation. In the main I have an integer  global variable, a parallel region that sets that variabies, and a function ever in parallel region that uses the variable. If I define the variable PRIVATE, the code dies. If Ipass the same variable to a subroutine the code works fine, also if the results are not the same as serial code. This is the snippet that fails:

PROGRAM my_program

integer samplmin_newscal
integer samplmax, sampl0, deltaT
REAL(stnd),        DIMENSION(  :  ), allocatable :: t0

samplmax = some_value
sampl0 = some_value
 deltaT  = some_value

...allocate and set t0

$!OMP PARALLEL DO PRIVATE (i, samplmin_newscal)
DO i

  samplmin_newscal = some_value
  call my_subroutine()

END DO


contains

my_subroutine()

real to_tmp

DO  ij  = samplmax, samplmin_newscal, -1

 t0_tmp = t0(ij + sampl0)+deltaT  ! here the code dies with
                                  ! Subscript #1 of the array T0 has value 0 which
                                  ! is less than the lower bound of 1

END DO

END program my_program

This is the snippet that works well:

integer samplmin_newscal
integer samplmax, sampl0, deltaT
REAL(stnd),        DIMENSION(  :  ), allocatable :: t0

samplmax = some_value
sampl0 = some_value
 deltaT  = some_value

...allocate and set t0

$!OMP PARALLEL DO PRIVATE (i, samplmin_newscal)
DO i

  samplmin_newscal = some_value
  call my_subroutine(samplmin_newscal)

END DO


contains

my_subroutine(samplmin_newscal_local)

integer samplmin_newscal_local
real to_tmp

DO  ij  = samplmax, samplmin_newscal_local, -1

 t0_tmp = t0(ij + sampl0)+deltaT

END DO

END program my_program

No, I know thas if a variable is defined inside a module, must be declared THREADPRIVATE, but this is not the case. Why the private definitions seems to fail? 

Thanks in advance.

The program below gives an internal compiler error for ifort (IFORT) 14.0.3 20140422 under Linux.  It is the character(:) in front of function getS that triggers the error.  Moving character(:) to the pointer statement four lines below makes everything work ok.

MODULE testModule

  TYPE :: FOO

     CHARACTER(LEN=:), ALLOCATABLE :: s 

   CONTAINS

     PROCEDURE, PASS(this) :: getS

     PROCEDURE, PASS(this) :: setS

  END TYPE FOO

CONTAINS

 

  PURE SUBROUTINE setS( this, s )

    !

    CLASS(foo),   INTENT(inout) :: this

    CHARACTER(*), INTENT(in)    :: s

    IF( .NOT. ALLOCATED( this % s ) ) THEN

       ALLOCATE( this % s, SOURCE=s )

    ELSE IF ( LEN(this % s) /= LEN(s) ) THEN

       DEALLOCATE( this % s )

       ALLOCATE( this % s, SOURCE=s )

    ELSE

       this % s = s

    END IF

  END SUBROUTINE setS

  CHARACTER(:) FUNCTION getS( this ) RESULT( p )

    !

    CLASS(foo), INTENT(in), TARGET :: this

    !

    POINTER :: p

    p => this % s

  END FUNCTION getS

END MODULE testModule

PROGRAM testProgram

  USE testModule

  TYPE(foo),    TARGET  :: someFoo

  CHARACTER(:), POINTER :: stringInType

  CALL someFoo%setS( "The quick brown fox jumps over the lazy dog." )

  stringInType => someFoo%getS()

  PRINT '(A)', stringInType

END PROGRAM testProgram

Steve, Colleagues:

I have a large, binary, sequential access data file. Each record corresponds to data for a particular element in a large problem being analyzed. Each record is the same length. Two scenarios:

1. I launch a coarray program and each image opens this (same) file. Different images read through (skip over) the records until the file pointer is at the first element to be processed by that image. Each image then process it's own set of elements, sequentially reading records from the file as necessary. Does the file/MPI system maintain the correct/separate file pointer position(s) for each image?

2. Parallelization is achieved by an OMP 'parallel do' in a single program. Before the parallel do loop is entered, the data file is opened. Each thread is responsible for processing a subset of the elements in the problem. Does the file/OMP system maintain the correct/separate file pointer position(s) for each thread?

Or must I use a binary direct access file and calculated/seek the correct record for each read in each image or thread?

David

I have some code that runs fine and doesn't give any warnings using parallel studio XE2011 (or under that version on windows). But under parallel studio XE2013 update3 it give this warning:

ld: Warning: alignment 16 of symbol `hshdt_' in /home/steve/Documents/SF5.6/lib/proces.a(blkdat.o) is smaller than 32 in /tmp/ifortpmrpmh.o

ld: Warning: alignment 16 of symbol `flonm6_' in /home/steve/Documents/SF5.6/lib/proces.a(blkdat.o) is smaller than 32 in /tmp/ifortpmrpmh.o

I see under windows and using XE2011 it aligns these using 32 bytes.  But the common blocks are only 16 bytes long.  Under 2011 the map gives

                0x0000000000cdd1f0                droot_find0_

                0x0000000000cd6b80                hstdt8_

                0x0000000000cdd2c0                hpxloc_

                0x0000000000cd6b70                hshdt_

                0x0000000000cdd300                svredb2_

(not sure why they are not ordered sequentially ) where you can see hstdt8 is 16 bytes after hshdt.  I'm not sure what problem this might cause, or what exactly would be the best fix for it (if one is needed).

All compiles use REAL_SIZE and INTEGER_SIZE 64.  We don't declare anything that is 128 bits long. 

TIA

Hello,

I try to pass an 1D-array from a C#-DLL to Fortran. For that I am using R. Giesecke DllExport. That makes my managed DLL to a unmanaged DLL with a .lib file. To pass a normal parameter works well. Please see here: https://software.intel.com/en-us/forums/topic/517631

The 1D-Array has always the size of 6! The size of the array will never change only the assigned value.

Here my Code in C#:

using System;
using System.Text;
using RGiesecke.DllExport;
using System.Runtime.InteropServices;

namespace Testme
{
    class Test
    {
        [DllExport("Get1DArray", CallingConvention = CallingConvention.Cdecl)]
        public static int Get1DArray([MarshalAs(UnmanagedType.LPArray, SizeConst = 5)] int [] Stress)

        {

            Stress [0] = 0;
            Stress [1] = 1;
            Stress [2] = 2;
            Stress [3] = 3;
            Stress [4] = 4;
            Stress [5] = 5;

            return Stress[5];
        }

    }
}

Build my C# Dll successfully.

Here my Fortran Code:

MODULE MYEXTERNALS
USE iso_c_binding
INTERFACE
FUNCTION Get1DArray(Stress) RESULT(ret) bind(c, name="Get1DArray")
USE, intrinsic :: iso_c_binding
INTEGER(c_int), intent(in) :: Stress(6)
INTEGER(c_int) :: ret
END FUNCTION
END INTERFACE
END MODULE MYEXTERNALS


PROGRAM CallArray
!DEC$ATTRIBUTE DLLIMPORT :: Get1DArray
USE MYEXTERNALS
IMPLICIT NONE
PRINT*, '1DArray =', Get1DArray(Stress)
PAUSE
END PROGRAM CallArray

I get following error:

error #6404: This name does not have a type, and must have an explicit type.   [STRESS] 

Please help me... Thanks in advance!

- Carsten

Hello,

Could you guys explain me how to update the intel fortran Composer XE and the C++ composer XE (both are part of the Intel Cluster Studio )

The head teacher of my lab bought the Intel cluster studio in 2012 but it has never been updated so i need let it up to date.

I can say for sure that the licence is valid till february 2015 and i've already downloaded the latest version (2013 SP1) of the compilers but i don't know how to proceed (its the first time that i have to deal with this kind of software)

If you guys could help me with a step-by-step procedure of how to do the update i would be really thankful.

I've already tried to look in the user's guide (this page: https://software.intel.com/en-us/intel-software-technical-documentation?...) but not found anything useful

Thanks for your help and support

Hello

we created a large static library using Intel FORTRAN, winch can be included in a FORTRAN project , and we would like to protect and secure this library using USB key. In other words I would like to write a subroutine in that library to check if the USB key exists or not, in case the key is there the library will continue otherwise it will stop and send a license message for the user. Could any one give me directions or provide me some articles about how to do that?

Any help would be very much appreciated.

Many thanks

Ahmed

Consider the following simple example: the compiler (version 14 as well as 2015 BETA) allows a procedure pointer to an elemental procedure and based on what I understand, this is a violation of the standard.  So I request Intel staff to take a look and do the needful; my apologies if this issue has already been identified and a tracking incident is already in effect.

   MODULE m

      !..
      IMPLICIT NONE

      !..
      PRIVATE

      !.. Private fields
      INTEGER :: m_i1 = 1
      PROCEDURE(GetAbstract), POINTER :: Get

      !.. Public methods
      PUBLIC :: Set

      !.. Abstract Interface for a getter method
      ABSTRACT INTERFACE

         PURE ELEMENTAL FUNCTION GetAbstract() RESULT(RetVal)
            !.. Function result
            INTEGER :: RetVal
         END FUNCTION GetAbstract

      END INTERFACE

   CONTAINS

      PURE ELEMENTAL FUNCTION get_i1() RESULT(RetVal)

         !.. Function result
         INTEGER :: RetVal

         !..
         RetVal = m_i1

         !..
         RETURN

      END FUNCTION get_i1

      SUBROUTINE Set(qName)

         !.. Argument list
         CHARACTER(LEN=*), INTENT(IN) :: qName

         !..
         Get => NULL()
         IF (qName == "i1") THEN
            Get => get_i1
         END IF

         !..
         RETURN

      END SUBROUTINE Set

   END MODULE m

Thanks,

Hi,

I need to work with images and I would like to know if there is a way to work with 8-bits unsigned integer in Fortran, with comparisons, additions,... I can't find a way to do that.

Best regards,

François

All,

I have a relatively large legacy codebase (~25 years old) that I am looking to make incremental build improvements on. The inter-project dependencies are very high, and we are going to work on that in the future, but I want to improve our build process on what we have. We currently use a build script to build all the projects sequentially, ensuring that all of the dependencies happen in the correct order. Unfortunately, this means our build is very serial, with approximately 45 minutes of build time each for release and debug. 

We are using Visual Studio 2013 (a mix of Professional /Premium/Ultimate) with Intel Visual Fortran Composer 2013 SP1. We have ~180 C++ projects and ~25 Fortran projects. The codebase as a whole is ~280 projects with varying degrees of sharing over ~20 solutions. 

My current attempt at improving the build is to set up the project references so that each project is aware of what it needs to build. Nearly every C++ project depends on another C++ project, and a good portion of the high-level C++ projects link to the Fortran .libs. Currently we have all the .lib linking set up correctly - I do not need any assistance with this part of it). 

The first option I investigated was looking at the Project Dependencies (Project -> Project Dependencies) where one can go through and select a project and then identify its dependencies. This is probably the most straightforward solution, but it unfortunately is not portable outside of its solution. For example, in Solution SLN_A, I have four projects, A, B, C, and D (Fortran). A depends on B and C, and C depends on D. I can set all these up in the Project Dependencies window, and Visual Studio will build B and D first, then C, then A. If I then add A, B, C, and D to another solution , I have to SLN_B, I have to manually configure these project dependencies again. I'm lazy and really didn't want to go do this for every solution, so I looked for something else.

I have found that native Visual C++ projects have the ability to add "Project References" to other projects in that solution (Project -> Properties -> Common Properties -> References).  This gets stored on each Project independently. In the previous example, I would tell A that it depends on B and C by stating that A has a reference to B and C. Similarly for C, I would say that it references D. When I add A, B, C, and D, to either SLN_A or SLN_B, the build order dependency is automatically discovered. If I forget to include C into a project, when it attempts to build from scratch, it will fail because I don't have that project in the solution. It kind of enforces the "Include What You Use" idea in C++. 

I really like the second option, but here's the problem with it: Visual Fortran Projects can not be selected as references. Thus, I am stuck having all of my C++ references defined to the other C++ projects, but they have no idea/knowledge of the fact they might reference a Fortran project. My build order is now about 90% correct, but the fortran projects are just scattered in there randomly as Visual Studio sees fit. I have already gone through the work of setting up all the C++-project dependencies to the other C++ projects, and am now looking to finish the Fortran-side of things.

Here are my questions:

1. Is there any way to have project references for Visual Fortran projects? vfproj->vcxproj or vcxproj->vfproj?
2. If this is not possible, do we know why?
3. Is there a feature request site for Intel Visual Fortran that I could submit this to, or is this a Visual-Studio thing?
4. Do you have any suggestions on how I can deal with this issue in its current state?

Current workaround is to enforce as many project dependencies as possible, and then return to the solution-level dependencies and individually add the Visual Fortran dependencies there. Again, not portable, but it does cut down the scope of work largely. 

Thank you in advance for your help and advice! 

Dear all:

Recently, i try to use openmp language through the Intel Visual Fortran.

Because i am a beginner of the parallel computing, i decided to make the do-loops faster by using multiprocessor.

I read a lot of information about the openmp, but had this warning when compiling.

warning #10247: explicit static allocation of locals specified, overriding OpenMP*'s implicit auto allocation

I really don't know where the problem is. 

If there are any suggestion, please help me.

Thank you very much

--------------------------------part of my program------------------------------------------------

!$omp parallel do default(shared) private(k,d_epsc,cgmci,Eta1)

       do k = 1,nsteel(i)       !the half of the section

            d_epsc=dd_defN(m)-zz_steel(k,i)*dd_defMy(m)+

     +      yy_steel(k,i)*dd_defMz(m)

            

          call FrontSteel(i,Fiber,Fbmat,d_epsc,cgmci,k,m,nsm,

     +           Eta1,time,repet,kfc,istep,nskip,secfail,ff_change)

!        computing axial force and bending moment of each fiber of the section 

        f11(k) = cgmci*aa_steel(k,i)

        fmy(k) = -cgmci*zz_steel(k,i)*aa_steel(k,i)

          fmz(k) = cgmci*yy_steel(k,i)*aa_steel(k,i)

 !        summation of axial force and bending moment of all fibers of the section 

        ss_sum11 = ss_sum11 + f11(k)

        ss_sum21 = ss_sum21 + fmy(k)

        ss_sum31 = ss_sum31 + fmz(k)

          f11(k)=0.

          fmy(k)=0.

        fmz(k)=0.

          d_epsc=0.

          end do      

      !$omp end parallel do

-----------------------------------------------------------------------------------------------------------------------

Won't it be a great benefit to all users if the tracking incident database for Intel compiler incidents (bugs/features, etc.) can be made "viewable" for everyone?  I think it could be a "marketing coup" and generate a lot of positive feedback for Intel software products if Intel were to make this happen.

I know Premier Support offers some tracking capability, but my subscription status doesn't include that support and so I don't know the exact details.  My interest is in some tracking capability that will be open to everyone and which will give the users to simply view and keep up with the progress on all existing incidents,  

Note it is NOT necessary for the actual incident database to be accessible for all users - it could even be that a report is generated using some automated script at some frequency, perhaps weekly, from the database and a summary of all open incidents and their status along with incidents that have been closed over some time period, say past year, is presented at some link at software.intel.com.  The summary simply has to include the subject and some description of the incident, its status, the reference to a forum topic if applicable, if fixed then the details of the compiler version that includes the fix.  This itself will be of great help and it will more than suffice for what I'm looking for.  Of course, Intel is free to include any additional details, if they wish to, such as file attachments, sample code, developer comments, etc.

It will be much better than the current situation where someone who doesn't have Premier Support opens a topic on the forum, someone at Intel reviews and submits an incident with the Development team, and has to post back manually on the forum to update the readers (and the OP) on the status.  And it is easy to lose track in such an environment, so the OP often has to post a reminder comment to know the status.

What does everyone think?  Feedback/comments welcome.

I am getting a "fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt"

Can you suggest how I can proceed.

Thanks 

I wrote a bash scrip that download files from internet and then run a software called Wavewatch (which is compiled with Intel Fortran Compiler) to do some process using downloaded files. The problem is that when I run the script using crontab (which runs in background without any open terminal window), everything goes well, but when I run the command manually in a Terminal window, a software module (called ww3_outp) returns an error complaining about writing problem of /dev/pts/0 looks like this:

forrtl: severe (38): error during write, unit 6, file /dev/pts/0
Image              PC                Routine            Line        Source
ww3_outp           00000000004AFEDB  Unknown               Unknown  Unknown
ww3_outp           0000000000408A6A  Unknown               Unknown  Unknown
ww3_outp           0000000000408236  Unknown               Unknown  Unknown
libc.so.6          000000347D81ED1D  Unknown               Unknown  Unknown
ww3_outp           0000000000408129  Unknown               Unknown  Unknown

I looked to /dev/pts/ and found that with each instance of Terminal window a file named by a number (0,1,2,...) is produced which can't be edited or deleted even with root permission. It seems so weird, any idea?

I seem to remember that arguments in a call from vb6 must be by value. And I see in the Fortran manual that optional arguments must be by Ref. Does this mean that I can not have an optional argument in a call from vb6? Or if I can, how do I do it?