On Tue, Sep 30, 2014 at 12:48 AM, Junio C Hamano <[email protected]> wrote:
> Duy Nguyen <[email protected]> writes:
>
>> On Sun, Sep 28, 2014 at 2:50 PM, Ben Walton <[email protected]> wrote:
>>> Oracle Studio compilers don't allow for static variables in functions
>>> that are defined to be inline. GNU C does permit this. Let's reference
>>> the C99 standard though, which doesn't allow for inline functions to
>>> contain modifiable static variables.
>>>
>>> Signed-off-by: Ben Walton <[email protected]>
>>> ---
>>>  trace.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/trace.c b/trace.c
>>> index b6f25a2..4778608 100644
>>> --- a/trace.c
>>> +++ b/trace.c
>>> @@ -385,7 +385,7 @@ static inline uint64_t gettimeofday_nanos(void)
>>>   * Returns nanoseconds since the epoch (01/01/1970), for performance 
>>> tracing
>>>   * (i.e. favoring high precision over wall clock time accuracy).
>>>   */
>>> -inline uint64_t getnanotime(void)
>>> +uint64_t getnanotime(void)
>>>  {
>>>         static uint64_t offset;
>>
>> Would moving this offset outside getnanotime() work?
>
> I am not sure what the definition of "work" is.
>
> The function computes the difference between the returned value from
> gettimeofday(2) and a custom highres_nanos() just once and returns
> the value it got from gettimeofday the first time, and then for
> subsequent calls massages the returned value from highres_nanos() to
> be consistent with the value returned from gettimeofday using the
> offset it computed in the first call.
>
> If we have two copies of this function, two independent probes to
> these pair of underlying functions will be made to compute their
> offsets.

Hmm.. no. Even if the function is inlined in multiple places, inline
code still points to the same "offset" variable. So the
gettimeofday_nanos()/highres_nanos() pair should only be called once.
Tested with gcc.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to