Test case:
program testhour
use omp_lib
integer :: h(1000), h1(1000), bins(0:23), v(8)
call omp_set_num_threads(4)
print *, "Running on",omp_get_max_threads(),"threads
and",omp_get_num_procs(),"procs."
!$omp parallel do schedule(STATIC,250)
do i=1,1000
call date_and_time(values=v)
h(i) = v(5)
end do
!$omp end parallel do
print *, "date_and_time hour:"
bins = 0
do i=1,1000
bins(h(i)) = bins(h(i)) + 1
end do
do i=0,23
if (bins(i) > 0) print *, "For",bins(i),"calls, hour =",i
end do
end program testhour
Compile with -fopenmp, and run on 4 threads:
> aprun -n1 -d4 ./dattest
Running on 4 threads and 1 procs.
date_and_time hour:
For 707 calls, hour = 13
For 293 calls, hour = 18
Application 2721423 resources: utime 0, stime 0
This was run in US Central Daylight time zone. Most of the time, the correct
hour (13) was returned, but a sizable number of times, the hour correct for GMT
was returned instead. It looks like the conversion from GMT to the local time
zone sometimes fails when the routine is concurrently called from more that one
thread.
I wrote a similar program that called the system localtime() routine instead,
as well as localtime_r(), and both consistently returned the correct hour.
The same code compiled with either the Cray or PGI compiler consistently
returns the same hour for every iteration.
--
Summary: DATE_AND_TIME returns GMT hour sometimes with OpenMP
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC host triplet: Linux, x86-64
GCC target triplet: Linux, x86-64 (quad-core Opteron)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40190
