Register for Webinar on Advanced Vectorization and Optimization

The webinar will cover some of the loop patterns which posed challenge for vectorization and how Intel Compiler vectorizes those loop patterns with the latest 16.0 compiler. Topics covered in the webinar include:

1. Compress/Expand Loop Pattern
2. Histogram loops
3. Search Loop Pattern
4. Vectorization of STL Vectors
5. Valarrays
6. OpenMP4.0 SIMD constructs support

Register for Webinar on Advanced Vectorization and Optimization

The webinar will cover some of the loop patterns which posed challenge for vectorization and how Intel Compiler vectorizes those loop patterns with the latest 16.0 compiler. Topics covered in the webinar include:

1. Compress/Expand Loop Pattern
2. Histogram loops
3. Search Loop Pattern
4. Vectorization of STL Vectors
5. Valarrays
6. OpenMP4.0 SIMD constructs support

Hello,

I just completed a fresh installation of ifort-icc compilers and installed the HDF5 package with the intel compilers. The installation seemed ok and the correct mod files have been produced. Then when I try to use the HDF5 I get the usual different compiler error:

/Users/manfredo/Desktop/ED2/ED/src/include

 /usr/local/hdf5_mio/include

 /usr/bin/ifort-14.0-base/compiler/include/intel64

 /usr/bin/ifort-14.0-base/compiler/include

 /usr/local/include

 /usr/include

End of search list.

hdf5_coms.F90(3): error #7013: This module file was not generated by any release of this compiler.   [HDF5]

   use hdf5

-------^

compilation aborted for hdf5_coms.F90 (code 1)

make[1]: *** [hdf5_coms.o] Error 1

make: *** [all] Error 2

MacBook-Air-di-Manfredo:bin manfredo$ icc -v

icc version 14.0.4 (gcc version 4.8.1 compatibility)

Before installing the HDF5 with intel compilers I had a version compiled with gfortran. However before reinstalling it with ifort I cleaned all the files and now the only hdf5.mod file I have is the one produced during the intel compilation. Working on Mac OSX.

Thanks for any suggestions. Manfredo

I am using PSE2016 in Windows 10

Is there a method to just compile a subroutine? At present, I have to include a begin program...end program statements for successful compilation as shown below.

program try

end program try

SUBROUTINE CREEP(....

I am interested to know if there are any alternatives in VS2015 to simply compile the subroutine without adding the program statements. At present I am selecting a Fortran console project as my option in VS 2015.

The reason, I just need just a subroutine compiled is because it will be linked with another finite element analysis program which will access the compiled subroutine. Per the instructions of the finite element analysis program I need to link the compiled subroutine - I am assuming it means that I need to get the .obj file.

Please pardon my ignorance, as I am new to all this. All your helps and tips will be appreciated.

Regards

Animesh

So I am trying to move my working codes from PGI Fortran to Intel, I am using student free version of compiler for Intel and Microsoft Visual Studio 2013 Community version.

My perfectly running code in PGI, gets following error (attached image) when it comes to compiling with Intel Compiler. That is except that some other errors that I could solve (difference how they interpret INTENT(IN) ).

So why I am getting this error and how can I solve it?

Should I expect something unusual going on somewhere and redo checking my results ? i.e. when I choose INTEN(IN) in a subroutine with PGI, I could change the value of the parameter, but this changed value did not effect the parameter "out side the routine" (where it was initially called). So I had it defined as a " Parameter" in the main body of program, passed it inside the routine, changed it value, but the changed value did not pass outside!  but it seems I cannot do such with Intel

Hi, Steve. 

I applied  the student free Intel Parallel Studio XE Composer Edition for Fortran OS X and got one serial number.

1:   I download  the 2016 version but it's  'm_fcompxe_2016.0.033.app' file within the dmg file and double-click couldn't work to install it. 

2:   Then I downloaded the 2015 version(update 5) from the additional links, and it's a mpkg file which can be installed. After offering my seal number, it told me 'The Serial Number provided is not valid for this solution set'. I only have one serial number.

What should i do to solve these two problems? Thanks!
 

Attempting to resurrect yet another old CVf Program (yes they're still around)... I am trying to re-create a dialogue panel application.

I have copied in the necessary lines into the script.rc file which compiles ok - after I manually incorporated the "include <windows.h>" line.  I can edit the dialogues ok in the Visual Studio 2010 dialogue editor.  Running Fortran SE 2011 (Package ID: w_fcompxe_2011.4.196)

When I clicked Save I got a warning message saying that the script.rc & Resource.h files were from an older version - and did I want to re-create them - clicked yes to this.   BUT when I come to build, once the resource.fd is created (using the deftold resource.h resource.fd) I get the following list of errors.  Any ideas what I can try next ?

Script and resource.h and resourc.fd files attached. (script.rc and resource.fd renamed with .txt extensions since the upload tool didn't like their actual extensions).

Errors:

Error 1  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDABORT] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 109 
Error 2  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDHELP] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 552 
Error 3  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDIGNORE] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 647 
Error 4  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDCLOSE] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1203 
Error 5  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDOK] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1244 
Error 6  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDNO] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1396 
Error 7  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDRETRY] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1584 
Error 8  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDYES] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1661 
Error 9  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDCANCEL] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1715 
Warning 10  warning #6371: A jump into a block from outside the block may have occurred.   [100] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\b_w_messaging.for 62 
Error 11  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDABORT] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 109 
Error 12  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDHELP] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 552 
Error 13  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDIGNORE] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 647 
Error 14  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDCLOSE] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1203 
Error 15  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDOK] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1244 
Error 16  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDNO] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1396 
Error 17  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDRETRY] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1584 
Error 18  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDYES] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1661 
Error 19  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDCANCEL] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1715 
Error 20  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDABORT] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 109 
Error 21  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDHELP] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 552 
Error 22  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDIGNORE] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 647 
Error 23  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDCLOSE] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1203 
Error 24  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDOK] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1244 
Error 25  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDNO] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1396 
Error 26  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDRETRY] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1584 
Error 27  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDYES] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1661 
Error 28  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDCANCEL] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 1715 
Error 29  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDABORT] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 109 
Error 30  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDHELP] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 552 
Error 31  error #6401: The attributes of this name conflict with those made accessible by a USE statement.   [IDIGNORE] C:\Users\jmoffat\Documents\_jmoffats_stuff\Microsoft Visual Studio\Intel Fort Projects\b_w_form\b_w_form\resource.fd 647 
 

Dear Intel Fortran Compiler for Linux and Mac OS X users and developers,

I think that I found a number of issues when overloading "generic :: operator(-)" on a base derived data type -- let's call it A -- and calling the corresponding bindings with instances of a derived data type which extends A, --let's call it B--. The different scenarios tested were gathered in five programs attached to this post: test1.f90, test2.f90, test3.f90, test4.f90, and test5.f90. The outcome was as follows:

- test1.f90 compiles and generates the output that I would expect (OK).

amartin@Aetos:~/pruebas_fortran_03$ ifort test1.f90
amartin@Aetos:~/pruebas_fortran_03$ ./a.out
   2.000000    
   2.000000

- test2.f90 compiles but it DOES NOT provide the output that I would expect (I believe the expected output should be the same as the one provided by test1.f90) (NO-OK).

amartin@Aetos:~/pruebas_fortran_03$ ifort test2.f90
amartin@Aetos:~/pruebas_fortran_03$ ./a.out
 
   2.000000

- test3.f90 compiles but and generates the output that I would expect (OK).

amartin@Aetos:~/pruebas_fortran_03$ ifort test3.f90
amartin@Aetos:~/pruebas_fortran_03$ ./a.out
   1.000000

- test4.f90 DOES NOT compile, and I believe that it should compile (NO-OK).

amartin@Aetos:~/pruebas_fortran_03$ ifort test4.f90
test4.f90(46): error #6355: This binary operation is invalid for this data type.   [B_INSTANCE]
  write(*,*) B_instance-B_instance
-------------^
test4.f90(46): error #6355: This binary operation is invalid for this data type.   [B_INSTANCE]
  write(*,*) B_instance-B_instance
------------------------^
test4.f90(46): error #6549: An arithmetic or LOGICAL type is required in this context.
  write(*,*) B_instance-B_instance
-----------------------^
compilation aborted for test4.f90 (code 1)

- test5.f90 compiles and generates the output that I would expect (OK).

amartin@Aetos:~/pruebas_fortran_03$ ifort test5.f90
amartin@Aetos:~/pruebas_fortran_03$ ./a.out
   1.000000    
   1.000000

If you take a careful look at the code snippets, you may observe that the NO-OK tests are the ones where the "generic :: operator(-)" is overloaded for both the unary and binary minus operator.

Could you please help me and determine whether the codes are standard compliant, and confirm that they should provide the outputs that I except? In case I am correct, is there any compiler-related issue? Can it be work-arounded? Should it be fixed?

I got the same behaviour with both the 15.0.2 and 16.0.0 compiler versions.With the GNU gfortran compiler (5.1.0) all tests compiled and generated the output that I would expect.

Many thanks in advance for your help.

I tried to replicate in a small example but failed. It appears on entry to any routine with a local fixed size array of double precision type.

Here is assembler leading up to error from my 64 bit debug compile with XE 16.0:

000007FEECC174F8  jl          000007FEECC17488  
000007FEECC174FA  jmp         000007FEECC17468  
000007FEECC174FF  mov         rax,qword ptr [rsp+50h]  
000007FEECC17504  inc         r9d  
000007FEECC17507  mov         qword ptr [rdi+r8*8],rax  

error occures on last line and shows rdi = 0, r8 = 0, rax = a large number

Compiler flags:

/nologo /debug:full /MP /Od /QxHost /I"Removed for confidentiality" /DIntelQuad /Dx64 /DenhancedChecking /DoutputModel /Qopenmp /standard-semantics /debug-parameters:all /warn:declarations /warn:unused /Qinit:snan /Qinit:arrays /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc140.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /libs:dll /threads /dbglibs /Qmkl:parallel /c

Dear Intel Fortran Compiler for Linux and Mac OS X users and developers,

I have discovered an Intel 16.0.0 compiler error (with 15.0.2 is also there) when compiling my Fortran03 software which I believe to be standard conforming. Although this is a quite complex software with many data types, and a complex relationship among them (aggregation, 3-level inheritance hierarchy, etc.), I could already reproduce the compiler error on a simplified test case. In particular, I developed three test cases which are attached to this post. The following outcome was observed for these three test cases:

- overloaded_assignment_test1.f90: compiles and generates the output that I would expect.

amartin@Aetos:~/pruebas_fortran_03$ ifort overloaded_assignment_test1.f90
amartin@Aetos:~/pruebas_fortran_03$ ./a.out
 A_C1_t
 C_C1_t

- overloaded_assignment_test2.f90: DOES NOT COMPILE. I believe it to be standard confirming. Compiler error is as follows:

overloaded_assignment_test2.f90(104): error #6197: An assignment of different structure types is invalid.   [C1]
  B = C1
------^
compilation aborted for overloaded_assignment_test2.f90 (code 1)

Note that the only difference among *test1 and *test2, is that, in the latter, the (abstract) intermediate-level data type, type(C_t), has a deferred TBP, called output_C, which its children, type(C1_t) and type(C2_t), are forced to implement.

- overloaded_assignment_test3.f90. Compiles and generates the output that I would expect.

amartin@Aetos:~/pruebas_fortran_03$ ifort overloaded_assignment_test3.f90
amartin@Aetos:~/pruebas_fortran_03$ ./a.out
 A_C1_t
 C_C1_t

Note that the only difference among *test2 and *test3 is that the overloaded assignment is called with a rhs being of "class(C_t) :: pointer" type previously set to point to the instance of type(C1_t), instead of with a rhs being of type(C1_t) directly.

Could you please help me and confirm my suspicions? (i.e., a compiler related issue) How can it be more elegantly work-arounded?

Thanks very much in advance for your support.

OK, I'm having issues getting ifort to pull in functions out of libraries that weren't included in the intel package.

I had these issues with a copy of the BLAS library I compiled with ifort, but I ended up working around that using mkl.

However, this library I can't work around.    I'm sure it's something I'm doing wrong, or is wrong in the environment.   

I know the function is there in the library, 

nm -g libwsmp64.a | grep wgsmp

wgsmp.o:

0000000000001410 T wgsmp

0000000000000000 T wgsmp_

000000000000ad00 T wgsmp1

But when I run the compile, I continue to get errors like this.   And this exact file is the example file that's included with the library.

ifort -L /abs_work/wlib/ -lwsmp64 wgsmp_ex1.f

/tmp/ifortOWJLnd.o: In function `MAIN__':

wgsmp_ex1.f:(.text+0x40): undefined reference to `wsetmaxthrds_'

wgsmp_ex1.f:(.text+0x47): undefined reference to `wsmprtc_'

wgsmp_ex1.f:(.text+0xa4): undefined reference to `wgsmp_'

wgsmp_ex1.f:(.text+0xf0): undefined reference to `wsmprtc_'

wgsmp_ex1.f:(.text+0x12b): undefined reference to `wsmprtc_'

wgsmp_ex1.f:(.text+0x17d): undefined reference to `wgsmp_'

There are more errors, but it does appear to find the library (there's no -lwsmp64 not found error)

Any ideas on what I may be doing wrong ?

I have installed COMPOSER XE 2011 on a Windows 2008 R2 server with Visual Studio 2010.   The install was done in 2012 and has been running well until today.   With no known changes to FORTRAN or VS, I can no longer compile.   Any routine that attempts a FORTRAN compile causes a problem with routine fcA40B_tmp.exe.    We can still compile C++ routines so the problem is only related to FORTRAN.

I have also tried to re-install/repair and get an error trying to read existing licenses in chklic.exe.   I did not think Intel licenses had an expiration date but the problems appear to be license related.

Any thoughts/experience with these sorts of problems with COMPOSER after about 3-1/2 years?

I've been given a program developed for gfortran that relies on the -finit-local-zero option, which initializes all local variables to zero. (The option is documented here: https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html.) This is different than the Intel -init option, which apples only to SAVEd variables.

I would really like to use Intel Fortran with this program. Is there some way to get the Intel compiler to initialize all local variables to zero, like gfortran does?

The essence of the problem is shown below:

! In DLL 1 (Fortran)

! ==> File: my_mod.f90
module my_mod

    type my_type
    contains
    end type my_type

contains

    subroutine my_sub() bind(c,name='MY_SUB')
    !DEC$ ATTRIBUTES DLLEXPORT :: MY_SUB
    end subroutine my_sub

end module my_mod
! ==> End file

! File: another.for
      subroutine another_sub
          use my_sub
	      type(my_type) :: t
      end subroutine another_sub
! ==> End file

! MY_SUB is also specified in the EXPORTS section of the .def file for the DLL

! =============================================================================

// In DLL 2 (C++)
// File: dll2.cpp
extern "C" {
    void MY_SUB();
};

void dll2_proc() {
	MY_SUB();
}
// ==> End file

When I try to build DLL2 I get a link error that MY_SUB is missing unless I include the 'another.for' file in DLL1, so the behaviour is that the symbol MY_SUB is exported iff the module is used in DLL1; note that the subroutine another_sub has to be called in another part of DLL1 that gets used elsewhere. Adding the symbol to the .def file and DLLEXPORTS directive has no effect. I have tried this with VS2010 &IFV14, and VS2012 & IVF16 and the result is the same. Is this a known problem with a known solution?
 

Dear Intel Fortran team, and Steve Lionel,

I am a member of a computational research group and I have been appointed to develop an agent-based model from scratch for some biological processes. I am very much fluent in Fortran, and in love with it, obviously for its efficiency in number-crunching and really nice math and array-handling tools.

However, I seems like C++ is gradually gaining some momentum in the world of HPC and I have heard of some rumors that object-oriented Fortran codes may not be as efficient as OOP in C++.   Is this a myth or reality?

Also, since our software is expected to be scalable and well-maintained over the following years and perhaps decades, I wanted to know about Intel's plan for supporting Fortran in future.

If you have any advice or comments on why I should choose or not choose Fortran against C++ for OOP, I'd appreciate it very much.

Can I rely on coarray feature in Fortran for parallelization of the code in future? How would you compare it with MPI? The coarray feature is one of the reasons I'd like to continue with Fortran.

A. K.

I have a source, exe program compiled by G95 used :

G95 *.f03 mainlib.a

where the mainlib.a is a compact index of a lot of subroutines and compiled as the following:

G95 -c *.f03 *.o

ar -r mainlib.a *.o

The mainlib.f03 shown as following:

MODULE main
!
INTERFACE
!
SUBROUTINE mesh(g_coord,g_num,ips)
!
!  this subroutine draw the finite element mesh
!
 IMPLICIT NONE
 REAL,INTENT(IN)::g_coord(:,:)
 INTEGER,INTENT(IN)::g_num(:,:),ips
END SUBROUTINE mesh
!
SUBROUTINE interp(k,dt,rt,rl,al,ntp)
.
.
.
END SUBROUTINE interp
!
END INTERFACE
!
END MODULE MAIN

I want know how to compile this exe in Intel Fortran. The mainlib.a is not a library and I do not know how to link it with other Fortran program.

I've inherited a huge Fortran library that is built under Microsoft Visual Studio as a static library and subsequently linked into an executable using an Ada build tool with an Ada main program.

Need to develop formal tests and would love to use Code Coverage.

I've only seen examples of using Code Coverage where the executable is built with the Intel Fortran compiler.

Is it possible to (manually) link in the Code Coverage libraries needed for an externally generated executable?

I currently get several unresolved symbols: _PGOPTI_Prof_Begin_V13, _PGOPTI_Prof_Div_VP_V13, _PGOPTI_Prof_Icall_V13

I realize this may be out of the intended scope for the product...

Hi,

while installing Intel composer XE 2013, I get this error "the following components cannot be installed - integration(s) in Microsoft visual studio*"

my Os is Windows 8.1 and I have Microsoft Visual Studio 2015 installed on my computer. I have no idea where this error comes from.pleas help me it is so urgent.

Thanks in advance

Hello ! 

I've noticed that different calls are made in kmpc_threadprivate on different cases like this : 

void * __kmpc_threadprivate(ident_t *loc, kmp_int32 global_tid, void *data, size_t size)
{
	void *ret;
    struct private_common *tn;

	if ( ! __kmp_threads[global_tid] -> th.th_root -> r.r_active && ! __kmp_foreign_tp )
	{
        kmp_threadprivate_insert_private_data( global_tid, data, data, size );
        ret = data;
    }
    else
    {
        tn = __kmp_threadprivate_find_task_common( __kmp_threads[ global_tid ]->th.th_pri_common, global_tid, data );
        if ( tn ) {
            //nothing
        }
        else {
            tn = kmp_threadprivate_insert( global_tid, data, data, size );
        }
        ret = tn->par_addr;
    }
    return ret;
}

I don't really get why there is a special case for 

r_active && ! __kmp_foreign_tp

because in kmp_threadprivate_insert_private_data, if we don't find the data, the is no allocation of new data or update of the given pointer... just update of the structs.

Moreover, what are the struct shared_common used for ? we already have struct private_common right ? why make two ?