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=40201