Quantcast
Channel: Intel® Fortran Compiler
Viewing all 3270 articles
Browse latest View live

Defined assignment and allocatable components

$
0
0

My reading of both Fortran 2003 and Fortran 2008 (7.4.1.3, page 141) is that it should call my defined assignment for the explicit one between checkpoints Bravo and Charlie as well as for the one before Alpha.

MODULE Assign

    IMPLICIT NONE

    TYPE, PUBLIC :: Mytype

        INTEGER :: comp = 123

    CONTAINS

        PROCEDURE, PRIVATE :: Copy

        GENERIC :: ASSIGNMENT (=) => Copy

    END TYPE Mytype

CONTAINS

    SUBROUTINE Copy (a, b)

        CLASS(Mytype), INTENT(OUT) :: a

        CLASS(Mytype), INTENT(IN) :: b

        PRINT *, 'Copying', b%comp

        a%comp = b%comp

    END SUBROUTINE Copy

END MODULE Assign

PROGRAM Main

    USE Assign

    IMPLICIT NONE

    TYPE :: Weeble

        TYPE(Mytype), ALLOCATABLE :: arr

    END TYPE Weeble

    TYPE(Mytype) :: this, that

    TYPE(Weeble) :: object, temp

    that%comp = 456

    this = that

    PRINT *, 'Checkpoint Alpha'

    call Cheque(this)

    PRINT *, 'Checkpoint Bravo'

    ALLOCATE(object%arr)

    object%arr%comp = 123

    temp = object

    PRINT *, 'Checking', object%arr%comp

    PRINT *, 'Checkpoint Charlie'

    CALL Check(temp)

CONTAINS

    SUBROUTINE Cheque (arg)

        TYPE(Mytype), VALUE :: arg

        PRINT *, 'Checking', arg%comp

    END SUBROUTINE Cheque

    SUBROUTINE Check (arg)

        TYPE(Weeble), VALUE :: arg

        PRINT *, 'Checking', arg%arr%comp

    END SUBROUTINE Check

END PROGRAM Main

 


How to read multiple data without changing line?

$
0
0

Dear all,

I have a file without fixed number of data in every line. The example data are as follows:

0 0 0 30 45 0.2 0.001 5 0.005 0 0 1

0 0 1 0 0 0.2 0.001 1

For every line, if the eighth number is greater than 1, there are 4 data to be read, else if eighth number is equal to 1, there is no any data after that number.

How to design read format to read this kind of data?

Thanks,

Zhanghong Tang

 

Calling a File (a matrix with unknown size) inside of the UEL and COMMON variables

$
0
0

Hi everybody,

I'm almost new in FORTRAN and UEL. I have two questions:

1- Inside of the UEL I have to open and read a file which contain a matrix with unknown size. Without defining the size I can't open and read the file. What should I do to over come this?

2- I'm trying to define some of the variables as COMMON variables (for some reasons I can't use module). I have a variable (let's say 'A') which has been defined as allocatable variable. Some how I couldn't define it as COMMON variable. What should I do?

Thanks in advance,

Best Regards,

VALUE attribute has no value?

$
0
0
PROGRAM DubiousValues
  IMPLICIT NONE
  LOGICAL :: array(3)
  !****
  array = .TRUE.
  PRINT "('Before:',*(L1,:,1X))", array
  CALL proc(array)
  PRINT "('After :',*(L1,:,1X))", array
CONTAINS
  SUBROUTINE proc(arg)
    LOGICAL, VALUE :: arg(:)
    !****
    arg = .FALSE.
  END SUBROUTINE proc
END PROGRAM DubiousValues

arg should be associated with an anonymous data object that has the value of array (but not actually associated with array), etc.  But...

>ifort /check:all /warn:all /standard-semantics "2014-07-22 DubiousValues.f90"&& "2014-07-22 DubiousValues.exe"
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.070 Beta Build 20140530
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2014-07-22 DubiousValues.exe"
-subsystem:console"2014-07-22 DubiousValues.obj"
Before:T T T
After :F F F



 

WRITE Statement

$
0
0

Hi all,

The output of my program is a text file. The write statement is as follow:

open(unit=3 , file='GI.txt')
do i=1,n
write(3,*) GI(i,20),GI(i,21),GI(i,22),GI(i,23),GI(i,24),GI(i,25),GI(i,3)
end do
close(unit=3)

The output text file is:

  8.3631918E-02  3.8731284E-03  0.9124947      1.6570982E-02  1.2863785E-03
  0.9817734       5.000000
  8.3645843E-02  3.6123185E-03  0.9127416      1.6570950E-02  1.1989133E-03
  0.9818419       5.000000
  8.3371475E-02  3.6123185E-03  0.9130162      1.6491989E-02  1.1989133E-03
  0.9819432       5.000000
  8.3385289E-02  3.3518937E-03  0.9132624      1.6491955E-02  1.1117029E-03
  0.9820116       5.000000
  8.3376385E-02  3.0915497E-03  0.9135318      1.6491907E-02  1.0245456E-03
  0.9821022       5.000000
  8.3367527E-02  2.8312337E-03  0.9138010      1.6491858E-02  9.3740685E-04
  0.9821926       5.000000
  8.3357789E-02  2.5716582E-03  0.9140702      1.6491810E-02  8.5075555E-04
  0.9822835       5.000000
  8.3347775E-02  2.3130313E-03  0.9143388      1.6491760E-02  7.6472707E-04
  0.9823740       5.000000
  8.3338819E-02  2.0545253E-03  0.9146064      1.6491711E-02  6.7877769E-04
  0.9824634       5.000000
  8.3329812E-02  1.7961761E-03  0.9148740      1.6491663E-02  5.9293135E-04
  0.9825526       5.000000
  8.3320513E-02  1.5382101E-03  0.9151412      1.6491614E-02  5.0733547E-04
  0.9826420       5.000000    

and what happens is that, for example, [GI(1,20),GI(1,21),GI(1,22),GI(1,23),GI(1,24)] are in one line and [GI(1,25),GI(1,3)] are in the next line. I want to make all the seven values in a single row.

Also is there any way to make the format looks like that:

Sw   Krw  Kro
-----------------------
1.0  1.0  0.0
0.9  0.9  0.1
0.8  0.8  0.2

?

Thanks in advance

Andrew.

Internal compiler error (C0000005) with Floating-Point Exception Handling

$
0
0

Hello, I've been reading about this error in the forums and it appears to be a bug.

I am certain that it is not the code because it had been compiling just fine and I never change it. I don't even recall changing any of the floating point configuration settings either but I've been able to isolate the error to the flag for "Underflow gives 0.0; Abort on other IEEE exceptions (/fpe:0)." Everything compiles fine with the the default project setting of "Produce NaN, signed infinities, and denormal results"

I'm using Visual Studio 2010 version 10.0.40219 with Visual Fortran version 2013.1.119

I'm trying to compile a USGS groundwater model that is available here: http://water.usgs.gov/ogw/seawat/

 

Module Variable Scope

$
0
0

If I have a DLL with module variables, is it safe to call functions that use those variables in a parallel process? I want to avoid passing the debug level and output file to all of my functions in a DLL. So instead, my first function call into the DLL initializes 2 private module variables in the module logging: output_file and debug_level. Then I define a subroutine write_to_log( message ). In a non-parallel application, from anywhere in the dll I can say "use logging" and simply write "call write_to_log( some_message )." If I have multiple threads using this library, will all my logging messages go to the output file initialized by the last logging initialization call? My understanding is that they will not, but they would if I declared the variables in a common block. Is this correct?

If this question has been asked before and I missed it, or if there are any references out there please point me in that direction. Thanks for your time!

Extremely simple offload example: "Unexpected number of variable descriptors"

$
0
0

Hi 

In the extremely simple example below I never enter the offload region, but receive the runtime error message:  "Unexpected number of variable descriptors"

What could possibly be the problem here? I run the latest version of parallel studio XE on windows server 2008 R2.

Best regards,

C

 

    program Console2

    implicit none

    print *,'Starting on host ...'

!DIR$ OFFLOAD BEGIN TARGET(mic:0)

    print *,'On phi ...'

!DIR$ END OFFLOAD   

    print *,'Back on host ...'

    end program Console2

Compiler arguments:

/nologo /debug:full /Od /warn:interfaces /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc110.pdb" /traceback /check:all /libs:static /threads /dbglibs /c

Linker arguments:

/OUT:"x64\Debug\Console2.exe" /INCREMENTAL:NO /NOLOGO /qoffload-ldopts="-lifcoremt" /MANIFEST /MANIFESTFILE:"C:\Users\casper.kirkegaard\Documents\Visual Studio 2012\Projects\Console2\Console2\x64\Debug\Console2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\casper.kirkegaard\Documents\Visual Studio 2012\Projects\Console2\Console2\x64\Debug\Console2.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Users\casper.kirkegaard\Documents\Visual Studio 2012\Projects\Console2\Console2\x64\Debug\Console2.lib"


FINAL binding to an ELEMENTAL procedure does not work: causes "Program Exception - Access Violation"

$
0
0

Consider the simple program shown below:

MODULE m

   !..
   IMPLICIT NONE

   !.. Private by default
   PRIVATE

   TYPE, PUBLIC :: t

      !.. private by default
      PRIVATE

      !.. Private fields
      CHARACTER(LEN=:), ALLOCATABLE :: m_string

   CONTAINS

      !.. Private by default
      PRIVATE
      FINAL :: Clean

      !..
      PROCEDURE, PASS(This), PUBLIC :: Set => Set_String
      PROCEDURE, PASS(This), PUBLIC :: Get => Get_String

   END TYPE t

CONTAINS

   PURE ELEMENTAL SUBROUTINE Set_String(This, NewString)

      !.. Argument list
      CLASS(t), INTENT(INOUT)      :: This
      CHARACTER(LEN=*), INTENT(IN) :: NewString

      !..
      This%m_string = NewString

      RETURN

   END SUBROUTINE Set_String

   PURE ELEMENTAL FUNCTION Get_String(This) RESULT(RetVal)

      !.. Argument list
      CLASS(t), INTENT(IN) :: This
      !.. Function result
      CHARACTER(LEN=:), ALLOCATABLE :: RetVal

      !..
      RetVal = This%m_string

      RETURN

   END FUNCTION Get_String

   PURE ELEMENTAL SUBROUTINE Clean(This)

      !.. Argument list
      TYPE(t), INTENT(INOUT)      :: This

      !.. Local variables
      INTEGER :: Istat

      IF (ALLOCATED(This%m_string)) THEN
         DEALLOCATE(This%m_string, STAT=Istat)
      END IF

      RETURN

   END SUBROUTINE Clean

END MODULE m

PROGRAM p

   USE m, ONLY : t

   IMPLICIT NONE

   !.. Local variables
   TYPE(t), ALLOCATABLE :: foo(:)
   INTEGER :: Istat
   INTEGER, PARAMETER :: MaxElem = 5
   INTEGER :: I
   CHARACTER(LEN=2048) :: ErrDealloc

   !..
   PRINT *, " Test Elemental finalizer "

   ALLOCATE(foo(MaxElem), STAT=Istat)
   IF (Istat /= 0) THEN
      PRINT *, " Error allocating foo."
      STOP
   END IF

   DO I = 1, MaxElem
      CALL foo(I)%Set(" string " // ACHAR(34+I))
      PRINT *, " foo element ",I, " is ",foo(I)%Get()
   END DO

   DEALLOCATE(foo, STAT=Istat, ERRMSG=ErrDealloc)
   IF (Istat /= 0) THEN
      PRINT *, " Error deallocating foo: STAT = ",Istat,", ERRMSG = ", ErrDealloc(1:LEN_TRIM(ErrDealloc))
      STOP
   END IF

   PRINT *, " End Program "

   STOP

END PROGRAM p

 

Upon compilation and execution with Intel Fortran, either compiler version 14 or 2015 Beta, the program fails as follows:

  Test Elemental finalizer
  foo element  1  is  string #
  foo element  2  is  string $
  foo element  3  is  string %
  foo element  4  is  string &
  foo element  5  is  string '
forrtl: severe (157): Program Exception - access violation
Image              PC        Routine            Line        Source
TestFor32.exe      00DA1494  _M_mp_CLEAN@4              66  TestMod.f90
TestFor32.exe      00DB13DA  Unknown               Unknown  Unknown
TestFor32.exe      00DA2467  _MAIN__                    28  TestFor.f90
TestFor32.exe      00E148A2  Unknown               Unknown  Unknown
TestFor32.exe      00E157BA  Unknown               Unknown  Unknown
TestFor32.exe      00E1590D  Unknown               Unknown  Unknown
kernel32.dll       7576338A  Unknown               Unknown  Unknown
ntdll.dll          76F5BF32  Unknown               Unknown  Unknown
ntdll.dll          76F5BF05  Unknown               Unknown  Unknown

 

My understanding is the above is consistent with current Fortran standard and the access violation is due to some bug in the compiler.  Can someone from Intel please investigate and provide feedback?

Thanks,

What is up with "Debug Error!" from Microsoft Visual C++ Runtime Library?

$
0
0

Does anyone know the root causes of "Debug Error!" from Microsoft Visual C++ Runtime Library that is often accompanied by a message that says "Damage before 0x0... which was allocated by aligned routine"?

I'm getting this error in one of my codes when I run the executable build with Debug configuration for Intel 64 (64-bit) with the /dbglibs setting for Fortran Run-time libraries.  But the executable built with Release configuration runs with no such error.  So I rebuilt the Debug configuration executable with non-debug libraries (i.e., /dbglibs setting removed) and this error disappeared.

However I was not getting such an error in my code earlier, so some of my recent changes must have caused this to happen.  But I can't figure out what.  Note I've unit-tested thoroughly and separately each and every change.  The code is quite proprietary, so I can't post it here.

Hence I would appreciate if anyone has any pointers on what all I can check in my code.

Thanks,

 

 

Catastrophic error when compiling

$
0
0

When compiling a program using the 2013 version of Intel Fortran on RedHat 5.9 I received the following error message

/tmp/ifort31HZxZ.i90: 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.

Is there any work around for this problem?

!DIR$ OFFLOAD TARGET: Disable implicit copying of variables?

$
0
0

Hi 

I have a code that uses derived types that includes allocatables inside a region that I want to offload. In order to get the derives type onto the device I try to manually transfer the content of the allocatables and then re-assemble the derived type on the phi. However, I have run into the problem that some kind of implicit copying must be going on ...

The issue is illustrated in the small example below. In the offload region transfer of MyType is not allowed, so I state that only TransferInt,TransferFloats should be copied to the device. However, when you get to the very last line of the program it appears that MyType has been included implicitly as in INOUT variable. An access violation is now produced runtime, since MyType could not be properly copied back from the device.

Is there any way I can turn of implicit copying in order to get around this problem?

I use the latest version of parallel studio XE.

    module mTestType

      type TTestType

        integer :: Int

        real*8,allocatable :: Floats(:)

      end type TTestType

      !dir$ attributes offload : mic :: TTestType

      type(TTestType) :: MyType

      !dir$ attributes offload : mic :: MyType

    end module mTestType

 

    

    program Console1

    use mTestType

    implicit none

    integer            :: TransferInt

    real*8,allocatable :: TransferFloats(:)

    !dir$ attributes offload : mic :: TransferInt

    MyType%Int=1d0

    allocate(MyType%Floats(4))

    MyType%Floats(:)=2d0

    allocate(TransferFloats(4))

    TransferFloats(:)=MyType%Floats(:)

    TransferInt=MyType%Int

    !DIR$ OFFLOAD BEGIN TARGET(mic:0) IN(TransferInt,TransferFloats)

    allocate(MyType%Floats(4))

      MyType%Floats(:)=TransferFloats(:)

      MyType%Int=TransferInt

      print *,'On phi ...'

      print *,MyType%Int

      print *,MyType%Floats(:)

    !DIR$ END OFFLOAD  

    print *,'On host ...'

    print *,MyType%Int

    print *,MyType%Floats(:)

    end program Console1

Access a C library interface from F90 using iso_c_binding

$
0
0

So, I am trying to access a C function from F90, with the following code:

SUBROUTINE sub1()

    USE,INTRINSIC :: iso_c_binding

    ! interface to c library
    INTERFACE
        ! library function prototype
        ! DBfile *DBCreate (char *pathname, int mode, int target, char *fileinfo, int filetype)
        TYPE(C_PTR) FUNCTION DBCreate_f(pathname,mode,fileformat,fileinfo,filetype) BIND(C,NAME="DBCreate")
            IMPORT :: C_PTR,C_CHAR,C_INT
            IMPLICIT NONE
            CHARACTER(KIND=C_CHAR) :: pathname(*)
            INTEGER(KIND=C_INT),VALUE :: mode
            INTEGER(KIND=C_INT),VALUE :: fileformat
            CHARACTER(KIND=C_CHAR) :: fileinfo(*)
            INTEGER(KIND=C_INT),VALUE :: filetype
        END FUNCTION DBCreate_f

        ! library function prototype
        ! int DBClose (DBfile *dbfile)
        INTEGER(KIND=C_INT) FUNCTION DBClose_f(dbfile) BIND(C,NAME="DBClose")
            IMPORT :: C_INT,C_PTR
            IMPLICIT NONE
            TYPE(C_PTR) :: dbfile
        END FUNCTION DBClose_f
    END INTERFACE


    CHARACTER(LEN=...) :: string11
    CHARACTER(LEN=...,KIND=C_CHAR) :: string1
    INTEGER(C_INT) :: val1,val2,val3
    CHARACTER(LEN=...) :: string21
    CHARACTER(LEN=...,KIND=C_CHAR) :: string2

    TYPE(C_PTR) :: retval1_ptr
    INTEGER(C_INT) :: retval2


    retval1_ptr=C_NULL_PTR


    !======================================================================
    ! call to first interface function
    !======================================================================
    WRITE(string11,FMT='(a)') "blahblahblah"
    WRITE(UNIT=string1,FMT='(a,a)') TRIM(string11),C_NULL_CHAR
    val1=1
    val2=2
    WRITE(string21,FMT='(a)') "BLAHBLAHBLAH"
    WRITE(UNIT=string2,FMT='(a,a)') TRIM(string21),C_NULL_CHAR
    val3=3
    retval1_ptr=DBCreate_f(string1,val1,val2,string2,val3)      ! this is line 372 in the original file
    ! DBCreate returns a DBfile pointer on success and NULL on failure.
    IF (.NOT.C_ASSOCIATED(retval1_ptr)) CALL terminate(...)

    !======================================================================
    ! call to second interface function
    !======================================================================
    retval2=DBClose_f(retval1_ptr)
    ! DBClose returns zero on success and -1 on failure.
    IF (retval2==-1) CALL terminate(...)


END SUBROUTINE sub1

 

However, in the link stage, I get the error:

module1.o: In function `sub1':

module1.f90:372: undefined reference to `DBCreate'

Several notes:

  • It is my understanding that C_PTR can be used to return scalar pointers of _any_ type, and since I don't need to access any of the data pointed at by this pointer directly, I thought the above would be ok.
  • There are two calls to the library, and only one of them is having a problem.  However, running nm on the .a file verified that the function DBCreate is actually in the file.
  • I tried this with various versions of ifort, from early 12.xxx to 14.xxx, and they all exhibit the same problem.

     

Any thoughts?  Thanks.

 

error #6897

$
0
0

Just upgraded to Composer XE 2011 and code that compiled in IVF 9 through 11 but not fails with the error message:

error #6897: An interface-block in a subprogram must not contain an interface-body for a procedure defined by that subprogram.

I cannot find any help on this error. The source file only contains a single interface block with several interface definitions and the compiler error is thrown for only some of the routine definitions.

Trougle manipulating the Quickwin menu bar

$
0
0

Quickwin programs open with a default project frame having a status bar and a set of default menus. My Quickwin program opens with a splash screen, composed of a minimalist project frame in which I have deleted the task bar (using CLICKMENUQQ) and the menu bar (using DELETEMENUQQ). This frame is then filled with a solitary child window. This works fine. Then when the program takes over, I wish to resize and reposition the frame, which also works fine. Finally, I wish to add a single menu to the frame, which does not work fine.

I try this using either APPENDMENUQQ or INSERTMENUQQ. Either one adds the menu OK, but it also creates an unintended child window for no apparent reason, having the generic title "Graphic1" and an unknown unit number. It interferes with the program display, and I cannot get rid of it.

Surely the menuqq operations are not supposed to work this way? It doesn't seem possible to create a menu after having deleted all of the default menus. 


C++/Fortran: Cannot open 'ifconsol.lib' VS2013/XE 2013sp1

$
0
0

I recently upgraded to a new HD and re-installed all my development tools. In the past, I followed many topics answered by Steve Lionel to resolve fortran/c++ issues. I'm not sure what's wrong, but I can't seem to get things to work this time. 

My VS solution contains a C++ empty project and a static fortran library. I added lib/ias32 to VC++ directories for debug/release in win32 (everything is win32 atm) and set the C++ project to depend on the fortran project. The problem is that (.lib) files aren't being seen unless I add them to the C++ source folder directly (drag and drop into VS). If I edit the C++ proj's properties->linker->additional library dependencies and add the path to the ias32 libraries, I get LNK1104. What am I missing?

Thanks!

Unexpected access violation

$
0
0

I am using the latest: Fortran Compiler XE 14.0.3.202

The program I am working on has started unexpectedly crashing when compiled in optimized release mode.  However, when compiled in debug mode, there are no errors or warnings.  I have spent a day debugging, and I was able to isolate the portion of the code where the problem occurs.  This code is very unstable, and doing a trivial change can make the problem go away.

Attached is the source code, project, and output BuildLog files.  When compiled in release mode, the program crashes with:

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



Roman

 

AttachmentSize
Downloadfortran_problem.zip6.35 KB

Intel Fortran fails to recognize the PRIVATE attribute of a type-bound procedure in a base type when it is extended.

$
0
0

Consider the following simple example:

MODULE b

   IMPLICIT NONE

   !.. Private by default
   PRIVATE

   TYPE, ABSTRACT, PUBLIC :: A_t

      !..
      PRIVATE

      !.. Private fields
      INTEGER :: m_A

   CONTAINS

      !.. Private by default
      PRIVATE

      !.. Private methods
      PROCEDURE(IFoo), PASS(This), DEFERRED :: Foo

   END TYPE A_t

   TYPE, EXTENDS(A_t), PUBLIC :: B_t

      !..
      PRIVATE

   CONTAINS

      !.. Private by default
      PRIVATE

      !.. Private methods
      PROCEDURE :: Foo => BFoo

   END TYPE B_t

   !.. Abstract Interface for class methods
   ABSTRACT INTERFACE

      !.. Initialize EosClass
      PURE ELEMENTAL SUBROUTINE IFoo(This)

         IMPORT :: A_t

         !.. Argument list
         CLASS(A_t), INTENT(INOUT) :: This

      END SUBROUTINE IFoo

   END INTERFACE

CONTAINS

   PURE ELEMENTAL SUBROUTINE BFoo(This)

      !.. Argument list
      CLASS(B_t), INTENT(INOUT) :: This

      !..
      This%m_A = 0

      !..
      RETURN

      END SUBROUTINE BFoo

END MODULE b

MODULE c

   USE b, ONLY : B_t

   !..
   IMPLICIT NONE

   !.. Private by default
   PRIVATE

   TYPE, EXTENDS(B_t), PUBLIC :: C_t

      !..
      PRIVATE

      INTEGER :: m_C

   CONTAINS

      !.. Private by default
      PRIVATE

      !.. Private methods
      PROCEDURE, PASS(This), PUBLIC :: Bar

   END TYPE C_t

CONTAINS

   PURE ELEMENTAL SUBROUTINE Bar(This)

      !.. Argument list
      CLASS(C_t), INTENT(INOUT) :: This

      !..
      This%m_C = 0
      CALL This%Foo() ! <-- Foo is PRIVATE to module b; compiler should flag
                      !     an error

      !..
      RETURN

   END SUBROUTINE Bar

END MODULE c

 

Intel Fortran compiler  - version 13 (XE 13.1.1.171) and 2015 Beta - fails to flag an error at line 109 that the invoked method Foo is PRIVATE to MODULE b.  It compiles the code with no errors.

I think this is a compiler bug.  Can someone from Intel please check and do the needful?

Thanks,

 

Deallocated pointers still have old shape specifications

$
0
0

I found it odd that deallocated pointers still have their shape information, even though "associated" returns .false. I suppose I expected to get an error, or at least zeroes. Is there a good reason for this behavior? Perhaps it makes sense but I can't see how.

program test_alloc
implicit none
integer, pointer :: perms(:,:)=>null()

print*,"associated",associated(perms)
print*,"shape",shape(perms)
allocate(perms(3,5))
print*,"associated",associated(perms)
print*,"shape",shape(perms)
deallocate(perms)
print*,"associated",associated(perms)
print*,"shape",shape(perms)
perms=>null()
print*,"associated",associated(perms)
print*,"shape",shape(perms)

end program test_alloc

 

 associated F
 shape           0           0
 associated T
 shape           3           5
 associated F
 shape           3           5
 associated F
 shape           3           5

 

error #6633: The type of the actual argument differs from the type of the dummy argument.

$
0
0

I am new to programming with Intel Fortran so I think there is something missing or wrongly organized that I am not aware of in this case. I would be grateful if someone can help me in this regard.

The problem is that I see the following errors when compiling my code, while I believe that I have declared the derived type variables cr and me correctly.

error #6633: The type of the actual argument differs from the type of the dummy argument.   [CR]

error #6633: The type of the actual argument differs from the type of the dummy argument.   [ME]

My code contains a Module named InputData which contains the definition of the derived type gridand declaration of the derived type variables cr and me of type grid. I make use of these definitions in the main program using a USE statement. The error refers to a line in the main program which CALLs an internal subroutine that uses cr and “me” as input argument (INTENT(IN)). Surprisingly, I use exactly the same way for declaring the derived type variable ls of type Levelsetdefined in Module OutputData using a USE statement in the Main program and get no error on that variable in the same subroutine. Adding a USE InputData statement to the subroutine ComputeLSalso did not address the issue.

I tried to remove all modules and include all type definitions and variable declarations in the Main program instead of in separate modules. But unfortunately the errors still exist.

@SteveLionel

 

 

AttachmentSize
DownloadPrepro_test.zip80.78 KB
Viewing all 3270 articles
Browse latest View live