[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#710220: marked as done (libstdc++6: 4.8.0-8 upgrade breaks system_clock)

Your message dated Wed, 21 Aug 2013 15:45:58 +0200
with message-id <5214C496.8030601@debian.org>
and subject line Re: Bug#710220: libstdc++6: 4.8.0-8 upgrade breaks system_clock
has caused the Debian Bug report #710220,
regarding libstdc++6: 4.8.0-8 upgrade breaks system_clock
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
710220: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710220
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libstdc++6
Version: 4.8.0-8
Severity: important

Dear Maintainer,

Attached test case gets the current system time using std::chrono and using
gettimeofday, both with millisecond precision. Using libstdc++6 version 4.8.0-7,
this code works properly, both timestamps being identical. However, since
upgrading to 4.8.0-8, the std::chrono version reports a timestamp in seconds
despite the explicit duration_case to milliseconds, when compiling with GCC 4.6
or 4.7. Using libstdc++6 4.8.0-8 with GCC 4.8 results in correct output.

Looking through the preprocessed output, it seems like there is a a mismatch
between the system_clock duration of the preprocessed output (i.e. the duration
field in the system_clock struct generated by the chrono header) and the one
libstdc++ exposes. The output compiled with GCC 4.7 contains a system_clock
struct with a duration typedef'd to std::chrono::nanoseconds, which results in
correct timestamps using libstdc++6 version 4.8.0-7 but doesn't with version
4.8.0-8 (off by a factor of 1000). GCC 4.8 uses a nanosecond duration as well,
but accesses a system_clock within a V2 namespace, which seems to expose a
nanosecond-precision.

I'm guessing the upgrade to libstdc++6 version 4.8.0-8 changed the system_clock
exposed by the library, now using microsecond precision rather than nanosecond
precision (the V2 system_clock seems to be the one offering nanosecond precision
now). This conflicts with the chrono header, which -- due to the
_GLIBCXX_USE_CLOCK_REALTIME definition -- accesses the system_clock with
nanosecond duration.

Best,
Tim


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libstdc++6 depends on:
ii  gcc-4.8-base       4.8.0-8
ii  libc6              2.17-3
ii  libgcc1            1:4.8.0-8
ii  multiarch-support  2.17-3

libstdc++6 recommends no packages.

libstdc++6 suggests no packages.

-- no debconf information

#include <chrono>
#include <cstdio>
#include <sys/time.h>

int main()
{
    std::chrono::time_point<std::chrono::high_resolution_clock> tp
        = std::chrono::high_resolution_clock::now();
    printf("C++: %lu\n", std::chrono::duration_cast<std::chrono::milliseconds>
        (tp.time_since_epoch()).count());

    struct timeval tv;
    gettimeofday(&tv, NULL);
    printf("C:   %lu\n", tv.tv_sec * 1000 + tv.tv_usec / 1000);

    return 0;
}

--- End Message ---
--- Begin Message --- 
this is now fixed in gcc-4.6 and gcc-4.7 versions in unstable. closing the bug.

Am 30.05.2013 08:49, schrieb Tim Besard:
> Hi Matthias,
> 
>> Please could you name the software where you did see this failure?
> I only spotted this regression in my own development code, so it seems
> that the impact is limited after all.
> 
> Thanks,
> Tim
> 
>

--- End Message ---
Reply to: