Hello,
I tried to compile a fortran source code in Visual studio ultimate 2013 with update 5. I am using a Intel XE parallel studio _update 6 compiler (Free for students) and they are already linked. When I compile for my source code, i get 2 errors. I would be highly helpful if someone could help me out with this.
The source code (basically subroutine) was written in visual studio itself.
I am attaching my build log.
Thanks in Advance!
| Attachment | Size |
|---|---|
Download Build log.txt | 877 bytes |
What is the status of the Intel Static Security Analysis (SSA) product? Does it require a separate purchase? Will it work with the command line on Linux with Intel Fortran 16?
Jay
I am writing intel fortran code that is going to be compile into two dll, one will be called from excel 32 bits VBA code and the other from excel 64 bits VBA code.
I do not have problems calling and running the dll in 64 bits but I have problem in 32bits. In 32 bits, I have add the sequence statement in my type statement (see below). I am also using the Stdcall convention and the sequence type = Yes(/align:sequence)
I did a write statement of the arguments at entry in the dll and I figure that I am getting 0 starting with the first real*8 variable. Real*8 variables are declared as double in VBA
I am using the type statement for my arguments, which does not seems to be cover in the forums.
Does anybody have a hint for solving this problem ?
here is part of my code for the main subroutine of the dll
SUBROUTINE PS(arg)
IMPLICIT NONE
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS : "PS" ::PS
!DEC$ ATTRIBUTES STDCALL :: PS
!DEC$ ATTRIBUTES REFERENCE::arg
type s_data
SEQUENCE
integer sGroup
integer sBIRTH
real*8 sPEN
....
end type
type(s_data) arg
Is it possible to have more than one entry point within one fortran DLL ?
I was able to do that when I was compiling dll with Lahey Fortran.
If yes, can somebody give me some directives on how to proceed ?
Thank you
There was a question in stack overflow about implementing Matlab's diff function in Fortran. First attempt:
! diff.f90 module M use ISO_FORTRAN_ENV implicit none private public diff interface diff module procedure diff2 end interface diff contains recursive function diff2(A,n,dim) result(B) real(REAL64) A(:,:) real(REAL64), allocatable :: B(:,:) integer, optional :: n, dim integer Ndim integer shB(rank(A)) integer shA(rank(A)) integer peB(rank(A)) integer i if(present(n)) then if(n <= 0) then ! allocate(B,source=A) B = A return else if(n > 1) then ! allocate(B,source=diff(diff(A,n-1,dim),1,dim)) B = diff(diff(A,n-1,dim),1,dim) return end if end if if(present(dim)) then if(dim <= 0 .OR. dim > rank(A)) then ! allocate(B,source=A) B = A return else Ndim = dim end if else Ndim = 1 end if shB = shape(A) shB(Ndim) = shB(Ndim)-1 if(any(shB <= 0)) then allocate(B(shB(1),shB(2))) return end if peB = [(i,i=1,rank(A))] if(Ndim /= rank(A)) then peB([Ndim,rank(A)]) = peB([rank(A),Ndim]) end if shA = shape(A) ! allocate(B,source=reshape(reshape(eoshift(A,1,dim=Ndim)-A,shB1,order=peB),shB,order=peB)) B = reshape(reshape(eoshift(A,1,dim=Ndim)-A,shA(peB),order=peB),shB,order=peB) end function diff2 end module M
! main.f90
program P
use M
use ISO_FORTRAN_ENV
implicit none
real(REAL64), allocatable :: A(:,:), B(:,:)
integer M1, N
character(20) fmt
integer i,j
integer dim
do dim = 1, rank(A)
M1 = 3
N = 4
write(*,'(a)') 'A ='
A = reshape([((10*i+j,i=1,M1),j=1,N)],[M1,N])
write(fmt,'(*(g0))') '(',size(A,2),'(g0:1x))'
write(*,fmt) transpose(A)
B = diff(A,dim=dim)
write(fmt,'(*(g0))') '(',size(B,2),'(g0:1x))'
write(*,'(a)') 'B ='
write(*,fmt) transpose(B)
end do
end program P
Worked OK with gfortran, but with ifort I got:
diff.f90(55): error #6541: This element is not yet supported in this context. [SHA] B = reshape(reshape(eoshift(A,1,dim=Ndim)-A,shA(peB),order=peB),shB,order=peB ) -----------------------------------------------^ diff.f90(55): error #6361: An array-valued argument is required in this context. [RESHAPE] B = reshape(reshape(eoshift(A,1,dim=Ndim)-A,shA(peB),order=peB),shB,order=peB ) ---------------^ compilation aborted for diff.f90 (code 1)
And there is that error #6541, so what does it mean?
I figured the way to go was to create a rank-invariant expression for diff(A,1,dim=Ndim) so that it could be used in a function or subroutine with an assumed-rank input. Is this possible? Will it be possible when SELECT RANK is available? Actually a test program that incrementally wrote out a rank-invariant expression seemed to work OK, both on gfortran and ifort:
program Q
use ISO_FORTRAN_ENV
implicit none
real(REAL64), allocatable :: A(:,:,:)
integer M, N, P
integer i, j, k
character(30) fmt
integer Ndim
M = 3
N = 4
P = 5
do Ndim = 1, rank(A)
allocate(A(M,N,P))
write(fmt,'(a,i0,a)') '(',size(A,2),'(g0:1x))'
A = reshape([(((100*i**2+10*j**2+k**2,i=1,M),j=1,N),k=1,P)],shape(A))
write(*,'(a)') 'A ='
do i = 1, P
write(*,fmt) transpose(A(:,:,i))
write(*,'()')
end do
write(*,'(*(g0:1x))') 'shape(A) =',shape(A)
write(*,'(*(g0:1x))') '[(i,i=1,rank(A))] =',[(i,i=1,rank(A))]
write(*,'(*(g0:1x))') 'eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) =', &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim)
write(*,'(*(g0:1x))') 'eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)) =', &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A))
write(*,'(*(g0:1x))') '[(i,i=1,rank(A))] + ' // &
'eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + ' // &
'eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)) =', &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A))
write(fmt,'(a,i0,a)') '(',rank(A),'(g0:1x))'
write(*,'(a)') 'spread([1,(0,i=2,rank(A))],2,rank(A)) ='
write(*,fmt) transpose(spread([1,(0,i=2,rank(A))],2,rank(A)))
write(*,'(a)') 'eoshift(' // &
'spread([1,(0,i=2,rank(A))],2,rank(A)), 1-(' // &
'[(i,i=1,rank(A))] +' // &
'eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) +' // &
'eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))) ='
write(*,fmt) eoshift( &
spread([1,(0,i=2,rank(A))],2,rank(A)), 1-( &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A))))
write(*,'(a)') 'matmul(eoshift(' // &
'spread([1,(0,i=2,rank(A))],2,rank(A)), 1-(' // &
'[(i,i=1,rank(A))] +' // &
'eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) +' // &
'eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))),' // &
'shape(A)) ='
write(*,'(*(g0:1x))') matmul(eoshift( &
spread([1,(0,i=2,rank(A))],2,rank(A)), 1-( &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))), &
shape(A))
write(fmt,'(*(g0))') '(',M,'(',N,'(g0:1x)/))'
write(*,'(a)') 'eoshift(A,1,dim=Ndim)-A ='
write(*,fmt) reshape(eoshift(A,1,dim=Ndim)-A,[N,M,P],order=[2,1,3])
write(fmt,'("(",i0,"(",i0,"(g0:1x)/))")') matmul(reshape([1,0,0, &
0,1,0], &
[2,3],order=[2,1]), &
matmul(eoshift( &
spread([1,(0,i=2,rank(A))],2,rank(A)), 1-( &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))), &
shape(A)))
write(*,'(a)') 'reshape(' // &
'eoshift(A,1,dim=Ndim)-A,' // &
'matmul(eoshift(' // &
'spread([1,(0,i=2,rank(A))],2,rank(A)), 1-(' // &
'[(i,i=1,rank(A))] +' // &
'eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) +' // &
'eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))),' // &
'shape(A)),' // &
'order =' // &
'[(i,i=1,rank(A))] +' // &
'eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) +' // &
'eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))'
write(*,fmt) reshape(reshape( &
eoshift(A,1,dim=Ndim)-A, &
matmul(eoshift( &
spread([1,(0,i=2,rank(A))],2,rank(A)), 1-( &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))), &
shape(A)), &
order = &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A))), &
matmul(eoshift( &
spread([1,(0,i=2,rank(A))],2,rank(A)), 1-( &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))), &
shape(A)), &
order=[2,1,3])
write(*,'(a)') 'shape(A)-eoshift([1,(0,i=2,rank(A))],1-Ndim) ='
write(*,'(*(g0:1x))') shape(A)-eoshift([1,(0,i=2,rank(A))],1-Ndim)
write(fmt,'(*(g0))') '(',M-merge(1,0,Ndim==1),'(',N-merge(1,0,Ndim==2),'(g0:1x)/))'
write(*,'(a)') 'reshape(' // &
'reshape(' // &
'eoshift(A,1,dim=Ndim)-A,' // &
'matmul(eoshift(' // &
'spread([1,(0,i=2,rank(A))],2,rank(A)), 1-(' // &
'[(i,i=1,rank(A))] +' // &
'eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) +' // &
'eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))),' // &
'shape(A)),' // &
'order =' // &
'[(i,i=1,rank(A))] +' // &
'eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) +' // &
'eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A))),' // &
'shape(A)-eoshift([1,(0,i=2,rank(A))],1-Ndim),' // &
'order =' // &
'[(i,i=1,rank(A))] +' // &
'eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) +' // &
'eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))'
write(*,fmt) reshape(reshape( &
reshape( &
eoshift(A,1,dim=Ndim)-A, &
matmul(eoshift( &
spread([1,(0,i=2,rank(A))],2,rank(A)), 1-( &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A)))), &
shape(A)), &
order = &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A))), &
shape(A)-eoshift([1,(0,i=2,rank(A))],1-Ndim), &
order = &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim,(0,i=2,rank(A))],1-Ndim) + &
eoshift([Ndim-rank(A),(0,i=2,rank(A))],1-rank(A))), &
[N-merge(1,0,Ndim==2),M-merge(1,0,Ndim==1),P-merge(1,0,Ndim==3)],order=[2,1,3])
deallocate(A)
end do
end program Q
(ifort needs /assume:realloc_lhs for the above.) Encouraged by this result, I started on a version with a constant rank-invariant expression:
program P
use ISO_FORTRAN_ENV
implicit none
integer, parameter :: M = 3
integer, parameter :: N = 4
real(REAL64) :: A(M,N)
integer i, j
parameter(A = reshape([((10*i**2+j**2,i=1,M),j=1,N)],shape(A)))
integer, parameter :: Ndim1 = 1
real(REAL64) :: B1(M-merge(1,0,Ndim1==1),N-merge(1,0,Ndim1==2))
parameter(B1 = reshape( &
reshape( &
eoshift(A,1,dim=Ndim1)-A, &
matmul(eoshift( &
spread([1,(0,i=2,rank(A))],2,rank(A)), 1-( &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim1,(0,i=2,rank(A))],1-Ndim1) + &
eoshift([Ndim1-rank(A),(0,i=2,rank(A))],1-rank(A)))), &
shape(A)), &
order = &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim1,(0,i=2,rank(A))],1-Ndim1) + &
eoshift([Ndim1-rank(A),(0,i=2,rank(A))],1-rank(A))), &
shape(A)-eoshift([1,(0,i=2,rank(A))],1-Ndim1), &
order = &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim1,(0,i=2,rank(A))],1-Ndim1) + &
eoshift([Ndim1-rank(A),(0,i=2,rank(A))],1-rank(A))))
integer, parameter :: Ndim2 = 2
real(REAL64) :: B2(M-merge(1,0,Ndim2==1),N-merge(1,0,Ndim2==2))
parameter(B2 = reshape( &
reshape( &
eoshift(A,1,dim=Ndim2)-A, &
matmul(eoshift( &
spread([1,(0,i=2,rank(A))],2,rank(A)), 1-( &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim2,(0,i=2,rank(A))],1-Ndim2) + &
eoshift([Ndim2-rank(A),(0,i=2,rank(A))],1-rank(A)))), &
shape(A)), &
order = &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim2,(0,i=2,rank(A))],1-Ndim2) + &
eoshift([Ndim2-rank(A),(0,i=2,rank(A))],1-rank(A))), &
shape(A)-eoshift([1,(0,i=2,rank(A))],1-Ndim2), &
order = &
[(i,i=1,rank(A))] + &
eoshift([rank(A)-Ndim2,(0,i=2,rank(A))],1-Ndim2) + &
eoshift([Ndim2-rank(A),(0,i=2,rank(A))],1-rank(A))))
character(30) fmt
write(fmt,'(*(g0))') '(',size(A,2),'(g0:1x))'
write(*,'(a)') 'A ='
write(*,fmt) transpose(A)
end program P
But that one got a C0000005 with ifort.
Hello,
I have troubles deploying code Telemac http://opentelemac.org with Intel Fortran Compiler 16. All routines applying an old trick to skip lengthy records in an unformatted sequential file in order to get to some place in which one wants to read, deliver read error when compiled with optimisation higher than O0. The trick is instead of reading thousands of numbers, just read one number from this record and skip to the next record with next READ, and so on until you get where you want. This trick (a typical old Fortran way of doing things...) stopped working with optimised Intel 16.
I have written a short program containing the original Telemac routines (skipgeo) and a routine being a simple workaround with allocating large enough buffers (skipgeo_improved). The code works well with Intel Fortran 14 and with gfortran (gcc 4.8.4) and yields a read error with optimised Intel 16, catched by a wrapper routine (lit) for the Fortran READ. If you use -warn all -catch all and/or -O0, everything goes well.
I wonder if this is not an optimisation bug. I have not found in the documentation anything about changes in unformatted sequential file treatment.
Please find included code and the file to be read (big endian).
Looking forward for your reactions, best regards,
jaj
| Attachment | Size |
|---|---|
| Downloadreaderr.tgz | 197.89 KB |
All,
Got 2 questions in trying to get Fortran & C TYPES/typdefs working.
First, the typedefs in C;
typedef struct /* Polygon vertex structure */
{
double x; /* Vertex x component */
double y; /* vertex y component */
} gpc_vertex;
typedef struct /* Vertex list structure */
{
int num_vertices; /* Number of vertices in list */
gpc_vertex vertex; /* Vertex */
} gpc_vertex_list;
Now, the Fortran equivalent TYPES;
use, intrinsic :: ISO_C_BINDING
TYPE, BIND(C) :: F_GPC_VERTEX ! /* Polygon vertex structure */
REAL(8) (C_FLOAT) :: x ! /* Vertex x component */
REAL(8) (C_FLOAT) :: y ! /* vertex y component */
END TYPE
TYPE, BIND(C) :: F_GPC_VERTEX_LIST ! /* Vertex list structure */
INTEGER(C_INT) :: num_vertices ! /* Number of vertices in list */
TYPE (F_GPC_VERTEX) :: vertex ! /* Vertex */
END TYPE
Now, the compilation errors with the "REAL(8) (C_FLOAT) :: " x & y with
error #5082: Syntax error, found '(' when expecting one of: :: %FILL , INTEGER REAL COMPLEX TYPE BYTE CHARACTER CLASS DOUBLE DOUBLECOMPLEX ..."
but works with just "REAL (C_FLOAT) :: " ...but the C typdef is a double float. Why will it not allow the REAL(8)?
Two - is the "TYPE (F_GPC_VERTEX) :: vertex" an example of a Type Extension?
Thanks in advance,
Jeff
Hello,
I was trying to understand user-defined derived type I/O, but had some weird issues. I stripped it down to this minimal example:
1 ! ============== ! 2 ! === MODULE === ! 3 ! ============== ! 4 5 module SomeModule 6 7 implicit none 8 9 interface write(formatted) 10 module procedure WriteSomeType 11 end interface 12 13 type SomeType 14 integer :: value 15 end type 16 17 contains 18 19 subroutine WriteSomeType(var, unit, iotype, v_list, ios, iom) 20 21 class(SomeType), intent(in) :: var 22 integer , intent(in) :: unit 23 character(*) , intent(in) :: iotype 24 integer , intent(in) :: v_list(:) 25 integer , intent(out) :: ios 26 character(*) , intent(inout) :: iom 27 28 write(*,*) "DEBUG: using UDTIO" 29 30 write(unit, *, iostat=ios, iomsg=iom) var % value 31 32 end subroutine WriteSomeType 33 34 end module SomeModule 35 36 ! =============== ! 37 ! === PROGRAM === ! 38 ! =============== ! 39 40 program SomeProgram 41 42 use SomeModule 43 44 implicit none 45 46 type(SomeType) :: var 47 48 var % value = 10 49 50 write(*,*) var 51 52 contains 53 54 !subroutine SomeSubroutine(arg) 55 ! 56 ! type(SomeType) :: arg 57 ! 58 ! write(*,*) arg 59 ! 60 !end subroutine SomeSubroutine 61 62 end program SomeProgram
When I compile this with ifort 15.0.1 on CentOS 6 and run it, the output is
DEBUG: using UDTIO 10
indicating, that the the UDTIO subroutine has been used. When I uncomment SomeSubroutine and recompile, the output is
10
so just the usual output of derived types. I do not understand this - I don't even call SomeSubroutine?
Thanks,
Max
Sometimes I forget what is permitted and what is not. This is non-conforming code (says F2008 7.1.12p2), but ifort perhaps got more confused than it should.
PROGRAM MentalBlock
IMPLICIT NONE
BLOCK
INTEGER :: array(2) = SIZE(array)
END BLOCK
END PROGRAM MentalBlock
>ifort /check:all /warn:all /standard-semantics "2016-02-07 MentalBlock.f90" Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Build 20151021 Copyright (C) 1985-2015 Intel Corporation. All rights reserved. 101004_2042 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-02-07 MentalBlock.f90 (code 1)
A variant, that perhaps is conforming...
PROGRAM MentalBlockDeluxe
IMPLICIT NONE
BLOCK
DIMENSION :: array(2)
INTEGER :: array = SIZE(array)
END BLOCK
END PROGRAM MentalBlockDeluxe
>ifort /check:all /warn:all /standard-semantics "2016-02-07 MentalBlockDeluxe.f90" Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Build 20151021 Copyright (C) 1985-2015 Intel Corporation. All rights reserved. 101004_2042 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-02-07 MentalBlockDeluxe.f90 (code 1)
.
IF(ISW .eq. 1 )then ID=0 M=0 L=NDF !------------------------------------------------------------------------------------------------------- ! ! ! !------------------------------------------------------------------------------------------------------ 903 JJ=J1-1 IF(JJ .gt. 0) then 905 DO 910 J=1,JJ DO 910 K=1,6 910 ID = ID + JTYPE(J,K) endif 912 DO 965 IC=1,6 IF(JTYPE(J1,IC) .lt. 1)then 915 DO 916 N=1,NLS 916 ASAT(M + IC,N) = 0.0 else 920 DO 925 N=1,NLS 925 ASAT(M+IC,N)=GK(ID+1,L+N) ID=ID+1 endif 965 end do IF(M .lt. 1) then 980 M=6 J3=J1 J1=J2 ID=0 GO TO 903 endif !------------------------------------------------------------------------------------------------------- ! ! ! !--------------------------------------------------------------------------------------------------- 990 DO 1100 II=1,6 DO 1100 J=1,NLS SR(II,J)=0. DO 1100 K=1,12 1100 SR(II,J)=SR(II,J)+SAT(II,K)*ASAT(K,J) !Write(*,1010)I if(i .eq. 1) then Write(*,1011)LSN(I) Write(sw,1011)LSN(I) endif DO 1020 J=1,NLS write(*,1030)i,(SR(II,J),II=1,6),(-(SR(2,j)+SR(3,j))/Length(I)),(-(SR(4,j)+SR(4,j))/Length(I)) 1020 write(sw,1030)i,(SR(II,J),II=1,6),(-(SR(2,j)+SR(3,j))/Length(I)),(-(SR(4,j)+SR(4,j))/Length(I)) !pause 1030 FORMAT(I4, 5x,1X,5(F11.4,2x),F10.4,1x, F10.4, 1x, F10.4) N=4 J=12 endif
I have been getting rid of all the arithmetic goto's inside this "old" Fortran -- from the 1973 book from Harrison -- I am blowed if I can see an elegant method to get rid of the goto 903. I have had several shots at it and I end up always breaking the program.
Any ideas would be appreciated - I was thinking a do while on M?
Over the years, Visual Fortran users have asked how to get console applications to display color, bold and move the cursor around. "Back in the day", one could do this by loading the driver ANSI.SYS and sending ANSI escape sequences, but that went away after Windows 95. You can do all that stuff with calls to the Windows API console routines, but who wants to do that?
According to this post, a coming update to Windows 10 completely overhauls the console environment, adding support for many ANSI (and VT100) escape sequences. Looks like fun!
Hi All,
I have a "type (T_RECT) rectp" defined and I'm in a WM_PAINT section in an SDI window. I've created a brush as " hBrush = GetStockObject(WHITE_BRUSH)". I've populated the rect by "bret = GetClientRect(hWndMain, rectp)". All the values look good in the debug window but the program crashes at the statement "iret = FillRect ( hDC, rectp, hBrush)" with the message "Unhandled exception at 0x00007FF7DDFB1CD6 in Pearson.exe: 0xC000041D: An unhandled exception was encountered during a user callback.". I am running Intel Fortran 2016.1.146 in x64 mode on a Win 10 x64 OS.
Any ideas what is wrong here?
Thanks,
Brooks V
Hi,
I saw this topic for the visual Fortran compiler for Windows, I get the same warning on OSX for a code that I didn't write.
#6375: Because of COMMON, the alignment of object is inconsistent with its type
https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo...
What does it mean? what are the "potential performance impact"?
Thanks
GB
About 1 out of every 4-5 times, when I start a debug session, it just sits there endlessly.
I thought the firewall had something to do with that, but turning it off does not fix the problem.
and then I noticed a message from the debugger - -
it sometimes mentions something about an "internal process."
Usually it starts right up again, but I have to restart the DEBUG session to do that.
It does not make any difference what I am trying to debug.
Its just a minor annoyance, but is there a way around this?
Hi,
I just ported mixed language code from VS 2012/IF 2013 SP1 to VS2015/IF 2016 and got strange "check-stack" errors. I'm having a static FORTRAN lib with modules which is linked into an MSVC dll. The FORTRAN lib is compiled with /iface:default in has the following interface
module rgtafneu_module
REAL*8 FUNCTION RAUCHGASSCHNITTSTELLE_INTERNAL_INOUT
F (TYP,E1,E2,A1,A2,GAT_SPLIT,AA_,WDT_SWT,GASTYP,REAL_GAS_CORRECTION,FNCVMETHOD,TABLE_ID,
F IER1)
IMPLICIT NONE
INTEGER * 4, INTENT(IN), VALUE :: TYP
REAL * 8, INTENT(IN), VALUE :: E1
REAL * 8, INTENT(IN), VALUE :: E2
REAL * 8, INTENT(IN), VALUE :: A1
REAL * 8, INTENT(IN), VALUE :: A2
type(gat_type), INTENT(INOUT) :: GAT_SPLIT
REAL * 8, INTENT(IN) :: AA_(4)
INTEGER * 4, INTENT(IN), VALUE :: WDT_SWT
INTEGER * 4, INTENT(IN), VALUE :: GASTYP
INTEGER * 4, INTENT(IN), VALUE :: REAL_GAS_CORRECTION
INTEGER * 4, INTENT(IN),VALUE :: FNCVMETHOD
INTEGER * 4, INTENT(IN), VALUE :: TABLE_ID
INTEGER * 4, INTENT(INOUT) :: IER1
when this function gets called directly from C++ I get an exception/error because FORTRAN expects the parameters E1, E2 and A1 to be transferred via float-registers xmm1 to xmm3 AND rdx, r8 and r9 which is NOT the standard fastcall-convention. (see asm-dump at the end)
When I add the "BIND(C)" attribute to the function everything works fine again but I've got some questions:
- where can I find the documentation to this non-standard changing of parameter passing
- since I produce (at least I expect to) a COFF static FORTRAN library, I expect it to be fully compatible to the standard. Is there any way to enforce this (apart from adding BIND(C) to every function/procedure)
- how compatible are static FORTRAN 2016-libraries with older FORTRAN code? (Since there is no change in the name-mangling I expect not.)
best ragards
Tobias
------------------------------------------------------------------------------------------------------
asm-dump of BIND(C) version:
REAL*8 FUNCTION RAUCHGASSCHNITTSTELLE_INTERNAL_INOUT
000000000BB991D7 push rbp
000000000BB991D8 sub rsp,3F0h
000000000BB991DF lea rbp,[rsp+70h]
000000000BB991E4 mov qword ptr [rsp],rax
000000000BB991E8 mov rax,3ECh
000000000BB991EF mov dword ptr [rsp+rax],0CCCCCCCCh
000000000BB991F6 sub rax,4
000000000BB991FA cmp rax,4
000000000BB991FE jg RGTAFNEU_MODULE_mp_RAUCHGASSCHNITTSTELLE_INTERNAL_INOUT+18h (0BB991EFh)
000000000BB99200 mov rax,qword ptr [rsp]
000000000BB99204 mov dword ptr [rsp],0CCCCCCCCh
000000000BB9920B mov dword ptr [rsp+4],0CCCCCCCCh
000000000BB99213 mov qword ptr [rbp+378h],rsi
000000000BB9921A mov qword ptr [rbp+370h],rbx
000000000BB99221 mov dword ptr [TYP],ecx
000000000BB99227 movsd mmword ptr [E1],xmm1 !<<<<<<<<< float transferred via xmm
000000000BB9922F movsd mmword ptr [E2],xmm2 !<<<<<<<<< float transferred via xmm
000000000BB99237 movsd mmword ptr [A1],xmm3 !<<<<<<<<< float transferred via xmm
000000000BB9923F fld qword ptr [A2]
000000000BB99245 wait
000000000BB99246 fstp st(0)
000000000BB99248 mov byte ptr [rbp+299h],0
000000000BB9924F mov byte ptr [rbp+29Ah],0
000000000BB99256 mov byte ptr [rbp+298h],0
000000000BB9925D mov byte ptr [rbp+298h],1
000000000BB99264 movsd xmm0,mmword ptr [string L"ERROR : Unable to in"...+4700h (0C03EF80h)]
000000000BB9926C movsd mmword ptr [RAUCHGASSCHNITTSTELLE_INTERNAL_INOUT],xmm0
F (TYP,E1,E2,A1,A2,GAT_SPLIT,AA_,WDT_SWT,GASTYP,REAL_GAS_CORRECTION,FNCVMETHOD,TABLE_ID,
F IER1) BIND(C,NAME='RGTAFNEU_MODULE_mp_RAUCHGASSCHNITTSTELLE_INTERNAL_INOUT')asm-dump of non-BIND(C) version:
REAL*8 FUNCTION RAUCHGASSCHNITTSTELLE_INTERNAL_INOUT
000000000BB891D7 push rbp
000000000BB891D8 sub rsp,3F0h
000000000BB891DF lea rbp,[rsp+70h]
000000000BB891E4 mov qword ptr [rsp],rax
000000000BB891E8 mov rax,3ECh
000000000BB891EF mov dword ptr [rsp+rax],0CCCCCCCCh
000000000BB891F6 sub rax,4
000000000BB891FA cmp rax,4
000000000BB891FE jg RGTAFNEU_MODULE_mp_RAUCHGASSCHNITTSTELLE_INTERNAL_INOUT+18h (0BB891EFh)
000000000BB89200 mov rax,qword ptr [rsp]
000000000BB89204 mov dword ptr [rsp],0CCCCCCCCh
000000000BB8920B mov dword ptr [rsp+4],0CCCCCCCCh
000000000BB89213 mov qword ptr [rbp+378h],rsi
000000000BB8921A mov qword ptr [rbp+370h],rbx
000000000BB89221 mov qword ptr [TYP],rcx
000000000BB89228 mov qword ptr [E1],rdx !<<<<<<<<< float expected in rcx (non-standard fastcall)
000000000BB8922F mov qword ptr [E2],r8 !<<<<<<<<< float expected in r8 (non-standard fastcall)
000000000BB89236 mov qword ptr [A1],r9 !<<<<<<<<< float expected in r9 (non-standard fastcall)
000000000BB8923D mov byte ptr [rbp+299h],0
000000000BB89244 mov byte ptr [rbp+29Ah],0
000000000BB8924B mov byte ptr [rbp+298h],0
000000000BB89252 mov byte ptr [rbp+298h],1
000000000BB89259 movsd xmm0,mmword ptr [string L"ERROR : Unable to in"...+4700h (0C02EF80h)]
000000000BB89261 movsd mmword ptr [RAUCHGASSCHNITTSTELLE_INTERNAL_INOUT],xmm0
F (TYP,E1,E2,A1,A2,GAT_SPLIT,AA_,WDT_SWT,GASTYP,REAL_GAS_CORRECTION,FNCVMETHOD,TABLE_ID,
F IER1)
The following simple code works fine with gfortran but fails with an unexpected "has stopped working" message with Intel compiler (version 16, update 1). It feels like one of those simple code constructs that has worked umpteen times previously with Intel compiler but something has changed which causes it to fail now. But I just can't figure out the problem.
module m
use, intrinsic :: iso_c_binding, only : c_char, c_int, c_ptr, c_f_pointer
use, intrinsic :: iso_fortran_env, only : output_unit
implicit none
contains
subroutine Fsub( Str, LenStr ) bind(C, name="Fsub")
!.. Argument list
type(c_ptr), intent(in), value :: Str
integer(c_int), intent(in), value :: LenStr
blk: block
character(kind=c_char,len=LenStr), pointer :: f_str => null()
call c_f_pointer( Str, f_str )
write(output_unit,*) "In Fsub: Str is ", f_str
f_str => null()
end block blk
!..
return
end subroutine Fsub
end module m#include <string.h>
void Fsub(const char *, int);
int main()
{
const char * s = "Hello World!";
int len_s;
len_s = strlen(s);
Fsub(s, len_s);
return(0);
}C:\temp>ifort /c /standard-semantics /warn:all f.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R ) 64, Version 16.0.1.146 Build 20151021 Copyright (C) 1985-2015 Intel Corporation. All rights reserved. C:\temp>cl /c c.c Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64 Copyright (C) Microsoft Corporation. All rights reserved. c.c C:\temp>link c.obj f.obj /out:p.exe Microsoft (R) Incremental Linker Version 12.00.40629.0 Copyright (C) Microsoft Corporation. All rights reserved. C:\temp>p
Hello,
The following does not compile with 15.0.1:
module m_module
implicit none
type :: TypeB(int)
integer, len :: int
integer :: val(int)
end type
type :: TypeA
type(TypeB(:)), allocatable :: bar
end type
type(TypeA) :: foo
end module m_modulebut returns
101004_2049 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 param_dt_bug.f90 (code 1)
Is it not standard F2003?
Cheers,
Max
Okay, I know this has been hashed through with the USE DFPORT possibility, but I just compiled up my code which had been using IFPORT and found some really weird results without USE IFPORT. The idea was to compile the app I have using strictly USE ***, ONLY clauses. The app is a QuickWin application with a few Windows API calls interspersed and the getting of an environment variable on the front end.
Diligently I went through the code and found clauses along the lines of
USE Strawberry
and commented them out. I then let the VS compiler/linker catch all my missing references. The code is compiled with IMPLICIT NONE everywhere. In doing this the compiler/linker never found the missing reference to GETENV. Thus it was not "missing" at all, but I am unsure what it found because it certainly did not work. The program hung very early in the INITIALSETTINGS call (QuickWin) and never pulled its way out. Very strange.
when optimization by means of fma of instructions is realized?
I'm doing mixed C++/FORTRAN development and reference FORTRAN symbols from static libs in C++ code. During regression test for switching from VS2012/IF2013 to VS2015/IF2016 I had to add BIND(C) to all exported functions/procedures (due to a change of the call-semantics for VALUE-tagged parameters). Since I also reference parameter-arrays I tried to also "BIND(C)" them but got an error and found https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo... , but there only scalar-constants are mentioned. My question is: Since I can't BIND(C) parameter-arrays, is there any guarantee on the layout of parameter-arrays (resp. is there a way to enforce a special layout)?