https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #16 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > Or maybe the testcase makes invalid assumptions and isn't really measuring
> > what it thinks it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #15 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #14)
> Or maybe the testcase makes invalid assumptions and isn't really measuring
> what it thinks it's measuring?
e.g. maybe clock_getres says 100ns even though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #14 from Jonathan Wakely ---
Thanks!
So does that mean mingw-w64 fixed the issue by improving the resolution of
CLOCK_REALTIME?
In that case, this bug could be closed WORKSFORME.
Or maybe the testcase makes invalid assumptions and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #13 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Jonathan Wakely from comment #8)
> > Is this still an issue in 2022?
> >
> > Using a mingw-w64 cross-compiler and running under Wine I get:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap
> seconds to turn it into a sys_time. That's doable though.
Doable, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> Is this still an issue in 2022?
>
> Using a mingw-w64 cross-compiler and running under Wine I get:
>
> CLOCK_REALTIME: 0,100
> CLOCK_MONOTONIC: 0,100
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #10 from Jonathan Wakely ---
GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap
seconds to turn it into a sys_time. That's doable though.
Alternatively, we could use it to implement a high performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #9 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #4)
> For CLOCK_REALTIME, the Windows API GetSystemTimeAsFileTime is used.
> GetSystemTimePreciseAsFileTime is an improved version which provide "the
> highest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #8 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #4)
> With mingw-w64, the following program shows that the monotonic clock is far
> more precise:
>
> #include
> #include
>
> int main()
> {
> using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #7 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #5)
> BTW, what if the clock_gettime call failed? The current implementation does
> nothing about error handling... (Though for QPC on Windows it should rarely
> fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
Maybe we should make high_resolution_clock a typedef for steady_clock on
mingw-w64 but maybe only when using winpthreads.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target||mingw-w64
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #2 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
Which of macros are defined on mingw-w64?
Preprocessing this should tell you
#include chrono
#ifdef _GLIBCXX_USE_CLOCK_REALTIME
#ifdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
What libstdc++ is doing is sensible, why is the realtime clock so much coarser
than the monotonic clock on mingw-w64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #4 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
What libstdc++ is doing is sensible, why is the realtime clock so much
coarser than the monotonic clock on mingw-w64?
It is not always true that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #5 from frankhb1989 at gmail dot com ---
BTW, what if the clock_gettime call failed? The current implementation does
nothing about error handling... (Though for QPC on Windows it should rarely
fail for machines within a decade.)
16 matches
Mail list logo