Here is test code. It reads properly the first time when text=".", but fails after writing (which causes removal of quotes) and rereading.

      character(len=10)::text
      namelist/l/text
      open(1,file='test.in',action='read')
      read(1,l,err=999)
      write(*,l)
      close(1)
      open(1,file='test.in',action='write')
      write(1,l)
      close(1)
      open(1,file='test.in',action='read')
      read(1,l,err=999)
      write(*,l)
      stop
 999  continue
      write(*,*)'ERROR in namelist read'
      end

I installed Visual Studio 2015 and then the Composer XE 2016 Update 1. When I tried to run the psxevars.bat I get the error: Visual Studio 2010, 2012, 2013 or 2015 not found in the system. I checked the folder of Visual Studio 2015 and I have noticed that the Microsoft Installer created a folder C:\Program Files (x86)\Microsoft Visual Studio 14.0. What could be the problem? I can start the Microsoft Visual Studio 2015 with no problem. Any help to get me started will be appreciated.

The following directive in the beginning of my code (partially shown below)

!DEC$OBJCOMMENT LIB:'INLATHENA.LIB'
!
      Options /EXTEND_SOURCE
      Program MAIN
!
!:Variable Declarations Section
!
      Implicit None

causes the Intel compiler v16.0 Update 1 (pack 146) to issue the following error:

ALG01.FOR(3): remark #5082: Directive ignored - Syntax error, found HEX_OCT_BIN_CONSTANT 'BINLATHENA.LIB' when expecting one of: <CHARACTER_CONSTANT>
!DEC$OBJCOMMENT LIB:'INLATHENA.LIB'
--------------------^

There was no problem with the Compiler version 11.1. Does this mean that I can no longer use the above directive or is there a workaround?

Michael

I try to use openmp to enhance my program on multi-core PC. But find no effects.

I can not explain why. It is difference from what i read from books and docs.

Following is my demo code. In my laptop (intel i5 3210M , 2 cores, 4 Threads ), 2 threads is always slower than 1 thread.

Compile with /qopenmp and default release options.

    program Console1
    use omp_lib
    implicit none

    common /C1/ a, b
    integer, parameter :: N = 5000000
    logical, parameter :: iopenmp = .true.
    real :: a(N), b(N)
    real :: cc
   
    integer :: i, j, m
    integer :: nThreads_default = 4, nThreads = 2
    real :: t1, t2, t3
   
   
    m= OMP_GET_NUM_PROCS()
    print *, 'cpu number: ', m
    m = OMP_GET_MAX_THREADS()
    print *, 'Local max threads by openmp: ', m
    print *, 'Parallel threads: ', nThreads
   
    call omp_set_num_threads( nThreads )

10    call CPU_TIME(t1)   
   
   
!$omp PARALLEL do private(cc) if (iopenmp)

    do i = 1, N
        if (i==1) print*, 'parallel threads number:', OMP_GET_NUM_THREADS()

        a(i) = sin(cos(cos(sin(float(i)))))
        if (a(i) > 0.5D0) then
            b(i) = log(abs(a(i)))
            if (b(i) > 0D0) then
                cc = b(i) ** i
            else
                cc = abs(b(i)) ** (1/float(i))
            end if
           
        else
            b(i) = log(abs(1-a(i)))
            if (b(i) > 0D0) then
                cc = b(i) ** i
            else
                cc = abs(b(i)) ** (1/float(i))
            end if           
        end if
        a(i) = abs(cc) ** ( a(i) )
    end do
!$omp end parallel do
   
    call CPU_TIME(t2)   
    print *, 'total time: ', t2-t1
    
    read*, m
    if (m <= 0) goto 10
    print*, a(m), b(m)

   
    end program Console1

Hello,

I am writing the fortran code to call a subroutine in parallel loop. Last command in the subroutine is to write an output file (one file on each call). Here's the pseudo code.

program omp
use omp_lib
implicit none
integer   :: i,n,a(1000)
integer   :: b(1000)
integer   :: fi
n=1000
fi=11
open(UNIT=fi,file='inp.txt')
!$omp parallel default(private) shared(fi,a,b,n)
!$omp do
do i=1,n
    !$omp critical
    read (fi,*) a(i)
    !$omp end critical
    call expo4(a(i),b(i))
end do
!$omp end do
!$omp end parallel
close(fi)
open(12,file='out.txt',action='write')
do i=1,n
write(12,*) b(i)
end do
close(12)
end program


subroutine expo4(a,b)
implicit none
integer, intent(in)  :: a
integer, intent(out) :: b
character*32         :: fname
integer              :: f
b = a**4
write(fname,'(A,I6.6)') 'temp.',a
open(f,file=trim(fname),action='write')
write(f,*) b
close(f)
return
end subroutine

There were two issues with it, when I started. 1) I used a number "31" for fine unit specified in subroutine, which threads could not differentiate. So, I changed to the a variable. 2) there is a mismatch between what was printed in temp.xxx files and in array b(:). Array b(:) is not sequentially updated as it should be. I am not sure what am I missing here. Looking for help.

here is the test code:

      character(len=100)::buf
      write(buf,*)0.,'ABC'
      write(*,*)buf
      end

With intel (Composer XE 2015) the output is

 0.0000000E+00ABC

while with G95 it is

 0. ABC

Note the space with G95, which allows a subsequent read(...,*).

This seems like a bug to me.

This question arose on a webinar recently.  Looking into it, there is more to it than I recognized at first.

Besides evident differences such as the "legacy" Intel specific directive being applicable to array assignments as well as do loops, there is frequently a performance deficit for the omp simd.  Looking at generated code, the biggest differences appear to be in more frequent use of AVX vmaskmov instructions for omp simd.

The OpenMP is a bit more trouble, as it involves checking opt-report to see if all the alignments are taken, besides not (to my knowledge) allowing for cases where arrays are aligned at elements other than the first.

Could anyone explain why the older directive (what is it called nowadays, surely not Cilk(tm) Plus?) should produce more efficient code when both are applicable?  I would see a stronger argument for portable code if it were as efficient.  It would also help with the idea of controlling all vectorization by omp simd directives, if anyone buys into that idea.

I suspect a similar situation arises between #pragma vector aligned and omp simd with C for loops; I'll check further if it's of interest.  Some C compilers require one or the other pragma to be protected by ifdef or the like, considering them as erroneous syntax.  Fortran is more forgiving.

gfortran doesn't appear to take advantage of directive, so I'm not surprised that it has the problem with use of vmaskmov (as it has to deal with more misalignments), as well at not always vectorizing cases where ifort needs directives.

I could post some examples or try to submit IPS if it's of interest.
 

I have just modified my settings to compile a  programme in x64 (Visual Studio 2008, professional; compiler v11.0.075.) and run it on Windows 10.

I have changed no code but now I can no longer interact with the program using the keyboard.

I have used incharqq() to test where the problem arrives and I have keyboard input until I create a dialog

retint = DlgModal( dlg )

Within the dialog, I can use the keyboard to enter data but when I exit using the following command

CALL dlgexit (dlg)

I lose the keyboard.

Icharqq() immediately after the DlgModal command no longer works.

I would like to continue to post my performance problem with array operations a in a new topic. Some history can be found in  https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/605372#comment-1854000 and http://openmp.org/forum/viewtopic.php?f=3&t=1682 . Some of the participants in these previous discussions got better performance on their HW and compilers than me. I also was advised to go for MKL and this is part of this topic. The dissapointing message: neither OMP nor MKL are faster than simple Do loops on my laptop.

My questions are: is it that my hardware is not suited for parallel calculations, or did I forget to use some special compiler options, or does HT in my Win7x64 home premium SP1 impede the performance (don't know how to supress it)? I am attaching my processor details (bandwidth issue etc.).

This is the test code, trying to compare Do-loops, vector notation, OMP and MKL.

! TESTS 26.12.2015
! Test speed for array operation y(i)=a*x(i)*y(i) in 4 different ways
!
! "C:\Program Files (x86)\Intel\Composer XE 2013 SP1\mkl\bin\mklvars" intel64 mod
! "C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\compilervars.bat" intel64
! ifort testMKLvsOpenMP.f90 /QopenMP /Qmkl
!    Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.176 Build 20140130
!    Microsoft (R) Incremental Linker Version 9.00.21022.08
!     -out:testMKLvsOpenMP.exe
!     -subsystem:console
!     -defaultlib:libiomp5md.lib
!     -nodefaultlib:vcomp.lib
!     -nodefaultlib:vcompd.lib
!     "-libpath:C:\Program Files (x86)\Intel\Composer XE 2013 SP1\mkl\lib\intel64"
!     testMKLvsOpenMP.obj
!
program TestMKLvsOpenMP
use omp_lib
IMPLICIT NONE
integer :: N
real*8,Allocatable :: x(:),y(:)
real*8 :: alpha
real*8 :: endtime,starttime,DSECND
real :: cpu1,cpu2
integer :: NTHREADS,irepeat,nrepeat,i
! initialize
alpha=.0001
print *,'N=?'
read *,N
nrepeat=1000000000/N          ! nrepeat*N=10 Mio
print *,'nrepeat=',nrepeat

Allocate (x(N),y(N))
x(:)=0.  ; y(:)=0.
pause 'Press Return'

! 1. standard do loops
forall (i=1:N) ; x(i)=i ; y(i)=-i ;end forall
Nthreads=0
starttime = OMP_get_wtime()
Call cpu_time(cpu1)
do irepeat=1,nrepeat
 do i=1,N
   y(i)=alpha*x(i)+y(i)
 enddo
enddo
endtime = OMP_get_wtime() ; Call cpu_time(cpu2)
print *, 'Threads=',NTHREADS,' DO time=',SNGL(endtime - starttime),cpu2-cpu1
pause 'Press Return'

! 2. vector
forall (i=1:N) ; x(i)=i ; y(i)=-i ; end forall
Nthreads=0
Call cpu_time(cpu1)
do irepeat=1,nrepeat
   y(1:N)=alpha*x(1:N)+y(1:N)
enddo
Call cpu_time(cpu2)
print *, 'Threads=',NTHREADS,' Vector time=',cpu2-cpu1
pause 'Press Return'

Nthreads=2

! 3. OMP
forall (i=1:N) ;x(i)=i ; y(i)=-i ; end forall

CALL OMP_SET_NUM_THREADS(NTHREADS)
starttime = OMP_get_wtime() ; Call cpu_time(cpu1)

!$OMP PARALLEL Shared(N,x,y,alpha)
do irepeat=1,nrepeat
!$OMP DO  PRIVATE(i) SCHEDULE(static)
 do i=1,N
   y(i)=alpha*x(i)+y(i)
 enddo
!$OMP END DO nowait
enddo
!$OMP END PARALLEL

endtime = OMP_get_wtime() ; Call cpu_time(cpu2)
print *, 'OMP Threads=',NTHREADS,' OMPtime=',SNGL(endtime - starttime),(cpu2-cpu1)/Nthreads
pause 'Press Return'

! 4. MKL
forall (i=1:N) ; x(i)=i ; y(i)=-i ; end forall
starttime =DSECND() ; Call cpu_time(cpu1)
CALL MKL_SET_NUM_THREADS(NTHREADS)
do irepeat=1,nrepeat
  CALL daxpy(N,alpha,x,1, y ,1)
end do
endtime = DSECND(); Call cpu_time(cpu2)
print *, 'MKL Threads=',NTHREADS,' time=',SNGL(endtime - starttime),(cpu2-cpu1)/Nthreads

end

The results for N=1000000 (1 mio) and N=10000 are

 N=?
1000000
 nrepeat=        1000
Press Return
 Threads=           0  DO time=  0.1767103      0.1716011
Press Return
 Threads=           0  Vector time=  0.1716011
Press Return
 OMP Threads=           2  OMPtime=   1.397965       1.388409
Press Return
 MKL Threads=           2  time=   1.406852       1.404009

 N=?
10000
 nrepeat=      100000
Press Return
 Threads=           0  DO time=  0.1744737      0.1560010
Press Return
 Threads=           0  Vector time=  0.1716011
Press Return
 OMP Threads=           2  OMPtime=  0.2589355      0.2574016
Press Return
 MKL Threads=           2  time=  0.3295782      0.3120020

When I go down to N=100 OMP and MKL run slower

 OMP Threads=           2  OMPtime=  0.8096205      0.8112052
 MKL Threads=           2  time=  0.4926147      0.2418015

I am /QxAVX would speed up the vector time by 80% (and the do loops), however, as I am distributing my codes to a variety of users, I want to use the most common flags. All comments are welcome.

Hello, I am struggling a bit with Fortran callbacks that are passed to a C routine. In the course of various experiments with that I came across this problem:

C code:

/* printc.c --
       Print a value via a callback
*/
#include <stdio.h>
void print_via_cb( float x, void (*p)(float x) ) {

    fprintf(stderr,"Callback: %p\n", p );
    fprintf(stderr,"Callback: %f\n", x );
    (*p)(x);
}

Fortran code:

! testcall.f90 --
!     Test callbacks via ISO_C_BINDING
!
module mycallback
    implicit none
contains
subroutine printvalue( x )
    real, value :: x

    write(*,*) x
end subroutine printvalue
end module mycallback

program testcallback
    use mycallback
    use iso_c_binding
    implicit none

    real :: x

    interface
        subroutine print_via_cb( x, sub ) bind(c, name = 'print_via_cb' )
            use iso_c_binding
            real, value :: x
            interface
                subroutine sub(x)
                   real, value :: x
                end subroutine sub
            end interface
        end subroutine print_via_cb
    end interface

    x = 1.2
    call print_via_cb( x, printvalue )
end program testcallback

The output of this program was:

Callback: 000000013FEE1060
Callback: 1.200000

5.4472619E-39

rather than 1.20000.

If I add BIND(C) to the interface to the argument SUB, I get an error message, stating that the actual routine doesn't have that attribute and should have, but there is no warning or error if I leave it out (with the above result).

I am using Intel Fortran 15.0.1 at this moment.

Hi,

I'm working with a mixed C/Fortran project which uses waf as its cross-platform build system. While trying to resolve issues with ifort on Windows, the waf developers asked if there was a way to get ifort to list the preprocessor symbols or macros it defines because they need that info to support compilation with ifort.

As an example, if one runs

    gfortran.exe -dM -E - < a.f90

where a.f90 is an empty file, gfortran helpfully dumps out a long list of #defines (see attached).

Is this a thing ifort can do? I've looked into

    ifort /E /fpp a.f90 /dryrun

but I don't think that's doing quite the same thing.

There's more info on this issue at https://github.com/waf-project/waf/issues/1672 which revolves around the inability to get version information, etc. from ifort.

Thanks much,

I am having a problem with a Quickwin project that worked fine with CVF 6.6. (I am running the executable in Win 7 / 64.) This project uses two child windows: one for text I/O and one for graphics. The problem is that when the text finally reaches the bottom of the text I/O window, most of the last line is cut off and cannot be seen. This can be fixed by slightly dragging the lower right edge of the window inward to make a vertical scrollbar appear. If I drag the scrollbar to the bottom, the text is no longer cut off and new text continues to be visible, but if I pull the right size of the window to the right with the mouse, the vertical scrollbar disappears and the text is cut off again.

In CVF, no scrollbars appeared in the text window and this problem did not occur. In IVF, a horizontal scrollbar appears when the window is first opened. I can find no documentation on how (or if it is even possible) to control the appearance of scrollbars in a Quickwin child window.

I can't help but think that this is a bug in the IVF Quickwin runtime.

Here is the code the opens the text window:

	SUBROUTINE TweakConsole (nrows, ncolumns)
!  text window handling code starts here (from DVF support email 7/14/98)

      USE IFQWIN

      IMPLICIT NONE
      TYPE (windowconfig) wc
      TYPE(qwinfo) wci
      TYPE(rccoord) rc

      integer*4 irow, rowmoves, pagesize, i2res, nrows, ncolumns
      logical statuss
      character*1 ch
	real RES, TMP ! added these; original email had these as implicitly typed


      ! Use unit 6 for input and output
      ! It will always scroll down but lines will
      ! be lost at the top.
      open(unit=6,file="CON", CARRIAGECONTROL='FORTRAN')
      !set the scrollable screen fairly small
      wc%numtextrows = nrows ! number of scrollable rows+2
      wc%numtextcols = ncolumns ! number of scrollable cols
      wc%numxpixels  = -1
      wc%numypixels  = -1
      wc%numcolors   = -1
      wc%mode = QWIN$SCROLLDOWN
      wc%title       = "Terminal Window"C
      wc%fontsize    = #00080010
      ! try to set with user values
      statuss = setwindowconfig(wc)
      ! if that fails, try again with system computed values
      if(.not. statuss) tmp = setwindowconfig(wc)
	i2res = displaycursor($GCURSORON) ! turn cursor on

      ! Set the size of window to be actually seen
      ! be the same or slightly bigger
      WCI.TYPE = QWIN$SET
      WCI.X  = 0 ! was 10
      WCI.Y  = 0 ! was 2
      WCI.H  = wc%numtextrows+3 ! lines hi
      WCI.W  = wc%numtextcols+2 ! chars across
      RES = SETBKCOLOR(15)
      RES = SETTEXTCOLOR(0)
      CALL CLEARSCREEN($GCLEARSCREEN)
      STATUSS = SETWSIZEQQ(6,WCI)

	END SUBROUTINE TweakConsole

I have just recently installed Visual Studio 2015 and Intel Fortran.

During the build process I get the error,   "error 1104, cannot open ucrt.lib"

I am linking with the nodefaultlib option set to "No" ( setting it to "Yes" results in the same error message).

I have confirmed that the file ucrtbase.dll exists in C:\Program Files(x86)\Windows Kits\10.

I have confirmed that the file ucrtbased.dll exists in C:\Windows\System32.

Can you help with this problem?

Big picture: I am trying to embed a Lua interpreter in Fortran code via the F2003 ISO C bindings (see https://bitbucket.org/haraldkl/aotus ).

I can get it to work with ifort and Windows, just not both at the same time ('it works' means 'a C library is built and example Fortran code using the Lua bridge builds and produces the expected results'). gfortran/gcc works on both Windows and Linux, ifort/gcc works on Linux, but neither ifort/msvc or ifort/gcc works on Windows. The C code is ANSI C and the Fortran is plain F2003; there's no screwy preprocessor stuff, platform-specific nonsense, or operating environment weirdness like Cygwin. This isn't exactly a trivial problem but as I said, I've successfully built this code with gfortran/gcc on both Windows & Linux and with ifort/gcc on Linux so the problem is not with the code or the operating systems. I expect it should build with ifort on Windows but I cannot figure out the magic words to make that happen.

The C portion of the project compiles without incident and is packed into a few static libraries (libaotus.a, libflu.a, liblualib.a) with ar which comes from the TDM distribution of gfortran and gcc for Windows. I'm not worried about this part since this code works fine if I build the code with gfortran.

The automated build tool used by the project (waf) fails with ifort on Windows so I'm trying to manually convert the compilation steps which use gfortran to ifort. I have a reasonable amount of success until I try linking with the C libraries which is where everything falls apart.

Here's an example of where conversion is failing - first the (successful) compilation step:

@REM [46/84] Compiling LuaFortran\examples\test.f90
@REM gfortran.exe -O3 -march=native -Wall -Wconversion -Wimplicit-interface -Wunderflow -W -frange-check -c -o .\LuaFortran\examples\test.f90.8.o ..\LuaFortran\examples\test.f90
ifort.exe /O3 /warn=all /fpe:0 /warn=interfaces /gen-interfaces -c -o .\LuaFortran\examples\test.f90.8.o ..\LuaFortran\examples\test.f90

Then a few lines later, the unsuccessful link step:

@REM [49/84] Linking build\flu_sample.exe
@REM gfortran.exe -Wl,--enable-auto-import -Wl,--enable-auto-import -O3 -march=native -Wall -Wconversion -Wimplicit-interface -Wunderflow -W -frange-check LuaFortran\examples\test.f90.8.o -o .\flu_sample.exe -L. -lflu
@REM -Wl,--enable-auto-import -Wl,--enable-auto-import ; superfluous linker directives; only suppresses warnings which may not exist with ifort
ifort.exe /O3 /warn=all /fpe:0 LuaFortran\examples\test.f90.8.o -o .\flu_sample.exe /LIBPATH:. -lflu

I'm almost certain the problem is in the unixy '-lflu' argument to ifort which (I believe) is passed directly through ifort to LINK.EXE, which, as far as I can tell, is not meant for humans to understand or manipulate directly. I believe if I can get the linking sorted out, the rest of the project will fall into place.

What's the right way to resolve this?

Is there a way to tell ifort to ignore Microsoft's infrastructure and just use C:\TDM-GCC-64\bin\ld.exe which (apparently) works?

Note that I typically work with either pure Fortran or interpreted languages. If I'm faced with a linking problem, it usually indicates I'm using the wrong language or platform. I've been fighting with this for a week or two now trying to get it to build with ifort on Windows, and passing whatever knowledge I gather back to the upstream project (I'm not directly involved in the Lua/Fortran bridge development). I've helped improve the automated build system's detection of ifort, but so far it's been a miserable slog on Windows. Any help you could provide would be greatly appreciated.

The following specification is accepted by the compiler:

      CHARACTER*1 FALSE/Z'00'/, TRUE/Z'01'/

but is not accepted in the next case:

CHARACTER(LEN=1), PARAMETER :: FALSE=Z'00', TRUE=Z'01'

 v9synchk.for(102): error #6957: This is an illegal data type value for this parameter.   [Z'00']
      CHARACTER(LEN=1), PARAMETER :: FALSE=Z'00', TRUE=Z'01'

Hello,

I'm finishing my PhD in Geotechincal Engineering, in the Polytechnic University of Catalonia.

I've implemented Fortran Code within Plaxis environtment (User Soil Defined Model). To create the necessaries dynamic libraries .dll, I've been using Intel Fortran Compiler (32/64) and LF95.

Intel Fortran (32/64) compiles the principal part of the code, and Lahey compiles an additional part of the code that let me use Plaxis Interface introducing input parameters. 

I've using next make orders (which I've adapted from the original ones) for compiling the code and create the .dll:

IFORT32 (ifcomp.bat)
echo !DEC$ ATTRIBUTES DLLExport, StdCall, reference :: User_Mod
ifort @comp_rel  UsrMod.f90 UsrAddDF.f90 usrlib.f90 okmsgivf.f90 /dll /exe:example_ivf

IFORT64 (ifcomp64.bat)
REM compile 64-bit DLL: make sure you're in a 64-bit development environment
copy impivf impexp
ifort /static  UsrMod.f90 usrlib.f90 okmsgivf.f90 /dll /exe:example_ivf64
 

LF95 (lfcomp.bat)
echo       DLL_Export User_Mod
lf95 -c usrlib.f90
lib /out:lfusrlib.lib usrlib.ob
lf95 -c -ml winapi okmsglah.f90
lf95 -win -dll  UsrMod.f90 Usr_Add.f90 okmsglah.obj -lib lfusrlib.lib -ml bd -out:example_lah.dll

I've been able to compile the code of the constitutive code that I've developed in PLAXIS, introduce the model parameters, calculate and analyze the results. But now, LF95 trial license has expired (>30 days), and Lahey doesn't offer me any Student Version at a reasonable price.

That's why I'd like to ask you how to change LF95 make orders to Intel Fortran. I've tried all it was in my hand, but I'm not an expert developer (can manage well numerical models, but get lost with compiler orders -except basic ones-).

Thank you very much.
Best regards,

Hi,

I've got two codes, which I want to combine. In one code I've got type:

  TYPE, PUBLIC ::m_type
    INTEGER :: m,
    REAL ( KIND( 1.0D+0 ) ), ALLOCATABLE, DIMENSION(:) :: val
  END TYPE

and subroutine which uses this type as an input:

   subroutine sub(m)
      type(m_type), intent(in) :: matrix
      ....
   end subroutine

In the second code, which calls the subroutine sub(), I have already allocated array, let say x(:), and I don't want to allocate once more memory for m%val, just for copying data, because size of x(:) is huge. Is there any way to assign m%val with values of x(:) without allocating additional memory? In C pointer will do the trick, but I don't know how I could use it here. I dont want to change subroutine sub(), because it will cause changes not only in my part of the code.

Any ideas?

The following code fails (Update 1, 2016.0.1.51; both 32 bits and 64 bits.)

  MODULE ti_mod
  USE ISO_C_BINDING
  IMPLICIT none
  PRIVATE
!
  INTEGER,PUBLIC,PARAMETER :: GLintptr = C_INTPTR_T
!
  PUBLIC :: glBsd
  POINTER :: glBsd
  INTERFACE
    SUBROUTINE glBsd(tg) BIND(C)
!
!  The following two lines let the compilation fail:
!
    IMPORT :: GLintptr
    INTEGER(KIND=GLintptr),VALUE :: tg
!
!  If the preceeding lines are replace by the following ones, everything wents fine.
!
!  USE ISO_C_BINDING
!  INTEGER(KIND=C_INTPTR_T),VALUE :: tg
!
    END SUBROUTINE glBsd
  END INTERFACE
!
  END MODULE ti_mod

Our gfortran friends do not complain! A compiler bug, I guess?

Greetings,

apologies for the title of the topic, which may seem a bit cryptic, but I doubt I can find a better one - nor a worse either ;-)

Let me explain the unusual situation I am facing. My PC runs under Windows 10 with Japanese keyboard (plus two other layouts, because I often switch among four languages). I have Intel Fortran Composer 2016 integrated in MS Visual Studio 2015 community (English). The results of the compilation are shown in the "Output" tab of VS. The problem is that the output messages are shown in Japanese but with incorrect encoding, so that the whole output is unreadable. I need either to get an English output or a correctly encoded Japanese output. The issue certainly comes from the Fortran compiler, because VS simply shows what the compiler has to say.

If there is no solution on the compiler side, I may try to install the Japanese language pack for VS but I am not sure that would solve the problem.

Thanks in advance for any suggestion you may provide.