On 31/10/23 13:45, Martin Storsjö wrote:
On Wed, 25 Oct 2023, Mark Harmstone wrote:
Signed-off-by: Mark Harmstone
---
mingw-w64-crt/Makefile.am | 1 +
.../api-ms-win-shell-namespace-l1-1-0.def | 26 +++
mingw-w64-crt/lib-common/onecore_apiset.mri | 1 +
On 31/10/23 13:08, Martin Storsjö wrote:
On Tue, 31 Oct 2023, Martin Storsjö wrote:
On Wed, 25 Oct 2023, Mark Harmstone wrote:
Signed-off-by: Mark Harmstone
---
.../api-ms-win-core-rtlsupport-l1-2-0.def | 13 -
...api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def | 13 ---
In Windows Store builds with the winstorecompat library,
GetModuleHandle returns null, and GetProcAddress is not documented
to allow passing null.
Signed-off-by: Martin Storsjö
---
mingw-w64-libraries/winpthreads/src/clock.c | 8 +---
mingw-w64-libraries/winpthreads/src/misc.c | 4 +++-
m
On Tue, 31 Oct 2023, LIU Hao wrote:
在 2023-10-31 18:15, Martin Storsjö 写道:
02b4df13b1aac0dba0a35e87f1a536594fd35edd added attribute used to
_CRTALLOC, applying it automatically on most such special variables
that need to be retained during LTO. _tls_used is also such a variable,
but it's not lo
On Tue, 31 Oct 2023, LIU Hao wrote:
在 2023-10-31 21:37, Martin Storsjö 写道:
Yes, this is what I meant. The fact that Windows Store apps wouldn't be
getting the modern codepath with GetTickCount64, but unconditonally be
usin the old fallback codepath of using QueryPerformanceCounter,
doesn't se
在 2023-10-31 18:15, Martin Storsjö 写道:
02b4df13b1aac0dba0a35e87f1a536594fd35edd added attribute used to
_CRTALLOC, applying it automatically on most such special variables
that need to be retained during LTO. _tls_used is also such a variable,
but it's not located in any special section; thus app
在 2023-10-31 17:24, Martin Storsjö 写道:
The UCRT implementation of scalbn/scalbnf (and presumably ldexp
too, as it's an identical function) has a minor spec incompliance;
it doesn't respect the rounding mode that has been set.
For most uses of scalbn, rounding isn't at play at all; rounding
only
在 2023-10-31 21:37, Martin Storsjö 写道:
Yes, this is what I meant. The fact that Windows Store apps wouldn't be getting the modern codepath
with GetTickCount64, but unconditonally be usin the old fallback codepath of using
QueryPerformanceCounter, doesn't seem too bad, so I think that's acceptabl
On Wed, 25 Oct 2023, Mark Harmstone wrote:
Signed-off-by: Mark Harmstone
---
mingw-w64-crt/Makefile.am | 1 +
.../api-ms-win-shell-namespace-l1-1-0.def | 26 +++
mingw-w64-crt/lib-common/onecore_apiset.mri | 1 +
.../api-ms-win-shell-namespace-l1-1-0.def
On Tue, 31 Oct 2023, LIU Hao wrote:
在 2023/10/31 16:20, Martin Storsjö 写道:
Right. On the other hand, the QueryPerformanceCounter based fallback
implementation probably is workable enough for winstore apps as well, I
would guess, so perhaps it't not worth making a fuss about in the end
anyway.
在 2023/10/31 16:20, Martin Storsjö 写道:
Right. On the other hand, the QueryPerformanceCounter based fallback implementation probably is
workable enough for winstore apps as well, I would guess, so perhaps it't not worth making a fuss
about in the end anyway.
The issue is not about whether there
On Wed, 25 Oct 2023, Mark Harmstone wrote:
Signed-off-by: Mark Harmstone
---
mingw-w64-crt/Makefile.am | 2 +-
.../lib-common/api-ms-win-core-memory-l1-1-6_windowsapp.def | 6 ++
mingw-w64-crt/lib-common/windowsapp.mri | 2 +-
.../lib32/api
On Tue, 31 Oct 2023, Martin Storsjö wrote:
On Wed, 25 Oct 2023, Mark Harmstone wrote:
Signed-off-by: Mark Harmstone
---
.../api-ms-win-core-rtlsupport-l1-2-0.def | 13 -
...api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def | 13 -
.../lib32/api-ms-win-core-rtlsu
On Wed, 25 Oct 2023, Mark Harmstone wrote:
Signed-off-by: Mark Harmstone
---
.../api-ms-win-core-rtlsupport-l1-2-0.def | 13 -
...api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def | 13 -
.../lib32/api-ms-win-core-rtlsupport-l1-2-0.def | 3 ---
...api-ms-win-c
Seems reasonable to me, thanks for checking.
On 31/10/2023 18:14, Martin Storsjö wrote:
In LLVM LTO builds with cfguard enabled, the non-extern
__guard_dispatch_icall_dummy can't pose as replacement for the
undefined symbol reference to an extern __guard_dispatch_icall_dummy.
Signed-off-by: Mar
02b4df13b1aac0dba0a35e87f1a536594fd35edd added attribute used to
_CRTALLOC, applying it automatically on most such special variables
that need to be retained during LTO. _tls_used is also such a variable,
but it's not located in any special section; thus apply the attribute
directly.
Signed-off-by
In LLVM LTO builds with cfguard enabled, the non-extern
__guard_dispatch_icall_dummy can't pose as replacement for the
undefined symbol reference to an extern __guard_dispatch_icall_dummy.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/cfguard/mingw_cfguard_support.c | 1 +
1 file changed, 1 in
The UCRT implementation of scalbn/scalbnf (and presumably ldexp
too, as it's an identical function) has a minor spec incompliance;
it doesn't respect the rounding mode that has been set.
For most uses of scalbn, rounding isn't at play at all; rounding
only makes a difference when scaling the float
On Tue, 31 Oct 2023, Jacek Caban wrote:
I find the claim that it's fine to wait for longer to be questionable.
GetTickCount's value may be off by up to 16 ms, so the way elapsed time is
calculated in those helpers may be off by up to 32 ms. I guess that precise
waits matter mostly for short time
19 matches
Mail list logo
