First of all, I do think that the code is correct, is it?. I understand that the standard Do-loop is preferable in this case but the code is extracted from a larger application, where each thread needs to allocate a set of private working arrays and private derived types in order to perform some more complicated computations before it can copy the local results into the global array.

If the code is correct then is the data race problem reported by Intel Inspector XE really a "problem" which can be solved by a better implementation or is it an "internal problem" of the inspector tool?

When I repeat all your steps with ifort version12.1.1.256, then no errors/problems are reported. Unfortunately, my initial post was based on# ifort -VIntel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.1.107 Build 20101116Copyright (C) 1985-2010 Intel Corporation. All rights reserved.Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.1.107 Build 20101116Copyright (C) 1985-2010 Intel Corporation. All rights reserved.which yields# ifort test.f90 -g -openmp -openmp-report -o test.iforttest.f90(17) (col. 9): remark: OpenMP DEFINED LOOP WAS PARALLELIZED.test.f90(34) (col. 9): remark: OpenMP DEFINED LOOP WAS PARALLELIZED.test.f90(30) (col. 9): remark: OpenMP DEFINED REGION WAS PARALLELIZED.and#inspxe-cl -collect ti3 -- ./test.ifortWarning: One or more threads in the application accessed the stack of another thread. This may indicate one or more bugs in your application. Setting the Intel Inspector XE 2011 to detect data races on stack accesses and running another analysis may help you locate these and other bugs.0 new problem(s) foundIt seems that this problem is not related to inspector but to the compiler itself.I am sorry for all the inconvenience caused.Regards, Matthias