This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/34533] DTIME returns total process time and not since last invocation
- From: "kargl at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Dec 2007 19:39:13 -0000
- Subject: [Bug fortran/34533] DTIME returns total process time and not since last invocation
- References: <bug-34533-13404@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #6 from kargl at gcc dot gnu dot org 2007-12-20 19:39 -------
(In reply to comment #5)
> > I think gfortran will need to handle it similar to how random_seed is done.
>
> Using a mutex, yes, that's what I thought as well. Btw, CPU_TIME gives values
> per process and does not bother with threads. DTIME probably wants to do the
> same?
I thought about this a little more. Because dtime() is provided for
backwards compatibility with g77 and g77 did not (to my knowledge)
support any kind of threading model, I would make it work under the
assumption of a nonthreaded process. In the documentation, simply
note that the behavior of dtime() is undefined (or processor-dependent)
when used in a threaded process.
Otherwise, I think you're going to run into strange race conditions
and oddly reported timings.
> While at it, a common time aquisition function for all three, CPU_TIME, DTIME
> and ETIME, would be useful. Currently, ETIME has an implementation separate
> from CPU_TIME -- but both use getrusage().
It's been a long time since I looked at the code. But, yes, I would think
one would want a single aquisition function with the intrinsics being
simple wrappers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533