在 2021-05-04 23:50, Martin Storsjö 写道:
On Tue, 4 May 2021, Liu Hao wrote:
在 2021-05-04 18:03, Christian Franke 写道:
Next try attached.
Thanks. This patch looks good to me. I may push this one if others don't have
objections on it.
That patch seems to work for me, thanks!
Good, I
On Tue, 4 May 2021, Liu Hao wrote:
在 5/4/21 2:48 AM, Martin Storsjö 写道:
Sure. However in practice, with e.g. code like this:
typedef void (*fp)(void);
_Atomic fp ptr1 = ((void(*)(void))0);
_Atomic fp ptr2 = ((void*)0);
Clang accepts ptr1 but errors out on ptr2:
On Tue, 4 May 2021, Liu Hao wrote:
在 2021-05-04 18:03, Christian Franke 写道:
Next try attached.
Thanks. This patch looks good to me. I may push this one if others don't have
objections on it.
That patch seems to work for me, thanks!
// Martin
在 2021-05-04 18:03, Christian Franke 写道:
Next try attached.
Thanks. This patch looks good to me. I may push this one if others don't have
objections on it.
If the '__atomic*()' are not used, gcc 10.2.0 -O2 generates the same code. '__ATOMIC_SEQ_CST' would
make a difference: the store is
Liu Hao wrote:
在 5/4/21 2:48 AM, Martin Storsjö 写道:
...
In practice it shouldn't really matter, because as Jacek points out,
we should be able to do without the atomics just fine in practice here.
Yes, see below.
I think I have to disagree on this. Just because something works 'in
在 5/4/21 2:48 AM, Martin Storsjö 写道:
Sure. However in practice, with e.g. code like this:
typedef void (*fp)(void);
_Atomic fp ptr1 = ((void(*)(void))0);
_Atomic fp ptr2 = ((void*)0);
Clang accepts ptr1 but errors out on ptr2: https://gcc.godbolt.org/z/3YW6EsGP4
It looks like a bug. As per
On Mon, 3 May 2021, Jacek Caban wrote:
I'd say that we should skip it altogether. Atomic operations seem
totally redundant in this case. What would it protect from? It won't
prevent multiple GetProcAddress calls - for that we'd need a critical
section. Since GetProcAddress will always return
On Mon, 3 May 2021, Liu Hao wrote:
在 2021-05-03 20:52, Martin Storsjö 写道:
On Mon, 3 May 2021, Christian Franke wrote:
Would plain '... = 0' without cast also work ? IIRC it should since C89
:-)
That doesn't work either - clang seems to consider the cast (either
implicit or explicit)
在 2021-05-03 20:52, Martin Storsjö 写道:
On Mon, 3 May 2021, Christian Franke wrote:
Would plain '... = 0' without cast also work ? IIRC it should since C89 :-)
That doesn't work either - clang seems to consider the cast (either implicit or explicit) between a
integer or pointer-to-integer
On 5/3/21 2:52 PM, Martin Storsjö wrote:
On Mon, 3 May 2021, Christian Franke wrote:
Would plain '... = 0' without cast also work ? IIRC it should since
C89 :-)
That doesn't work either - clang seems to consider the cast (either
implicit or explicit) between a integer or pointer-to-integer
在 2021-05-03 20:30, Christian Franke 写道:
Would plain '... = 0' without cast also work ? IIRC it should since C89 :-)
Alternative: Leave '/* = 0 */' only as a comment. There is no need to
set a static variable to 0.
Either using `= 0` as the initializer or omitting it should work. I don't
On Mon, 3 May 2021, Christian Franke wrote:
Would plain '... = 0' without cast also work ? IIRC it should since C89 :-)
That doesn't work either - clang seems to consider the cast (either
implicit or explicit) between a integer or pointer-to-integer and a
pointer-to-function as something
Martin Storsjö wrote:
On Mon, 3 May 2021, Martin Storsjö wrote:
On Mon, 3 May 2021, Christian Franke wrote:
Liu Hao wrote:
在 2021-05-03 14:49, Martin Storsjö 写道:
Just for the record - I wouldn't mind applying the patch or
something like it. I agree with the arguments that it would be
On Mon, 3 May 2021, Martin Storsjö wrote:
On Mon, 3 May 2021, Christian Franke wrote:
Liu Hao wrote:
在 2021-05-03 14:49, Martin Storsjö 写道:
Just for the record - I wouldn't mind applying the patch or something
like it. I agree with the arguments that it would be beneficial to get
more
On Mon, 3 May 2021, Christian Franke wrote:
Liu Hao wrote:
在 2021-05-03 14:49, Martin Storsjö 写道:
Just for the record - I wouldn't mind applying the patch or something like
it. I agree with the arguments that it would be beneficial to get more
precision here, even if one in general maybe
Liu Hao wrote:
在 2021-05-03 14:49, Martin Storsjö 写道:
Just for the record - I wouldn't mind applying the patch or something
like it. I agree with the arguments that it would be beneficial to
get more precision here, even if one in general maybe can argue that
we don't strictly need to
Liu Hao wrote:
在 2021-04-29 03:34, Christian Franke 写道:
BTW.2: The *ftime*() functions from newer versions of MSVC CRT also use
GetSystemTimePreciseAsFileTime() if available.
UCRTBASE.DLL still uses `GetSystemTimeAsFileTime()`.
A test program build with VS2019 and estimation of the
在 2021-05-03 14:49, Martin Storsjö 写道:
Just for the record - I wouldn't mind applying the patch or something like it. I agree with the
arguments that it would be beneficial to get more precision here, even if one in general maybe can
argue that we don't strictly need to provide such
On Wed, 28 Apr 2021, Liu Hao wrote:
在 4/27/21 2:00 AM, Christian Franke 写道:
Which complexity do you mean - the extra cost of the system call or the
extra 15 lines of code?
Just for the record - I wouldn't mind applying the patch or something like
it. I agree with the arguments that it
在 2021-05-03 00:39, Dan Raymond 写道:
I don't agree with this. First: precision and accuracy are two entirely different things so it's
important not to use them interchangeably. It is true that the absolute value of the wall clock
time is not likely to be very accurate. If you are interested
1. `clock_gettime()` is not meant to be precise, and it shouldn't be,
because the extra accuracy is useless. (It may make some sense for
logging, as mentioned in another message; but in logs only the order
of writes matters, while timestamps don't matter.)
I don't agree with this. First:
在 2021-04-29 03:34, Christian Franke 写道:
BTW.2: The *ftime*() functions from newer versions of MSVC CRT also use
GetSystemTimePreciseAsFileTime() if available.
UCRTBASE.DLL still uses `GetSystemTimeAsFileTime()`. It does not even have an entry for the precise
one in its import directory
Vincent Torri wrote:
On Wed, Apr 28, 2021 at 9:35 PM Christian Franke
<...> wrote:
BTW.1: Hack:
Do this once in the program
#ifdef _WIN32
timeBeginPeriod(1);
https://docs.microsoft.com/fr-fr/windows/win32/api/timeapi/nf-timeapi-timebeginperiod?redirectedfrom=MSDN
"Setting a higher
Corinna Vinschen wrote:
On Apr 26 20:00, Christian Franke wrote:
System calls and resolutions of C++11 clocks:
Mingw-w64 MSVC16 Cygwin
system_clock::now() 1 2 2
steady_clock::now() 1 3 3
On Wed, Apr 28, 2021 at 9:35 PM Christian Franke
wrote:
>
> Liu Hao wrote:
> > 在 4/27/21 2:00 AM, Christian Franke 写道:
> >>
> >> Which complexity do you mean - the extra cost of the system call or
> >> the extra 15 lines of code?
> >>
> >
> > It's actually both.
> >
> > Wall clocks are not meant
Liu Hao wrote:
在 4/27/21 2:00 AM, Christian Franke 写道:
Which complexity do you mean - the extra cost of the system call or
the extra 15 lines of code?
It's actually both.
Wall clocks are not meant to be steady, because they are free to jump
back and forth due to NTP synchronization, and
com>
Sent: Wednesday, April 28, 2021 15:05
To:
mingw-w64-public@lists.sourceforge.net<mailto:mingw-w64-public@lists.sourceforge.net>
Subject: Re: [Mingw-w64-public] [PATCH] crt: Increase precision of
gettimeofday() if possible.
On Apr 26 20:00, Christian Franke wrote:
> System calls and
On Apr 26 20:00, Christian Franke wrote:
> System calls and resolutions of C++11 clocks:
>
> Mingw-w64 MSVC16 Cygwin
> system_clock::now() 1 2 2
> steady_clock::now() 1 3 3
> high_resolution_clock::now() 1
在 4/27/21 2:00 AM, Christian Franke 写道:
Which complexity do you mean - the extra cost of the system call or the extra
15 lines of code?
It's actually both.
Wall clocks are not meant to be steady, because they are free to jump back and forth due to NTP
synchronization, and arithmetic
Liu Hao wrote:
在 2021-04-22 20:35, Christian Franke 写道:
This patch significantly increases the precision of gettimeofday() on
Windows 8 or later. It is then similar to Cygwin or Linux.
It also affects C++11 std::chrono:*_clock as
_GLIBCXX_USE_GETTIMEOFDAY is defined but not
在 2021-04-22 20:35, Christian Franke 写道:
This patch significantly increases the precision of gettimeofday() on Windows 8 or later. It is then
similar to Cygwin or Linux.
It also affects C++11 std::chrono:*_clock as _GLIBCXX_USE_GETTIMEOFDAY is defined but not
_GLIBCXX_USE_CLOCK_*.
A similar
31 matches
Mail list logo
