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

LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

March 21, 2019, 6:05 am
$
0
0

Hello,

a top which was already discussed a few times but the current threads could not help me. I am trying to create a x64 configuration but I am getting the mentioned error. What I did so far and specifics:

  • VS 2015
  • Intel Fortran 18.0.5

 

  • Build a Minimal test system x64 -> it is build and running flawlessly (x64 Compiler correctly installed)
  • Checked in the configuration that all projects have the x64 configuration for the x64 *.sln
  • Checked that there is no /MACHINE:I86 or similar in the "addional options" area in the linker section
  • Checked that in the linker settings "Target Machine" is set to "Not set"
  • C++ lib: Librarian; TargetMaschine /MACHINE:X64
  • The *.exe which should be builded: "Additonal dependencies""kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib"

What keeps me wondering that the File which is causing the error is looking for a object file MyC++Lib(hlmscffs.obj) which I do not know and which is also not in any of my x64/Debug folders.

Any has an Idea?

↧
Search

Leaked mutant (mutex) handles during formatted write

March 21, 2019, 10:21 am
$
0
0

I'm using the ifort compiler, version 16.0 Build 20150815. In my long-running program (2-3 days) I'm doing quite some formatted writes along the lines of:

CHARACTER(1024) :: c_string
WRITE (c_string, '(2X,A8,I2,F9.1)') parent%sub%c_a_string, parent%sub%i_an_integer, d_a_double

and use the result for output e.g. to the screen.

Every time I'm doing this, a mutant (mutex) handle is leaked.
I used WinDbg's !htrace -diff function to get traces of the incidents. What I get are loads of traces similar to this one:

0x00000000777ca25a: ntdll!NtCreateMutant+0x000000000000000a
0x000007fefd54a1b7: KERNELBASE!CreateMutexExW+0x0000000000000057
0x000007fefd551d60: KERNELBASE!CreateMutexExA+0x0000000000000050
0x000007fedfab24db: libifcoremd!for_lge_ssll+0x0000000000001dcb
0x000007fedfb03ed6: libifcoremd!for_write_int_fmt+0x0000000000000056
0x000000014085aa21: myprog!MY_ROUTINE+0x0000000000000121

During the runtime, these leaked mutant handles pile up until they reach the number 16711680. When the program is finally at the point of writing stuff to a file, the attempt to get a file handle fails with the error:
0x000005aa ERROR_NO_SYSTEM_RESOURCES : Insufficient system resources exist to complete the requested service.
(The file is created but the file handle, I get from fopen is NULL)

It seems that the handle leaking is happening inside some Intel libraries. Is this a known problem? Is it maybe fixed in a version later than 16.0? Is there anything I can do to circumvent the handle leaking?

I found something which seems somewhat related, only it's describing memory leaks during using the WRITE function: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo...

↧
↧

Unresolved external symbol omp_get_* on VS2017.

March 21, 2019, 7:10 am
$
0
0

Hello,

I am trying to build a project on VS2017 with OpenMP libraries. A minimal example of code is the following:

program checkOMP
    use omp_lib
    implicit none
    
    integer                 :: num_threads
    !integer, external  ::  omp_get_num_procs
    
    num_threads = omp_get_num_procs()
    if (num_threads > 2) then
       call omp_set_num_threads(num_threads-1)
    end if
    
    write(*,*) 'Hello World'
    
    read(*,*)
end program checkOMP

I am compiling it without issues using /Qopenmp. However, the linker throws errors about unresolved external symbols for the two omp_* procedures (LNK2019). The weird thing is that the exact same project, with the same properties, builds just fine with VS2015 on the same machine.

I tried explicitly adding the location of intel libraries to Project Properties -> Linker -> Additional Library Directories but without luck.

Do you think I am missing anything?

Thanks. 

↧

Intel Parallel Studio 2019 Fortran Library not Detect by MS Visual Stuido 2017

March 21, 2019, 11:13 am
$
0
0

I started with installing MS Visual Studio 2017 without any workloads then I installed Intel Parallels Studio.

I then tried creating a Fortran project in MS VS, but it doesn't see the library or give me an option to do so.

I then modified the VS installation and added the C++ workload per https://software.intel.com/en-us/articles/installing-microsoft-visual-st...

Still was not able to get it working.

Then I followed https://software.intel.com/en-us/articles/troubleshooting-fortran-integr...

I found out that the integration files were not present.

Repaired the installation of Intel Parallel Studio to no avail.

Any help would be greatly appreciated.

Thank you.

↧

Multi-Dimensional Allocatable Array

March 21, 2019, 12:16 pm
$
0
0

Dear group

I have a Fortran-question on Multi-Dimensional Allocatable Arrays

I'd like to declare an array of dynamic length, where each entry is itself an array of length 2. It should look like

      REAL, Allocatable:: XY(2,:)

Unfortunately: If I do so, I get an error

     error #6644: The dimension specifications are incompatible.   [XY]

I could solve this by declaring both dimensions dynamic:

      REAL, Allocatable:: XY(:,:)

But if I do so, I expect the compiler to generate less efficient code, since the compiler does know less about the structure of my array at compile time.

In particular: The expression "XY(1,i)" should generate code like "Multiply i with 2*sizeof(REAL)" which is an efficient power-of-2-multiplication.

Any advice?

Thank you

Benedikt

↧
↧

Link Errors with Multithreaded Runtime 64bit

March 22, 2019, 1:23 am
$
0
0

Hello,

I'm using Visual Studio 2017 with the Intel Fortran Compiler. I have a bigger project using several Intel libraries like mkl and I need to switch from 32bit to 64bit.
When compiling in debug mode (using Runtime Library: "Debug Multithreaded (/libs:static /threads /dbglibs))" everything works fine but when compiling for release (Runtime Library: "Multithreaded") I get thousands of LNK2001 and LNK2019 errors. Compiling and linking for x86 however is possible with both runtimes.
The libs that are not found are mostly mkl libs (e.g. mkl_core.lib) but also non mkl libs like libifcoremt.lib and libifport.lib.

I'm guessing it has something to do with wrong path variables but I reinstalled the Intel Compiler and it should have repaired it, shouldn't it?
Does anyone have an idea how to solve this problem?

My Compiler Versions are 19.0.3.203 and 18.0.5.274, the problem occurs with both of them.

Your help would be greatly appreciated.

Thanks in advance

Andreas

↧

Odd behaviour "Rebuild" - one object file missing at first run

March 25, 2019, 5:13 am
$
0
0

Hello,

we are experiencing a very odd behaviour with Visual Studio (2015) and Intel Fortran (2017): we use the netCDF library in our programs and it turns out that the first (!) time we do a rebuild of one of the programs in the solution an object file from the Fortran interface library for netCDF is missing - typeSizes.obj, whereas the corresponding .mod is there. According to the build log, it was correctly compiled. Of course it means that at the end things cannot be properly built.

But if we rebuild it again, the object file is actually present and the whole build succeeds.

While I state here that it has to do with the netCDF library and its Fortran interface, I cannot be sure - it is just that it happens with a source file from that library. I cannot remember ever seeing it with any other program or programs though.

The phenomenon is repeatable: every time I start Visual Studio and rebuild one of the programs in the solution, the first rebuild fails and all subsequent ones do the job properly. It is also very odd that only that one object file (but not the .mod file) is missing.

Does anybody have a suggestion as to how to solve this? It is an annoyance, not impossible to get around, but still, an annoyance.

 

 

↧

How to measure Visual Fortran Code metrics ?

March 26, 2019, 5:02 am
$
0
0

How to measure code metrics (Maintainability Index, Cyclomatic Complexity, etc.) of an Intel visual Fortran project ?

We are using Parallel Studio 18 with Visual Studio 2017. The measurement seems possible with other languages.

Thank you !

↧
Search

Since the new upgrade KB4023057 Intel Fortran parallel is not working

March 25, 2019, 10:17 pm
$
0
0

Hello everyone!

I'm student and I'm using VS with the libraries from intel parallel studio. I'm actually working with Intel Fortran. I have a code that was working so good, using all the processor and that help me to saving time. Yesterday mi windows had an upgrade (KB4023057), and now my code is not working as well it was, right now is using 30% of the processor. All the configuration is the same, the only change was the upgrade.

Some ideas ? What can I do ?

↧
↧

student license needed

March 26, 2019, 2:17 pm
$
0
0

Where do I go to get my student license ? I cant find the link.

I am a student at a local college here.

 

↧

student license needed

March 26, 2019, 2:17 pm
$
0
0

Where do I go to get my student license ? I cant find the link.

I am a student at a local college here.

 

The license I had has expired.

 

someone transferred me over to some useless site where noboby was any help whatsoever.

 

Can I get my answer here ?

 

 

↧

BUG will not allow me to upgrade my license

March 26, 2019, 6:07 pm
$
0
0

I made a mistake putting in my student ID.

But then I cannot go back and put in the CORRECT one.

It does not give me a way to do that.

They say "resubmit" but that does nothing at all.

Who is knowlegeable about this stuff ?

↧

Intel MPI 2019.3.203 not working with Fortran in Visual Studio 2015 if Fortran version is set to "latest"

March 28, 2019, 4:52 am
$
0
0

If I try to compile a Fortran file with "use mpi" and in the options of Visual Studio 2015 (14.0.25123.00 Update 2) the Intel compiler version is set to latest (with Intel Fortran 2019.2 installed), I get the following output:

1>------ Neues Erstellen gestartet: Projekt: nut, Konfiguration: Release x64 ------
1>Deleting intermediate files and output files for project 'nut', configuration 'Release|x64'.
1>Compiling with Intel(R) Visual Fortran Compiler 19.0.3.203 [Intel(R) 64]...
1>nut.f90
1>..\..\nut\include/nut/communicators.fmod(29): error #7012: The module file cannot be read.  Its format requires a more recent F90 compiler.   [MPI]
1>..\..\nut\include/nut/communicators.fmod(60): error #6404: This name does not have a type, and must have an explicit type.   [MPI_COMM_WORLD]

...

If I set the compiler version explicitly to 2019.0.3.203, it is working.

Does anybody else see this problem? What could cause it?

 

 

↧
↧

LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

March 21, 2019, 6:05 am
$
0
0

Hello,

a top which was already discussed a few times but the current threads could not help me. I am trying to create a x64 configuration but I am getting the mentioned error. What I did so far and specifics:

  • VS 2015
  • Intel Fortran 18.0.5

 

  • Build a Minimal test system x64 -> it is build and running flawlessly (x64 Compiler correctly installed)
  • Checked in the configuration that all projects have the x64 configuration for the x64 *.sln
  • Checked that there is no /MACHINE:I86 or similar in the "addional options" area in the linker section
  • Checked that in the linker settings "Target Machine" is set to "Not set"
  • C++ lib: Librarian; TargetMaschine /MACHINE:X64
  • The *.exe which should be builded: "Additonal dependencies""kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib"

What keeps me wondering that the File which is causing the error is looking for a object file MyC++Lib(hlmscffs.obj) which I do not know and which is also not in any of my x64/Debug folders.

Any has an Idea?

↧

Has anybody else had problems installing XE2019U3?

March 21, 2019, 2:40 am
$
0
0

I can't install Parallel Studio XE2019U3 on my PC.  I wonder whether anybody else has the same issue?

Installation exits at the "Preparing environment..." stage; I'm trying to install Fortran, MKL, and VS2017 integration only.

OS: Windows 10 1809 Enterprise x64. VS2017 updates and XE2019U2 seem to install OK.

I have reported this to Intel Support (#04110009).

 

↧
Search

How to improve user functionality

March 28, 2019, 1:54 pm
$
0
0

I made this suggestion earlier, but no one responded.

I don't know if anyone took a hard look at this idea.

 

as you know, there is currently a problem with the debugger running while one is still

trying to rebuild their program to make changes.

The message I get is "cannot access manifest file."

That is because the debugger is still attached to their executable,

and it keeps on running long after they are done with debugging.

My idea is: simply put a random letter or number at the END of the executable name.

 

That way you can make a NEW executable while the debugger is finished (doing whatever its trying to do)..

So then there is no longer any conflict. The actual NAME of the executable does not seem to be that important.

 

If something is wrong with that suggestion, I would sure love to hear about it.

The obvious fix, is to make sure the debugger does not run when you are done with it, but

so far, no one seems to want to address that issue.

↧

Redistributable libraries packaging in Microsoft SCCM

March 29, 2019, 9:51 am
$
0
0

We have a need to roll out Fortran Redistrubutables to a large audience in our organization, we are planning on using Microsoft SCCM to achieve it --  When a updated version of redistributable is released by Intel, does the silent install overwrite the older redistributable (if any was installed?) if the new msi is run using /qn switch? or does it create another (side-by-side) install on the PC?

 

↧
↧

how to get a console program's folder location at run time

March 29, 2019, 10:28 am
$
0
0

This question is specific to the Windows OS.  Is the code below the recommended way for a console program to get the folder in which it is located at run time?  Note I do not want the "current working folder" or "default path".  I want the location of the EXE file.  This code is from a very old post.

Subroutine get_exe_path(gpth,npth) !get exe path from cmd line 
    implicit none 
    integer, intent(out)          :: npth 
    character(len=*), intent(out) :: gpth 
    integer                       :: ilen, istat   
    character(len=512)            :: garg 
    gpth='' 
    npth=0 
    call get_command_argument (0, garg, ilen, istat) !an intrinsic function
    if(istat == 0) then 
        npth=index(garg,'\',.true.) !an intrinsic function, true means search backward
        gpth=garg(1:npth) 
    endif 
end subroutine

 

↧

Passing Vector Segments to Assumed-sized Array

April 1, 2019, 9:55 am
$
0
0

Hello,

I working some inhereted code that uses assumed-size arrays. I haven't worked with assumed-size assays before (I'm under the impression that assumed-shaped are preferrable and assumed-size only exist for backward compatibility) and the way they are used doesn't seem to fit neatly into the documentation I have found online about assumed-size arrays. What seems strange to me is that the main program has one long vector and single elements of this vector are passed into assumed-size array interface parameters of a subroutine. The ones of these that are of the format a(*)  get created as vectors of length 1 but the ones that are of the form a(10,*) get created as arrays of shape (10,1). At least that is my understanding of how it behaves from reverse enginerring the  code. So my question is, have I understod correctly and can I rely one the code to consitently behave this way? To make the question clear here is a code snippet

    program test
    real ::X(100), y(5)
    
    call sub(x(1),x(10),x(50),y)
    
    contains
    subroutine sub(a,b,c)
    real:: a(*), b(10,*), c(*), d(*)
    
    end subroutine sub
    end program test

So in this example I a and c are of shape (1), b is of shape (10,1) and d is of shape (5). I've seen documentation explaining why d would be (5) but not confirming b should always be (10,1).

Thanks in advance

↧

F1-access to Fortran documentation (redux)

April 3, 2019, 8:23 am
$
0
0

Is anyone else seeing this?

Highlighting a keyword in source code and hitting the F1 key no longer brings up the proper section of Fortran documentation. This appears to have happened either with the installation of PS XE 19.0.3  or two of the latest updates to Visual Studio 2017:  15.9.10 or 15.9.11

↧
Viewing all 5691 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>