Quantcast
Channel: Intel® Software - Intel® Visual Fortran Compiler for Windows*
Viewing all 5691 articles
Browse latest View live

Access violation error when subroutine is called

$
0
0

Stripped-down code shown below is generating "access violation" run-time error when ReadAttribute subroutine is called. The error occurs when the program is compiled with IVF 17.0 but not with IVF 16.0. Maybe a bug in the compiler?

Thanks!

 

MODULE HDF5_CLASS
    IMPLICIT NONE

  TYPE :: HDF5FileType
  CONTAINS
      PROCEDURE,PASS :: New             => New_HDF5File
      PROCEDURE,PASS :: ReadAttribute
      GENERIC        :: ReadData        => ReadAttribute
  END TYPE HDF5FileType

CONTAINS

  SUBROUTINE New_HDF5File(ThisFile,FileName,lInputFile,AccessType,Status)
    CLASS(HDF5FileType)                  :: ThisFile
    CHARACTER(LEN=*),INTENT(IN)          :: FileName
    LOGICAL,INTENT(IN)                   :: lInputFile
    CHARACTER(LEN=*),OPTIONAL,INTENT(IN) :: AccessType
    INTEGER,OPTIONAL,INTENT(OUT)         :: Status

    CHARACTER(LEN=11) :: cAttributesDir
    LOGICAL           :: TrackTime

    cAttributesDir = '/Attributes'
    CALL ThisFile%ReadAttribute(cAttributesDir,'TimeStep%TrackTime',ScalarAttrData=TrackTime)

  END SUBROUTINE New_HDF5File


  SUBROUTINE ReadAttribute(ThisFile,cGrpOrDset,cAttrName,ScalarAttrData,ArrayAttrData)
    CLASS(HDF5FileType),INTENT(IN) :: ThisFile
    CHARACTER(LEN=*),INTENT(IN)    :: cGrpOrDset,cAttrName
    CLASS(*),OPTIONAL,INTENT(OUT)  :: ScalarAttrData,ArrayAttrData(:)
  END SUBROUTINE ReadAttribute

END MODULE HDF5_CLASS


PROGRAM Test
    USE HDF5_CLASS
    IMPLICIT NONE

    TYPE(HDF5FileType) :: ThisFile

    CALL ThisFile%New('SomeFileName',.TRUE.)

END

 

Thread Topic: 

Bug Report

Why does VS 2013 keep hanging up ?

$
0
0

When I first go into VS 2013 it compiles and does a build with a second or two.

The problem occurs when it hits a breakpoint, and I want to quit and restart.

I say "stop debugging," and I get the blue circle for about 15 seconds, and then an error message,

to the effect that the DEBUGGER MAY UNSTABLE then I cant reference the EXE or do any more builds,

or restart it.

 

To proceed , I have to quit VS 2013 entirely, and start over.

 

I dont see this hangup when the program exits normally, like with a STOP command.

 

So there is some process going on that interferes with any further work, until I quit the VS2013.

 

Incidentally, sometimes I get "CANNOT WRITE THE MANIFEST, about 25 percent of the time, but then I can still do the rebuild by trying again.

 

I can attach the two source files, but I dont see the relevance. It is not in my source code, its in VS 2013.

 

Dont we have something to say about the quality of stuff we get from Microsoft ?

IFORT_COMPILER16 not created

$
0
0

I am using Visual Studio Professional 2015 Version 14.0.25431.01 Update 3 with Intel Parallel Studio XE 2016 Composer Edition for C++ WIndows and Intel Parallel Studio XE Update 1 Composer Edition for Fortran Windows.  Compiling pure C++ project works fine or FORTRAN projects that call C++ is fine but C++ calling FORTRAN fails to find ifconsol.lib.   When I look at the VCC++ directories / Library Directories the $(IFORT_COMPILER16) macro is used but it is not defined if I select the macros button.  There is no IFORT_COMPILER macro defined.  What do I do to tell Visual Studio the value of IFORT_COMPILER16 should be? 

Thank you 

Caroline

 

 

 

 

Thread Topic: 

Question

Following in Steve's footsteps

$
0
0

Hi everyone,

Well, tomorrow is my last day and I too will be riding off into the sunset of retirement. After 45 years of being allowed to play with computers, from mainframes to micros, I am finally hanging up my keyboard and coding pad.

I know that for the last few years I haven't been able to contribute as much as I would have liked to this forum. I have been without a Fortran compiler at work for some time, but I have regularly visited the forum and tried where possible to add my 2p worth if I thought it could help.

I would like to say thank you to all of the other contributors from whom I have learned so much over the years, and from whom I have received help when I needed it. I am hesitant to name anyone in case I miss someone out. :-)

I wish you all a Merry Christmas and a Happy New Year (and I hope IanH does get a new compiler from Santa!)

Thank you all.

Les

Endless Blathering

$
0
0

Why dont you allow a remote login/assist , that would make it real simple to show someone what is going on, instead of this endless blather going back and forth ?

I was interested in this rather interesting comment in another topic. 

1. Most of the people who inhabit this forum have another job and this is just for fun, to learn and as a service to the broader Fortran community. 

2. The terseness of your comments and the comments on other people is in the long run counter productive. The fact that you ask simple questions that anyone with a basic knowledge of Fortran or VS should be able answer is pretty obvious and one that is also a strain on the time of these good people who do answer serious questions.  The fact that they continue to answer the questions in the face of some very negative comments shows their ability to turn the other cheek.

3. There are several excellent textbooks on many of the subjects you raise, can I suggest politely you read a few books, I would suggest Knuth, Abelson and Sussman and Winston and Horne. 

4. There are very many IDE they are configured by humans, we are all human, choose another - or better yet get another Fortran compiler say Laheys.

just a few polite thoughts 

John

 

 

TWO Line program hangs up the debugger

$
0
0

        read(*,*)

         end

 

When it gets to the READ statement, I want to close the window, which generates a breakpoint.

But when I wanna quit and do something else, I get the little blue circle, and then it makes some remark about "debugger is unstable, save all files and exit"

 

so apparently, the debugger is going off into la-la-land, and hanging everything else up, 

I have to close the VISUAL 2013 app entirely and start over, to do anything else.

 

Dont they test this stuff ? Too bad we're stuck with Microsoft products.

Unexpected linker error "LNK2001: unresolved external symbol" and an ICE

$
0
0

The following simple code compiled using Intel Fortran compiler 17 update 1 and no optimization (/Od option) generates a linker error I have never seen before, "unresolved external symbol ????":  With optimization (/O), compilation of the main program results in an internal compiler error.

module m

   implicit none

   private

   type :: t
      private
      procedure(Ifoo), nopass, pointer :: m_foo_ptr => foo
   contains
      private
      procedure, nopass :: foo
      procedure, pass(this), public :: bar
   end type t

   abstract interface

      pure subroutine Ifoo( this )

         import :: t

         implicit none

         !.. Argument list
         type(t), intent(inout), optional :: this

      end subroutine Ifoo

   end interface

   interface t
      module procedure construct_t
   end interface t

   public :: t

contains

   function construct_t( foo_ptr ) result( new_t )

      !.. Argument list
      procedure(Ifoo), optional :: foo_ptr
      !.. Function result
      type(t) :: new_t

      if ( present( foo_ptr ) ) then
         new_t%m_foo_ptr => foo_ptr
      end if

      return

   end function construct_t

   pure subroutine foo( this )

      !.. Argument list
      type(t), intent(inout), optional :: this

      if ( present(this) ) then
      end if

      return

   end subroutine foo

   subroutine bar( this )

      !.. Argument list
      class(t), intent(inout) :: this

      if ( associated(this%m_foo_ptr) ) then
         call this%m_foo_ptr( this )
      end if

      return

   end subroutine bar

end module m
program p

   use m, only : t

   implicit none

   type(t) :: foo

   call foo%bar()

   stop

end program p

Here's the information on the linker error:

C:\..>ifort /c /Od /standard-semantics /stand /warn:all m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.


C:\..>ifort /c /Od /standard-semantics /stand /warn:all p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.


C:\..>link /out:p.exe /subsystem:console p.obj m.obj
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

p.obj : error LNK2001: unresolved external symbol ????
p.exe : fatal error LNK1120: 1 unresolved externals

Here're the details of the internal compiler error, shown with /O1 optimization but the error occurs with all three levels:

C:\..>ifort /c /O1 /standard-semantics /stand /warn:all m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.


C:\..>ifort /c /O1 /standard-semantics /stand /warn:all p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for p.f90 (code 1)

 

No symbol file libifcoremd causing Instrumention Failed in Visual Studio 2015

$
0
0

 I want to use Visual Studio Performance Wizard to get the analysis (number of function calls) of my solution which include multiple projects written in Intel Visual FORTAN, Visual Studio C++ and C#. But Instrumentation analysis failed with the following warning and error.

Warning VSP2005: Internal instrumentation warning: The object '\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.1.146\windows\compiler\lib\intel64\ifmodintr.lib(./frtl/static/iso_c_binding.obj)' was built without debug information.

Error VSP1033: The file 'C:\Development\abc\x64\Release\abc.exe' does not contain a recognized executable image.

PRF0002: Instrumentation failed with these options: /u "C:\Development\abc\x64\Release\abc.exe"   /excludesmallfuncs.  Please check the output window for additional details.

It seems Visual Studio won't allow instrumentation until it gets all symbols files.

Following symbol file is missing from FORTRAN project: "libifcoremd.pdb".

Can I get this file or is there any other way to make it work.

Thanks

Babar

 

Zone: 

Thread Topic: 

Question

Link statically with MKL

$
0
0

Hi,

I have a program that calls an MKL eigenvalue subroutine and I want to distribute copies of my program to others within my firm. Is it possible to link MKL statically? I understand this is not the preferred option, but static linking avoids many installation headaches. I am already linking the runtime libraries statically. Also, is there an option in Developer Studio for this? If not, I supposed I can still do it via the Command Line tab in DevStudio.

Thanks and my apologies if the question has been asked before.

Gabriel

ICE with 17 update one and MERGE/PRESENT/C_PTR/BIND(C)/VALUE...

$
0
0

The following causes an ICE with 17 update one.

MODULE m
  IMPLICIT NONE
CONTAINS
  SUBROUTINE ice(arg)
    USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_LOC, C_NULL_PTR
    INTEGER, OPTIONAL :: arg

    CALL proc(MERGE(C_NULL_PTR, C_NULL_PTR, PRESENT(arg)))
  END SUBROUTINE ice

  SUBROUTINE proc(ptr) BIND(C)
    USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_PTR
    TYPE(C_PTR), VALUE :: ptr
  END SUBROUTINE proc
END MODULE m

 

>ifort /c /check:all /warn:all /standard-semantics "2016-12-17 ice.f90"
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

2016-12-17 ice.f90(11): remark #7712: This variable has not been used.   [PTR]
  SUBROUTINE proc(ptr) BIND(C)
------------------^
2016-12-17 ice.f90(8): catastrophic error: **Internal compiler error: internal abort** 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.
compilation aborted for 2016-12-17 ice.f90 (code 1)

 

Two line program wont link ?

$
0
0

program test

end

 

It says"LINK error 1561"

No entry point defined.

Why would a main program have an entry point ?

 

what a god-awful mess - - - 

COM-server returning (safe)array of BSTR works under 32 bits but not under 64

$
0
0

Hi,

I have created a COM server with the wizard. This COM-server returns [out, retval] SAFEARRAY(BSTR)* VALUE

When I build this for a 32-bits platform it works fine and I can call this array from several 32-applications

However when I build this for a 64-bits platform it doesn't work. A Delphi-client gives " (EVariantArrayLockedError: Variant or safe array is locked)" and Powershell crashes when I try to access the array. Besides all other properties and methods are working under 32 as well 64 bit.

Does anyone have an idea where to look for the failure

 

Thanks

Aid Usman 

 

Compiler message not so clear: Common and Equivalence clash

$
0
0

Given the following program, IFort correctly refuses to compile, and rightly so.

program xeq
   implicit none
   logical  re,pe
   integer  rf,pf
   equivalence (re, rf), (pe, pf)

   common/RPCOM/re,pe,rf,pf

   print *,loc(re),loc(rf)
end

However, the error message does not clearly identify the problem, and seems to invite the user to try different alignment directives and compiler options. 

Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

xeq.f90(3): error #6501: The equivalences are causing alignment problems.   [RE]
   logical   re,pe
-------------^
xeq.f90(3): error #6501: The equivalences are causing alignment problems.   [PE]
   logical   re,pe
----------------^
compilation aborted for xeq.f90 (code 1)

The real problem with the code is that re and rf occupy the same storage -- the first storage unit of the block; pe and pf do likewise -- the second storage of the block. In other words, the same storage unit appears more than once in the list of common block variables. Gfortran's error message is quite clear:

xeq.f90:7:24:

    common/RPCOM/re,pe,rf,pf
                        1
Error: Symbol 'rf' at (1) is already in a COMMON block

 

UDDTIO: can the compiler issue a more meaningful error code during defined read of an internal file unit?

$
0
0

Fortran 2008 standard  (WD 1539-1 J3 10-007r1 24th November 2010)  document says in section 9.6.4.8.3 Defined input/output procedures:

Consider the following simple code:

module t_m

   use, intrinsic :: iso_fortran_env, only : iostat_end, iostat_eor, output_unit

   implicit none

   private

   type, public :: t
      private
      character(len=:), allocatable :: m_s
   contains
      !private
      procedure, pass(this), private :: read_t
      generic :: read(formatted) => read_t
   end type t

contains

    subroutine read_t(this, lun, iotype, vlist, istat, imsg)

      ! argument definitions
      class(t), intent(inout)         :: this
      integer, intent(in)             :: lun
      character(len=*), intent(in)    :: iotype
      integer, intent(in)             :: vlist(:)
      integer, intent(out)            :: istat
      character(len=*), intent(inout) :: imsg

      !.. Local variables
      character(len=*), parameter :: sfmt = "(*(g0))"
      character(len=1) :: c
      integer :: i

      i = 0
      loop_read: do

         i = i + 1

         read( unit=lun, fmt="(a)", iostat=istat, iomsg=imsg ) c
         select case ( istat )
            case ( 0 )
               write( output_unit, fmt=sfmt) "i = ", i, ", c = ", c
            case ( iostat_end )
               write( output_unit, fmt=sfmt) "i = ", i, ", istat = iostat_end"
               exit loop_read
            case ( iostat_eor )
               write( output_unit, fmt=sfmt) "i = ", i, ", istat = iostat_eor"
               exit loop_read
            case default
               write( output_unit, fmt=sfmt) "i = ", i, ", istat = ", istat
               exit loop_read
         end select

      end do loop_read

      return

   end subroutine read_t

end module t_m
program p

   use t_m, only : t

   implicit none

   character(len=:), allocatable :: s
   type(t) :: foo
   character(len=256) :: imsg
   integer :: istat

   s = "Hello"
   read( unit=s, fmt=*, iostat=istat, iomsg=imsg ) foo
   if ( istat /= 0 ) then
      print *, "istat = ", istat
      print *, imsg
   end if

   stop

end program p

Upon compilation and executing using Intel Fortran compiler 17 update 1, the output is

i = 1, c = H
i = 2, c = e
i = 3, c = l
i = 4, c = l
i = 5, c = o
i = 6, istat = 67
 istat =  67
 User Defined I/O procedure returned error 67, message: input statement requires
 too much data, unit -5, file Internal List-Directed Read

Is this conformant with the standard?

Note for the same, gfortran issues the error code of iostat_end which appears more meaningful in this context.

Can Intel Fortran development team please review this and follow up as needed?

Thanks,

 

Problem with IMSL with Intel Visual Fortran Composer

$
0
0

Hey

I use Intel Visual Fortran Composer with IMSL libraries and Microsoft Visual studio 10

Here is a piece of my code :

program main  
      !use imsl_libraries
      USE ZANLY_INT 
      USE WRCRN_INT
      INCLUDE 'link_fnl_shared.h' 

      IMPLICIT   NONE
!     Declare variables
      Real(8)  ERRABS,ERRREL
      INTEGER    INFO(3), NGUESS, NNEW
      COMPLEX(8)    F1, F2, Z(3), ZINIT(3)
      EXTERNAL   F1, F2
!     Set the guessed zero values in ZINIT
!     ZINIT = (1.0+1.0i 1.0+1.0i 1.0+1.0i)
      DATA ZINIT/3*(0.52,-0.16)/

!     Set values for all input parameters
      NNEW   = 3
      NGUESS = 0
      
!     Find the zeros of F
      CALL ZANLY (F2, Z, ERRABS=1.e-8,ERRREL=1.e-8, NNEW=NNEW, NGUESS=NGUESS,ZINIT=ZINIT, ITMAX=100000, INFO=INFO) !
!     Print results
      !CALL WRCRN ('The zeros of (Z**3 + 5.0*Z**2 + 9.0*Z + 45.0) are', Z)
      write(*,*) 'Exemple 1 : The zeros of (Z**3 + 5.0*Z**2 + 9.0*Z + 45.0) are :'
      write(*,"(3('('F10.6','F10.6') '))") Z
      print *,INFO(1),F2(Z(1))  ! nombre d'ittérations et résultat
      write(*,*) '===================================================================='
      
      DATA ZINIT/3*(0.52,-0.16)/
      NNEW   = 1
      NGUESS = 1
      CALL ZANLY (F1, Z, ERRABS=1.e-8,ERRREL=1.e-8, NNEW=NNEW, NGUESS=NGUESS,ZINIT=ZINIT, ITMAX=100000, INFO=INFO) !
!     Print results
      !CALL WRCRN ('The zeros of (exp(Z)-(3+3i) are', Z)
      write(*,*)'Exemple 2 : The zeros of [exp(Z)-(3+3i)] are :'
      write(*,"(2('('F10.6','F10.6') '))") Z
      print *,INFO(1),F1(Z(1))
      stop
      END program
      
!     External complex function
      COMPLEX (8) FUNCTION F2 (Z)
      COMPLEX (8)    Z
      F2 = Z**3 + 5.0*Z**2 + 9.0*Z + 45.0
      RETURN
      End
    
      COMPLEX (8) FUNCTION F1 (Z)
      COMPLEX (8)    Z
      F1 = Z**2*cdexp((3.0,3.0)*Z)-(3.0,3.0)
      RETURN
      END

My problem : this code works with simple precision but when I try to use the routine Zanly with double precision (like in the above code).

I have the following message after compilation:

Error    1     error #6285: There is no matching specific subroutine for this generic subroutine call.   [ZANLY]  

Zanly seems to be not recognized.

I have try to use several things but without success. Could you give me a solution to this problem.

When I use only simple precision, the code works fine???

 

Sincerely


Unreachable Code

$
0
0

I have inherited a code that has a lot of poor coding techniques.  In the ~50,000 lines of FORTRAN there is a significant amount of code that can never be reached.  In older mainframe compilers (e.g., FTN for CDC machines) the compiler cross-reference map would help to find such coding problems.  Is there  a way to use Intel's compiler to find such problems?

Zone: 

Thread Topic: 

Question

Providing a SafeArray to a COM object

$
0
0

Dear All,

I am trying to pass an array of floats using a COM object written in C#.

After registering the COM DLL, the code is created by the FORTRAN COM Wizard in Daniel-COM.f90

In Daniel-main.f90, I create a class which uses the array_test function from the COM object.

The interface to array_test requires safe arrays.

Q1. Which function from the COM object should I use ($$AnalysisDb_ArrayTest or $IAnalysisDb_ArrayTest)? What is the difference?

Q2. I use two procedures MakeVariantSafeArray and GetVariantSafeArray, Is this the correct way to create a safe array for to pass to the COM object? (Needless to say that the call to $$AnalysisDb_ArrayTest fails to return zero (0=success); the program compiles and builds fine).

Any ideas on the above?

Thank you for your efforts.

Daniel.

Thread Topic: 

Help Me

Interpreting VTune's resutls

$
0
0

Recently I have been working on optimizing a Fortran code.  I have noticed that the VTune profiling results indicate one of the subroutine declaration line took a considerable amount of time.  I'm not sure how this should be interpreted.  Any suggestions would be appreciated.  Thanks!

Zone: 

A forum problem: "Your submission contains invalid characters and will not be accepted" message

$
0
0

A couple of times recently while trying to create a new forum topic, I have encountered the "Your submission contains invalid characters and will not be accepted" message with no information on the invalid characters or any indication even of which sentence or the paragraph or the section might have the problem:

Is it possible for the contributors to receive some guidance from the system when they run into such issues in the future?

Like all self-righteous users out there, I don't believe I was doing anything wrong of course! :-)  I was simply trying to enter some normal text and Fortran code using the forum fields and the {..}(sub code) link.  It was painful each time to continue to reattempt the topic creation by copying and pasting text and code in separate chunks and simply hope to overcome the problem.

In one case (https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo...), I think the problem was some hidden character in the error message from the Microsoft linker.  But I was pasting the command prompt text into the {..}(sub code) window with a Plain Text selection, so I don't understand why this link itself couldn't parse out any offending characters.

In the other case, I couldn't narrow it down and barely managed to submit the issue following multiple attempts by trial and error.

I will appreciate any and all improvements Intel can make to the forum in order to enhance the reader experience.

Thanks,

 

 

Error passing string to subroutine

$
0
0

Strange behaviour which I have only observed since installing XE2017 update 1, but don't know how long this has been happening.

        I = LEN_TRIM(logtext)
        CALL WriteScrollLine(browse_log,logtext(1:I))

I reports 22

logtext contains "Case No.   1 loaded 80" (variable length actually 80)

Subroutine WriteScrollLine(box, text)

IMPLICIT NONE

INTEGER, INTENT(IN) :: box
CHARACTER (LEN=*), INTENT(IN) :: text

text is now blank with length 0.

This does not happen on all calls.  Most calls to the subroutine run as expected.

Any ideas?

Thanks

David

Viewing all 5691 articles
Browse latest View live


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