FORTRAN 17.0.-1695 can generate a 6415 naming error in the presence of IMPLICIT NONE, depending on the order of the dummy arguments and type declarations. The attachment provides an example. RISK has HMAX, an intended INTEGER, as one of its indexes. If the declaration of HMAX appears in the interface block before RISK, even if it is after RISK in the argument list, no error is generated. However, if HMAX follows RISK in the interface block, the 6415 duplicate declaration error is generated, even in the presence of IMPLICIT NONE. My personal hypothesis is that HMAX is being implicitly d
I have recently downloaded and installed the "Intel(R) Parallel Studio XE 2018 Update 1" which seems to lack "stdio.h"?
For example, if i try to initiate the env with "psxevars.bat intel64", it shows no error:
Intel(R) Parallel Studio XE 2018 Update 1
Copyright (C) 2017 Intel Corporation. All rights reserved.
Intel(R) Compiler 18.0 Update 1 (package 156)
I have used the WinPrint created by Steve Lionel a lot in the CVF days and I am also applying this add on with IVF for a Windows application. This of course with the revised IVF version. In the case of a IVF QW application I get a warning during compilation:
C:\CALC\CaFeMS\LIB-filer\WinPrint_Direct_A.f90(241): warning #7799: %LOC is being stripped from argument which has REFERENCE and IGNORE_LOC attributes. [HPRINTER]
Line 249 is as follows:
Last_Error = OpenPrinter(UserPrinterName, %LOC(hPrinter), PrtrDef)
Well, the program can be run, but when I print a file, the program fails with the message:
'_WINPRINT_DIRECT_mp_PRINT_DIRECT$PRINT_DIRECT is being used without being defined..
Hope somebody, if not Steve, can give me a clue..
I have a program that uses the following OpenMP directives together: taskloop and collapse. The program works fine when I compile with GCC 7.2, but it simply crashes when I compile with Intel compiler v 17.0.1. I investigated my code and I created a simple program that reproduces the cause of the crash. The code is below
int main ()
double * a=(double *) malloc(100*sizeof(double));
printf("1. a %x\n",a);
#pragma omp taskloop collapse(3) shared(a)
I have run into a rather peculiar problem with nmake and ifort. I have a makefile to build a library and two programs. When I run nmake, all goed well except when building the programs. However, when I use exactly the same command via the command prompt, these steps succeed. Here is the output to the screen:
I'm using Intel Fortran 188.8.131.52 on a system with KNL cpus on the compute nodes. Here is my test code,
module align_test_module implicit none contains subroutine do_something(nVertLevels) integer, pointer :: nVertLevels integer :: i real, dimension(:), allocatable :: uTemp allocate(uTemp(nVertLevels)) !$omp simd aligned(uTemp:64) do i = 1, nVertLevels uTemp(i) = 0.0 end do end subroutine do_something end module align_test_module
And here is my compile line,
I've encountered a strange problem of module dependency. It seems that the compiler integrated in microsoft visual studio can not correctly parse the module dependency under specific conditions. I tries to isolate the problem and simplifies it as the below sample:
The Visual Studio solution contains two projects.
One is named "foo" for a Fortran static library, which contains three modules in seperated source files: a, b, and c. Module b uses module c, which uses module a. Below are the simplified source files:
I noticed a remark in the documentation (Intel Fortran compiler v17.0) that puzzled me:
Is the size of the file storage unit expressed in bits. To use this constant, compiler option assume byterecl must be enabled.
I tried this in a small test program and found that the file storage size is the same whether I use -assume:byterecl or -assume:nobyterecl. If this remark is correct, how does it affect the results?
For your convenience, I have copied this test program below:
I've seen some messages posted to the forum about calling Fortran subroutines in the NetCDF library but have not noticed a resolution for 64-bit projects.
I have a mixed code (C++, Fortran) VS project and would like to call subroutines in the NetCDF Fortran library. It looks like Unidata does not support Fortran NetCDF compiled with the Intel Fortran compiler. Has anyone had any luck creating a static or dynamic version of the NetCDF Fortran library compatible with a 64-bit VS project? Alternatively, how about a C version?
Experiencing some peculiar activity using excel to call a FORTRAN DLL. By the way, have used successfully for years in earlier excel versions and FORTRAN DLLs compiled with CVF.
Finally having gotten the excel to work with the Intel FORTRAN, we are seeing a scenario where a called .DAT file works fine when call through a spreadsheet.
However, in the scenario where the same .DAT file is called after a previous case has run its course, it does not work.
It is clear that the correct input file is being called as a .tmp file shows that this has been updated.