From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3475 invoked by alias); 23 May 2012 15:37:07 -0000 Received: (qmail 3404 invoked by uid 22791); 23 May 2012 15:37:06 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_BG X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 May 2012 15:36:53 +0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/53456] Add time support for VxWorks Date: Wed, 23 May 2012 15:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Ever Confirmed Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-05/txt/msg02286.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456 Tobias Burnus changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #6 from Tobias Burnus 2012-05-23 15:36:26 UTC --- (In reply to comment #4) > VxWorks does not provide the process time in most versions and for most > cases. In fact, many VxWorks applications are not processes in the > traditional sense but instead tasks/threads spawned by the kernel in kernel > space. That's not different to, e.g., RTEMS which only allows for a single process but multiple threads. > If returning an error is the preferred behavior for gf_cputime, then the code > as is should work. I think returning "-1" is a sensible choice as the information is not available. An alternative would be: clock_gettime with CLOCK_MONOTONIC - but the starting point is not defined; in case of VxWorks it seems to be the elapsed since system startup, which would be a reasonable choice. However, POSIX allows other choices, for instance since the (Unix) epoch. [Plus CLOCK_MONOTONIC seems to be valid only in VxWorks 6.x but not in 5.x] (Another choice - available in 5.x - would be to use tickGet(), but that can be reset via tickSet and has probably some other issues.) Thus, instead of creating a special case for VxWorks, relying on 0 == start up time, and papering over the difference between kernel startup vs. program startup, returning -1 seems to be best. Note: Fortran provides SYSTEM_CLOCK which - with libgfortran - calls clock_gettime (using CLOCK_MONOTONIC if available and CLOCK_REALTIME if not) - or as fall back, it calls gf_gettime (which calls gettimeofday, clock_gettime w/ CLOCK_REALTIME, or time().)