Hi,
thanks for working on this and unifying this inlining issues. Looks good to me.
Thanks
Kai
Am Mi., 8. Mai 2024 um 14:23 Uhr schrieb Martin Storsjö :
>
> Prior to 1652e9241b5d8a5a779c6582b1c3c4f4a7cc66e5, the inline
> functions always were static. Due to reexporting such symbols
> in C++20 m
Thanks!
Am Fr., 14. Okt. 2022 um 15:24 Uhr schrieb Martin Storsjö :
>
> On Fri, 14 Oct 2022, Kai Tietz wrote:
>
> > Yes, look good to me. Wouldn't it make sense to add __mingww64_stpcpy
> > function, so we could provide this function in an more compatible way?
>
>
Yes, look good to me. Wouldn't it make sense to add __mingww64_stpcpy
function, so we could provide this function in an more compatible way?
Thanks,
Kai
Am Fr., 14. Okt. 2022 um 14:16 Uhr schrieb LIU Hao :
>
> 在 2022/10/14 19:38, Martin Storsjö 写道:
> > Initially, it may seem like this function m
GoFundMe zu unterstützen: https://gofund.me/83986499.
Best regards,
Kai Tietz
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Patch is ok.
Thanks,
Kai
We might could introduce a helper macro in _mingw_mac.h for it?
2018-08-14 13:55 GMT+02:00 Liu Hao :
> 在 2018-08-14 19:21, Martin Storsjö 写道:
>> Clang got support for the .rva assembler directive soon before
>> the clang 7.0 release branch was made.
>>
>> This breaks use
Thanks for fixing this. Please apply.
Kai
2018-03-12 21:34 GMT+01:00 Martin Storsjö :
> This fixes the function when built with clang.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/math/x86/cossin.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/mingw-
Ok.
Thanks Kai
2018-03-11 23:29 GMT+01:00 Martin Storsjö :
> This attribute is available since GCC 4.2.
>
> The previous trick of using inline assembly for overriding the stack
> pointer behind the compiler's back isn't guaranteed to work.
>
> This fixes stack alignment on llvm/clang.
>
> Signed-
Patch is ok.
Thanks,
Kai
2018-03-11 21:57 GMT+01:00 Martin Storsjö :
> On 32 bit x86, clang seems to miss loading input parameters based
> on asm constraints for inline assembly that uses the x87 floating
> registers, unless the snippet has got the volatile keyword.
>
> Signed-off-by: Martin Stor
Patch is ok.
Thanks,
Kai
2018-02-27 23:23 GMT+01:00 Jacek Caban :
>
> Based on patch by Ruslan Garipov.
>
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-headers/include/uianimation.idl | 6 ++
> 1 file changed, 6 insertions(+)
>
>
>
>
Ok, thanks.
Cheers,
Kai
2018-02-23 11:02 GMT+01:00 Martin Storsjö :
> This fixes building the following with libc++:
>
> #include
> #include
>
> With libc++, yvals.h is implicitly included by anything that includes
> locales (via xlocinfo.h).
>
> Signed-off-by: Martin Storsjö
> ---
>
2018-02-23 10:56 GMT+01:00 Martin Storsjö :
> On Fri, 23 Feb 2018, Kai Tietz via Mingw-w64-public wrote:
>
>> Patch looks fine beside one nit. The behavior above 4294967 seconds
>> seems to be pretty unexpected, isn't it?
>
>
> Well since the useconds_t parameter
Patch looks fine beside one nit. The behavior above 4294967 seconds
seems to be pretty unexpected, isn't it?
Cheers,
Kai
2018-02-22 22:17 GMT+01:00 Martin Storsjö :
> Even though the POSIX spec of usleep says that the argument shall
> be less than one million. Most unixes allow it and sleeps for
hmm, ok. But it might be better to temporary undefine _Bool via
'push_macro/pop_macro' pragma?
Kai
2018-02-23 10:20 GMT+01:00 Martin Storsjö :
> From: Hugo Beauzée-Luyssen
>
> This fixes building the following with libc++:
>
> #include
> #include
>
> With libc++, yvals.h is implicitly
Hey Jacek,
sorry for answering this late. I have no objections to get in synch
with Wine's upstream version. As long as midl isn't open sourced, and
there is a ported version of it for none-windows world too, we will
stick to the Wine version for sure.
Thanks,
Kai
2017-12-18 19:27 GMT+01:00 J
Patch is ok.
Thanks,
Kai
2018-02-06 23:17 GMT+01:00 Martin Storsjö :
> When using GNU binutils, the function aliases won't work transitively,
> i.e. the strcmpi == _strcmpi alias in msvcrt-common.def.in won't
> use the second alias of _strcmpi == _stricmp in ucrtbase.def.in but
> will instead end
Ok. Thanks, Kai
2018-02-06 11:53 GMT+01:00 Jacek Caban :
>
> This reverts 9b27e7e9ce13d05de3527878031e47cfe6eca06b. We update VERSION
> file to Wine version, which is imported into configure script.
>
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-tools/widl/wine-import.sh | 1 +
> 1 file change
Patch is ok.
Thanks,
Kai
2018-01-29 11:52 GMT+01:00 Liu Hao :
> On 2018/1/29 18:37, Liu Hao wrote:
>> The definitions of `struct _USB_DEVICE_CAPABILITY_BILLBOARD_DESCRIPTOR`
>> and `typedef struct
>> _USB_SUPERSPEEDPLUS_ISOCH_ENDPOINT_COMPANION_DESCRIPTOR` got moved
>> upwards to match their orig
Hey,
why you include _mingw_mac.h before including minwindef.h ? This seems
to be superflous. The header mingwindef.h includes already _mingw.h,
which includes for sure _mingw_mac.h too.
Te patch is ok with that change.
Thanks,
Kai
2018-01-29 11:36 GMT+01:00 Liu Hao :
> This caused trouble whe
Hey,
patch is ok. Please go ahead and apply.
Thanks,
Kai
2018-01-13 13:27 GMT+01:00 Liu Hao :
> The attached patch adds `const` qualifiers that were missing.
>
> --
> Best regards,
> LH_Mouse
>
>
> --
> Check out the vib
Hello,
it is a common, but nevertheless wrong assumption, that %z formatter
is compatible for different runtimes. Especially msvcrt is all but
C99 compatible. If you have enabled the use our C99 compatible
printf/scanf implementation via the __USE_MINGW_ANSI_STDIO macro, then
you will see that %
Ok.
Thanks,
Kai
2018-01-22 19:00 GMT+01:00 Jacek Caban :
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-headers/include/dwrite_3.h | 587
> +++
> 1 file changed, 587 insertions(+)
> create mode 100644 mingw-w64-headers/include/dwrite_3.h
>
>
>
>
Hmm, ok. Shouldn't we special case unnamed union/struct?
Kai
2018-01-22 19:00 GMT+01:00 Jacek Caban :
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-headers/include/dwrite_1.h | 53
>
> 1 file changed, 53 insertions(+)
>
>
>
> ---
Patch is ok.
Kai
2018-01-22 19:00 GMT+01:00 Jacek Caban :
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-headers/include/d2d1_1.h | 1 -
> mingw-w64-headers/include/d2dbasetypes.h | 9 -
> mingw-w64-headers/include/dcommon.h | 22 ++
> 3 files changed, 2
Patch is ok.
Thanks,
Kai
2018-01-22 19:00 GMT+01:00 Jacek Caban :
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-headers/include/dwrite.h | 4
> 1 file changed, 4 insertions(+)
>
>
>
> --
> Check out the vibrant te
Patch is ok. But this is indeed problematic that clang doesn't support
different scanf/printf warning API.
For C99 printf/canf formatter diagnostic the produced warnings will be
wrong for this compiler.
Thanks
Kai
2018-01-21 12:15 GMT+01:00 Martin Storsjö :
> On Sun, 21 Jan 2018, Jacek Caban wrot
Patch is ok.
Thanks,
Kai
2018-01-19 18:38 GMT+01:00 Jacek Caban :
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-headers/include/psdk_inc/intrin-impl.h | 83
>
> 1 file changed, 41 insertions(+), 42 deletions(-)
>
>
>
> --
Hello,
patch is ok. Please go ahead and apply.
Thanks (and a happy new year for you),
Kai
2018-01-08 15:51 GMT+01:00 Martin Storsjö :
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-headers/crt/sec_api/stdio_s.h | 655
> +++-
> mingw-w64-headers/crt/sec_api/wchar
Ok. Pease go ahead-
Thanks,
Kai
2017-12-15 22:30 GMT+01:00 Martin Storsjö :
> This was added at the same time as a bunch of non-empty headers
> (and a non-empty dxgi1_6.idl) in aa6ab47929a9cac6897f38e630ce0bb88458e288;
> this empty header seems to have been the result of an error.
>
> Signed-off-
Hello Martin,
patch is ok. Please go ahead and commit, if Jacek has no objections.
Thanks,
Kai
2017-11-28 8:41 GMT+01:00 Martin Storsjö :
> This is necessary for msvcrt.dll on x86_64 (and arm and arm64) and
> msvcr80.dll on x86_64.
>
> This fixes building for x86_64 with msvcrt.dll since
> 9a2f
Martin,
patch looks ok. Be careful about the static symbol in custom section
that it is actually present in a finally linked version. Sometimes
gcc thinks ... that it can optimize away such static symbols. I had
to introduce for that dummy references to such symbols in the past.
See crt/* folde
2017-11-21 11:36 GMT+01:00 Martin Storsjö :
> On Tue, 21 Nov 2017, Martin Storsjö wrote:
>
>> On Tue, 21 Nov 2017, Kai Tietz via Mingw-w64-public wrote:
>>
>>> Hi,
>>>
>>> Why was 'DllGetVersion' removed? Otherwise patch is ok.
>>
&
0644
> --- a/mingw-w64-crt/lib64/shlwapi.def
> +++ b/mingw-w64-crt/lib-common/shlwapi.def
> @@ -1,7 +1,7 @@
> ;
> ; Definition file of SHLWAPI.dll
> ; Automatic generated by gendef
> -; written by Kai Tietz 2008
> +; written by Kai Tietz 2008-2014
> ;
>
Patch is ok. Please go ahead and apply.
Thanks,
Kai
2017-11-21 9:14 GMT+01:00 Martin Storsjö :
> GCC throws an error when faced with "static static", while clang
> handles it fine.
>
> _mingw_mac.h defines __mingw_static_ovr to be a version of __mingw_ovr
> that always is static (the normal __min
Hmm, I am not sure that this will actually fix just llvm, but break
everything else.
We provide the Interloced API as inline functions/builtins on gcc. So
we don't want those symbols to be exported, as we want to use our own
version instead. The reasoning is that such builtins might be
optimizab
Patch is Ok.
Thanks
Kai
2017-11-10 10:03 GMT+01:00 Martin Storsjö :
> Some object files in the crt build were previously built with _CRTBLD,
> but not all of them. This lead to these wrappers not defining the
> unprefixed function (since that would cause warnings about mismatched
> dllimport attr
Patch looks ok to me. Jacek any comments?
Thanks
Kai
Am 10.11.2017 21:50 schrieb "Martin Storsjö" :
The CRT parts (especially libmingwex) can't be built with
__MSVCRT_VERSION__=0x1400, so force it to the intended version
there.
Signed-off-by: Martin Storsjö
---
Updated to take a library name a
I am not really the best person to review automake stuff. but for me patch
seems fine. If there are no objections, go ahead and apply.
Thanks
Kai
Am 10.11.2017 21:50 schrieb "Martin Storsjö" :
Install the import library for msvcrt.dll under the name libmsvcrt-os.a,
and install the one that is c
Hmm, I am not really good at choosing nice names. But well, I would
vote for something like libmsvcrt_os.a
Cheers
Kai
2017-11-09 22:42 GMT+01:00 Martin Storsjö :
> On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote:
>
>> Hmm, I would prefer to have a configure option. But neve
Hmm, I would prefer to have a configure option. But nevertheless all libraries
should be built regardless to this configure option, but under separate unique
names. The configure option should just decide, which msvc*/ucrt
library version should be copied as libmsvcrt.a library.
2017-11-09 15:59 G
Patch looks better now. Please go ahead.
Thanks,
Kai
2017-11-09 11:02 GMT+01:00 Martin Storsjö :
> In msvcrt.dll, it only existed on i386. In the numbered msvcr* DLLs,
> it was present in all of them except msvcr80.dll for x86_64.
>
> Define __argv to use __p___argv().
>
> This makes sure that co
Hmm, C99 support is pretty important for the gnu world. Nevertheless
patch ok. Please go ahead.
Thanks,
Kai
2017-11-09 10:04 GMT+01:00 Martin Storsjö :
> When __USE_MINGW_ANSI_STDIO is defined, we still call the custom
> implementation bundled in libmingwex. (Redirecting this case
> to use the u
Patch ok. Please go ahead.
Thanks,
Kai
2017-11-09 10:01 GMT+01:00 Martin Storsjö :
> Prior to unification of msvcrt.def.in, neither 32 or 64 bit x86
> did export this function. In practice, they seem to have existed
> since Vista.
>
> At this point, msvcrt.def.in should preprocess into the exact
Patch ok. Please go ahead.
Thanks,
Kai
2017-11-09 9:59 GMT+01:00 Martin Storsjö :
> Not all the variables that were listed seem to be exported from
> ucrtbase though, so only hook up those that do exist.
>
> Signed-off-by: Martin Storsjö
> ---
> This was approved previously by JonY, but is rebas
Patch ok. Please go ahead.
Thanks,
Kai
2017-11-09 9:59 GMT+01:00 Martin Storsjö :
> This is in preparation for redefining these declarations for ucrtbase.
>
> Signed-off-by: Martin Storsjö
> ---
> I don't think anyone actually has commented on this one yet, but it's
> a prerequisite for the patc
2017-11-09 9:18 GMT+01:00 Martin Storsjö :
> On Thu, 9 Nov 2017, Jacek Caban wrote:
>
>> On 08.11.2017 23:19, Martin Storsjö wrote:
>>>
>>> - Fix getopt by using __p___argv there instead of __argv, as Jacek
>>> suggested. In order to do this, I ended up cleaning up a few other
>>> inconsistenci
Patch is okay. Please go ahead ans commit.
Thanks
Kai
Am 07.11.2017 08:42 schrieb "Martin Storsjö" :
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-headers/crt/_mingw_mac.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/mingw-w64-headers/crt/_mingw_mac.h b/mingw-w64-headers/cr
Patch is okay. Please commit.
Thanks
Kai
Am 07.11.2017 08:42 schrieb "Martin Storsjö" :
> On Tue, 7 Nov 2017, Martell Malone wrote:
>
> ping. :)
>> I think this is being lost between all the different patches being
>> submitted atm.
>>
>
> The patch looks good to me although I'm not very familiar
Hello Martin,
The patch is ok. Please go ahead and apply.
JonY, Adrien do we have on web-server documentation about our special
configure options? I think it might be time to create such a
page/document. What do you think?
Thanks,
Kai
2017-11-03 10:06 GMT+01:00 Martin Storsjö :
> Signed-off
Thanks for the patch. If test passes, patch is ok to apply.
Thanks,
Kai
2017-10-26 14:51 GMT+02:00 Liu Hao :
> On 2017/10/26 19:53, sisyph...@optusnet.com.au wrote:
>>
>> -Original Message- From: JonY via Mingw-w64-public
>> Sent: Thursday, October 26, 2017 10:03 PM
>> To: mingw-w64-publ
Hello,
I am not quite sure if this is a Windows bug. The API you are using
is actually that one from msvcrt.dll for large/none-large file
accesses.
The most common issue showing this behavior is the TEXT vs. BINARY
file open mode on Windows C-runtime. New-lines might be expanded to
carriage-retu
Hello JonY,
the winpthread patch is ok. But I have to agree that this
"fallthrough feature" of gcc is more or less pretty bad ...
Regards,
Kai
2017-10-06 15:52 GMT+02:00 JonY via Mingw-w64-public
:
> Patches OK?
>
>
> -
Hi,
sorry for the late reply. I hope you already pushed it. For
completeness: there are no objections from my POV.
Thanks,
Kai
2017-09-13 10:40 GMT+02:00 Martin Storsjö :
> On Mon, 11 Sep 2017, Martin Storsjö wrote:
>
>> On Mon, 11 Sep 2017, Jacek Caban wrote:
>>
>>> Hi Martin,
>>>
>>> On 11.09
Well, I don't think it is necessary to provide them.
Thanks,
Kai
2017-08-21 15:00 GMT+02:00 Martin Storsjö :
> Hi,
>
> On Mon, 21 Aug 2017, Kai Tietz via Mingw-w64-public wrote:
>
>> Hello,
>>
>> I am not sure, if we might have users depending on those ordi
21 up to 27 are ok. Please go ahead and apply to master.
Thanks,
Kai
2017-08-17 14:14 GMT+02:00 Martin Storsjö :
> Where in doubt, where there were non-obvious differences between
> the lib32 and lib64 versions, I've kept the definitions separate
> instead of trying to unify them too much. (This
e of RPCRT4.dll
> -; Automatic generated by gendef
> -; written by Kai Tietz 2008
> -;
> LIBRARY "RPCRT4.dll"
> EXPORTS
> CreateProxyFromTypeInfo
> CreateStubFromTypeInfo
> I_RpcFixTransferSyntax
> +I_RpcBindingInqCurrentModifiedId
> I_RpcF
t.def
> @@ -1,8 +1,3 @@
> -;
> -; Definition file of bcrypt.dll
> -; Automatic generated by gendef
> -; written by Kai Tietz 2008
> -;
> LIBRARY "bcrypt.dll"
> EXPORTS
> BCryptAddContextFunction
> @@ -12,6 +7,7 @@ BCryptConfigureContext
> BCryptCon
ingw-w64-crt/lib64/clbcatq.def
> b/mingw-w64-crt/lib-common/clbcatq.def.in
> similarity index 73%
> rename from mingw-w64-crt/lib64/clbcatq.def
> rename to mingw-w64-crt/lib-common/clbcatq.def.in
> index a50196e..78b6981 100644
> --- a/mingw-w64-crt/lib64/clbcatq.def
> +++ b/mingw
/libarm32/crypt32.def
> +++ b/mingw-w64-crt/lib-common/crypt32.def
> @@ -1,21 +1,9 @@
> -;
> -; Definition file of CRYPT32.dll
> -; Automatic generated by gendef
> -; written by Kai Tietz 2008-2014
> -;
> LIBRARY "CRYPT32.dll"
> EXPORTS
> -ord_1001 @1001
> -o
Hello,
patch is ok. Please go ahead and apply.
Thanks,
Kai
2017-08-17 14:14 GMT+02:00 Martin Storsjö :
> Previously, we didn't actually ever include the def file in this library.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/Makefile.am | 3 +++
> mingw-w64-crt/lib32/Makefil
2017-08-09 15:11 GMT+02:00 Martell Malone :
>>
>> Just out of curiosity - the 800 def files that only are available for
>> x86_64 but not for i686, are they something that somebody practically care
>> about? Should we try to add them to i686 as well (given that they probably
>> actually exist there
2017-08-09 14:34 GMT+02:00 Jacek Caban :
> On 08.08.2017 22:32, Martin Storsjö wrote:
>> The libarm64 directory is a copy of libarm32 with minimal modifications
>> (renamings in the *.mri scripts and in Makefile.am).
>
>
> In that case I don't think we should have actual copies of every single
> .d
Hmm,
is there a chance that this source file is used for none ARM? If so,
we should reject this on top, as other targets (the exisiting ones)
are already providing this function.
Otherwise patch looks ok for me too.
Regards,
Kai
2017-08-03 0:48 GMT+02:00 JonY via Mingw-w64-public
:
> On 07/30/
Hello Hugo,
Hmm, I am not that convinced that this patch is ok. Why is just W4MO
a general import? Are you sure that in App mode this function has be
present too? Do you have some pointers for this?
Regards,
Kai
2017-07-10 17:06 GMT+02:00 Hugo Beauzée-Luyssen :
> On Tue, Jun 27, 2017, at 05:44
ter mark_section_writable, we have a mixture of XRW and
>>> X/COW pages, then in restore_modified_sections, VirtualQuery is given
>>> a truncated region that corresponds to only the first stretch of XRW
>>> pages, terminating at the first X/COW page. And
>>>
Hello,
Well, we could provide this prototype for x64 too. Not sure why we
are not doing this already.
Regards,
Kai
2017-06-16 16:14 GMT+02:00 :
> Hello,
>
> I'm trying to compile Gcc-7.0.1 and mingw-w64-5.0.2 in 64bits, using MSYS.
>
> I would like to enable the libsanitizer support, but one o
2017-06-22 18:41 GMT+02:00 Lev Serebryakov :
> On 22.06.2017 16:17, Kai Tietz via Mingw-w64-public wrote:
>
>> Be welcome. Well, actually gcc has one paragraph about this. You can
>> find it in gcc's extend.texi. It is part of the item 'format
>> (@var{archetype
Hello Jacek,
patch is ok.
Thanks,
Kai
2017-06-19 18:16 GMT+02:00 Jacek Caban :
> Please review.
>
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-headers/Makefile.am| 1 +
> mingw-w64-headers/tlb/oleacc.idl | 382
> +++
> 2 files changed, 383 insertions
2017-06-22 14:19 GMT+02:00 Lev Serebryakov :
> On 22.06.2017 15:12, Kai Tietz via Mingw-w64-public wrote:
>
>> Well, your issue is "(format (printf, ... )". First use __printf, or
>> even better __printf__. Nevertheless the printf formatter is
>> representing
2017-06-20 3:52 GMT+02:00 Liu Hao :
> On 2017/6/20 1:40, Jacek Caban wrote:
>>
>> Please review.
>>
>> Signed-off-by: Jacek Caban
>> ---
>> mingw-w64-headers/include/strsafe.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
> We might have to test this patch with different `-std
2017-06-22 13:39 GMT+02:00 Lev Serebryakov :
> Hello Liu,
>
> Thursday, June 22, 2017, 4:46:33 AM, you wrote:
>
So, I need to printf() uint64_t in my project, which is built in strict
ISO C11 mode and with all warnings enabled.
>>>
If I try to use "%llu" I get warning that "unkno
2017-06-22 4:53 GMT+02:00 :
> -Original Message- From: Liu Hao
> Sent: Thursday, June 22, 2017 11:46 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit
> compiler in strict ISO mode with all warnings enabled?
>
>>> S
I agree that - if we want to increase default windows version - we
should bump our default to Windows 7. Windows Vista is already on the
way to die ...
Nevertheless, IMHO we should do that increase just for our master.
Regards,
Kai
2017-06-04 1:33 GMT+02:00 Martell Malone :
> Thanks for that clar
Well,
the inline variant seems fine to me. I would prefer to have here
instead an implementation file. As later allows us to provide such a
function from import-library too.
Cheers,
Kai
2017-06-04 2:10 GMT+02:00 Martell Malone :
> Following up with an initial patch
> Not sure if this is ideal
Hello,
yes, everybody seems to get such a mail for the subscribed sf public
mailing lists. SF changed describes the reasoning at
https://sourceforge.net/blog/sourceforge-project-e-mail-policy-update/
for further information.
Regards,
Kai
2017-06-09 7:26 GMT+02:00 LRN :
> On 6/9/2017 6:13 AM, K.
Mixing C++ from different compilers is one of the ultimate adventurous
roads to go. Nevertheless you can still share C API instead.
Anyway, if you want to use mingw-w64 together with VS, I would
recomment to switch to Clang for mingw-w64 (llvm). It is capable to
produce mostly compatible C++ code
Jacek,
thanks for fixing this. Please go ahead, and apply.
Cheers,
Kai
2017-05-29 22:01 GMT+02:00 Jacek Caban :
> Hi David,
>
>
> Good catch, thanks. I sent a fixed version.
>
>
> Jacek
>
>
>
> On 5/29/17 9:56 PM, David Grayson wrote:
>>
>> The boolean logic in the patch looks wrong to me. You
2017-05-17 16:25 GMT+02:00 David Grayson :
> On Wed, May 17, 2017 at 4:10 AM, Kai Tietz wrote:
>> The best solution would be something like to include
>> driverspecs.h in specstring.h only, if user intends to use ddk.
>
> Is that how the real DDK works? When you don'
if we do change mingw-w64, I can revert your change in my builds,
>> and that works too, and it's just as easy as getting other toolchain
>> builders to run the sed command. If we do change mingw-w64, what
>> would be the timeline for reverting that change? Would we w
Hello,
I dislike such a change. As if somebody wants to driverspec.h, op
will need these symbols defined. Otherwise build will badly fail.
So this brings us back to the reasoning of this ... adding to
specstrings.h the include of driverspecs.h. IMHO this shouldn't be
done always. The best solu
> underscore to their names or something like that. In the long term, that
> would be nicer, because then users can have Microsoft-style code and
> libstdc++ code used in the same translation unit and they don't have to
> remember to use a guard on the include.
>
> --David
&g
Yes, that is a bit annoying ... sadly we can't do much about it.
So I would suggest to add a guard to the include, so that it is
user-defined, if this header should be included, or not.
This might be a work-a-round for this, which should work for most.
Regards,
Kai
2017-05-11 15:51 GMT+02:00 Dav
Hmm, where is the corresponding pop_macro pragma?
Regards,
Kai
2017-05-11 14:09 GMT+02:00 Martell Malone :
>>
>> While it's not "good form" to have the prototype
>> in multiple places...
>
> Attached updated diff
>
> Please Review
>
> diff --git a/mingw-w64-crt/intrincs/rdtsc.c b/mingw-w64-crt/in
ok, please apply.
Thanks,
Kai
2017-05-08 12:19 GMT+02:00 Liu Hao :
> On 2017/5/3 15:35, Christer Solskogen wrote:
>>
>> I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
>> with gcc 7.1.
>> (... abridgement ...)
>> src/.libs/libwinpthread_la-clock.o:clock.c:(.text+0x270): und
I think, it is worth a try. In general it looks sensible.
Kai
2017-05-02 11:56 GMT+02:00 Liu Hao :
> Kai, did you mean this patch was ok for master?
>
> --
> Best regards,
> LH_Mouse
>
>
> --
> Check out the vibrant tech
Ok, thanks for trying to get the reasoning, why we didn't marked it as
selectany. So I think it is time to add this selectany to our master,
and see if we get really any issues reported for it.
The only scenario I am concerned about is user-defined, library
defined. As prototypes are changing, an
2017-04-07 17:21 GMT+02:00 David Grayson :
>> type1 *foo(const type1 *my_const_ptr)
>> {
>> union {
>> type1 *t1;
>> const type1 *ct1;
>> } v;
>> v.ct1 = my_const_ptr;
>> return v.t1;
>> }
>
> Yes, that is sad, and it seems like just a matter of time before a C++
> compiler looks at the code ab
Patch is ok. Please apply.
Thanks,
Kai
2017-04-07 14:06 GMT+02:00 Jacek Caban :
> Please review.
>
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-headers/include/winnt.h | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
>
>
> -
2017-04-06 15:06 GMT+02:00 Liu Hao :
> On 2017/4/6 20:47, Kai Tietz wrote:
>> True. The reason why we prefer such patter is that it works in both
>> languages as desired. Otherwise we would be in need to write
>> different variants for the languages C/C++. This looks back
2017-04-06 14:47 GMT+02:00 Kai Tietz :
> 2017-04-06 13:38 GMT+02:00 Norbert Pfeiler
> :
>> I’m pretty sure that cast via union is UB in C++ whereas C-style casting
>> away constness isn’t (only writing to the resulting object would be) but it
>> may result in compilers issu
r C,
or C++ doing const casts.
Cheers,
Kai
> Kai Tietz schrieb am Do., 6. Apr. 2017 um
> 11:50 Uhr:
>
>> A cast via union looks like this:
>> type1 *foo(const type1 *my_const_ptr)
>> {
>> union {
>> type1 *t1;
>> const type1 *ct1;
>> } v;
&
A cast via union looks like this:
type1 *foo(const type1 *my_const_ptr)
{
union {
type1 *t1;
const type1 *ct1;
} v;
v.ct1 = my_const_ptr;
return v.t1;
}
The advantage of such a pattern is that no type conversion
errors/warnings are shown. So for casting from const to none-const,
this variant
t; 2.12.1
>
>
> -- Original Message --
> Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and
> ua_wcsrchr returns to wchar_t *
> Date: Wed, 5 Apr 2017 14:26:50 +0200
> To: Mingw-w64-public
> From: Kai Tietz
>> Hello Mateusz,
>>
>>
Hello Mateusz,
could you please re-attach, or simply inline patch to this mail?
Thanks in advance,
Kai
2017-04-05 14:08 GMT+02:00 Mateusz Mikuła :
> Ping, looks like it slipped unnoticed.
>
>
>
>
> -- Original Message --
> Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns
Ok for master.
Thanks,
Kai
2017-03-17 5:06 GMT+01:00 Liu Hao :
> On 2017/3/17 11:09, David Grayson wrote:
>> Here is that patch again. Thanks!
> These new prototypes match
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms647464.aspx ,
> so I think it is ok to apply, no?
>
> --
> Best
Hello,
If you want to solve this, you will need to use the large Code model.
Cheers,
Kai
Am 15.02.2017 06:43 schrieb "Roger Pack" :
> On 2/8/17, Ricardo Constantino wrote:
> > On 8 February 2017 at 02:55, Liu Hao wrote:
> >
> >> On 2017/2/8 1:45, Ricardo Constantino wrote:
> >> > Should be fi
Hello,
First "-Os" is indeed optimization for "size", not for "speed". But
well, later is sometimes true too. At least for programs benefiting
from cpu cache. :)
2017-03-15 4:06 GMT+01:00 Riot :
> Thanks for the detailed response Ruben, I appreciate it.
>
> We do use gold on Linux and perhaps t
Hello Kelvin,
I agree that this API is pretty useful, but it nothing we want to add
this way to our standard libraries.
Could could place it to our library section instead. It would be a
failure to add it by default to our crt,
as those symbols easily conflict with user code.
Regards,
Kai
2017-
Patch is ok for apply.
Thanks,
Kai
2017-03-08 12:29 GMT+01:00 Jacek Caban :
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-headers/include/objidlbase.idl | 6 ++
> 1 file changed, 6 insertions(+)
>
>
>
> --
> Announ
Ok, please apply.
Thanks, Kai
2017-03-08 12:29 GMT+01:00 Jacek Caban :
> Signed-off-by: Jacek Caban
> ---
> mingw-w64-crt/libsrc/uuid.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
>
> --
> Announcing the Oxford Dictiona
Not sure, if this new export was already added. If not, prepare a
patch, and send it to ML.
Regards,
Kai
2017-02-19 17:17 GMT+01:00 Ruslan Garipov :
> Hello!
>
> File 'mingw-w64-v5.0.1/mingw-w64-crt/lib32/user32.def' has exporting
> declaration of function [ChangeWindowMessageFilterEx][1], but f
1 - 100 of 1577 matches
Mail list logo
