--- Comment #13 from tkoenig at gcc dot gnu dot org 2007-12-27 12:36
---
Let's close this.
If anybody disagrees, please reopen :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-12-26 14:24
---
Can't we close this?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dfranke at gcc dot gnu dot org 2007-12-25 10:42
---
Subject: Bug 34533
Author: dfranke
Date: Tue Dec 25 10:41:44 2007
New Revision: 131168
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131168
Log:
gcc/fortran:
2007-12-25 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-12-20 22:33
---
> From Note 13.8:
> The start time is left imprecise because the purpose is to time
> sections of code, as in the example.
Thanks for pointing it out. I'll re-add this fallback to CPU_TIME.
--
http://gcc.
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu
2007-12-20 22:27 ---
Subject: Re: DTIME returns total process time and not since last invocation
On Thu, Dec 20, 2007 at 09:39:29PM -, dfranke at gcc dot gnu dot org wrote:
>
> > Daniel, are you working on this P
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-12-20 21:39 ---
> one needs to make dtime() a full-fledged intrinsic procedure.
This minute, I just realized the same ...
> Daniel, are you working on this PR?
Sort of. Finished the library part.
Btw, CPU_TIME has a fallback im
--- Comment #7 from kargl at gcc dot gnu dot org 2007-12-20 21:28 ---
A quick scan of intrinsics.c shows that dtime() is treated as an alias
to etime(). So, one needs to make dtime() a full-fledged intrinsic
procedure.
add_sym_1 ("etime", GFC_ISYM_ETIME, NO_CLASS, ACTUAL_NO, BT_REAL,
--- 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 bot
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-12-20 18:35 ---
> 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 probabl
--- Comment #4 from kargl at gcc dot gnu dot org 2007-12-20 18:26 ---
(In reply to comment #3)
> Another question: contrary to g77, we now have support for OpenMP. How about
> concurrency issues? Shall DTIME give the time since the last invokation from
> any thread, i.e. maintain a globa
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-12-20 16:41 ---
Another question: contrary to g77, we now have support for OpenMP. How about
concurrency issues? Shall DTIME give the time since the last invokation from
any thread, i.e. maintain a global storage, or the last invoka
--- Comment #2 from dominiq at lps dot ens dot fr 2007-12-20 15:57 ---
> Description:
> Subsequent invocations of DTIME return values accumulated since the previous
> invocation.
>
> Return value:
> Elapsed time in seconds since the start of program execution.
This at best ambiguous an
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-12-20 14:32 ---
> http://gcc.gnu.org/onlinedocs/gfortran/DTIME.html
Description:
Subsequent invocations of DTIME return values accumulated since the previous
invocation.
Return value:
Elapsed time in seconds since the start of pro
13 matches
Mail list logo
