_umul128 & _mul128: Moved these intrinsics from library-only to intrin-impl.
dw
Index: mingw-w64-crt/intrincs/_mul128.c
===
--- mingw-w64-crt/intrincs/_mul128.c (revision 6265)
+++ mingw-w64-crt/intrincs/_mul128.c (working copy)
@@ -
Thanks, patch is ok. Please apply.
Thanks
Kai
Am 12.09.2013 21:01 schrieb "dw" :
> _umul128 & _mul128: Moved these intrinsics from library-only to
> intrin-impl.
>
> dw
>
>
> --
> How ServiceNow helps IT people transform
Hello dw,
Patch is ok. Please apply.
Thanks,
Kai
2013/9/11 dw :
> __shiftright128 & __shiftleft128: Re-written as asm, moved from library-only
> to intrin-impl.h.
>
> Note that the code that is being replaced would not always return the same
> results as MS's intrinsics. This patch resolves th
__shiftright128 & __shiftleft128: Re-written as asm, moved from
library-only to intrin-impl.h.
Note that the code that is being replaced would not always return the
same results as MS's intrinsics. This patch resolves this issue as well
as producing more efficient code.
dw
Index: mingw-w64-
Patch is ok.
Thanks,
Kai
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Impleme
__movsb, __movsd, __movsq, __movsw: Move these intrinsics from
library-only to intrin-impl.
dw
Index: mingw-w64-crt/intrincs/__movsb.c
===
--- mingw-w64-crt/intrincs/__movsb.c (revision 6265)
+++ mingw-w64-crt/intrincs/__movsb.c (wo
>> I agree on fixing wrong behavior of intrinsic-functions (and their
>> implementation files), but such changes please sent in separate
>> patches, so that I can review them stand-alone.
>>
> dw, can you please do that?
I'll try to parse these out into separate patches. There's some overlap
in
On 09/09/13 14:51, Kai Tietz wrote:
> Hmm? I thought I said already all I have to say to this.
Well, you gave reasons that others don't agree with so we kind of
expected you to answer to those doubts.
> 1) I see no good need to remove non-inline variant from libmingwex.a library.
> 2) If somethi
Hmm? I thought I said already all I have to say to this.
1) I see no good need to remove non-inline variant from libmingwex.a library.
2) If something isn't an intrinsic, well, then move the implementation
file out of the intrinsic-folder, but this doesn't mean we don't want
it in libmingwex.a lib
On 09/07/13 02:44, dw wrote:
>> It's a really delayed reply, dw asked me to join the conversation.
>
> Hey Jacek, thanks for you thoughts on this. However, it doesn't seem
> to have brought us to a conclusion. I've been trying to avoid
> "nagging" (something I am prone to do), especially since I'
On 09/07/13 03:20, JonY wrote:
> On 9/7/2013 08:44, dw wrote:
>> However, if that's not acceptable, perhaps there is an alternative. If
>> the requirement I'm violating here is simply that these specific
>> functions must be able to support not being inlined, then I believe
>> simply changing them
On 9/7/2013 08:44, dw wrote:
>
> However, if that's not acceptable, perhaps there is an alternative. If
> the requirement I'm violating here is simply that these specific
> functions must be able to support not being inlined, then I believe
> simply changing them from "FORCEINLINE" to "inline" wou
It's a really delayed reply, dw asked me to join the conversation.
Hey Jacek, thanks for you thoughts on this. However, it doesn't seem to
have brought us to a conclusion. I've been trying to avoid "nagging"
(something I am prone to do), especially since I've seen how busy Kai
has been with
Hi,
It's a really delayed reply, dw asked me to join the conversation.
On 08/09/13 13:07, Kai Tietz wrote:
> Hi,
>
> sorry for the delayed answer per mail.
>
> 2013/8/9 dw :
>> So, no response here, other than a few (brief) comments on irc.
>>
>> It's hard to know how to advocate for a patch when
> IMHO it has some advantages to have some of
> those functions used by static-library instead of calling into a DLL.
What DLL? None of these 5 functions are in any DLL that I can see.
> The need to add it to libmingwex is that this function isn't present
> on all supported Windoof OSes, so
Hi,
sorry for the delayed answer per mail.
2013/8/9 dw :
> So, no response here, other than a few (brief) comments on irc.
>
> It's hard to know how to advocate for a patch when I'm not sure what the
> objections are. But it seems likely that that biggest areas of concern
> aren't the changes to
So, no response here, other than a few (brief) comments on irc.
It's hard to know how to advocate for a patch when I'm not sure what the
objections are. But it seems likely that that biggest areas of concern
aren't the changes to the inline asm, but the files I'm deleting from
\intrinsc\.
W
I think this is about it for intrinsics work for v3. This patch is
(mostly) for the files in intrinsc\*.c that weren't changed by any
previous work. It's possible that not everything in this patch will get
approved, but I figure it's easier to ask forgiveness than permission.
__movsb, __movs
On 07/03/13 12:22, Kai Tietz wrote:
> 2013/7/3 Jacek Caban :
>
>> Looks good to me.
>>
>> Thanks,
>> Jacek
> Yes, patch is ok. Jacek feel free to commit.
Committed as r5924.
Thanks,
Jacek
--
This SF.net email is sponsor
2013/7/3 Jacek Caban :
> On 07/03/13 02:29, dw wrote:
>> Thanks to both Kai and Jacek whose suggestions made this patch much
>> better.
>>
>> This patch includes two parts. The first (and more important) deals
>> with how MSVC's intrinsics are used in mingw-w64:
>>
>> winnt.h:
>>
>> - In all cases
On 07/03/13 02:29, dw wrote:
> Thanks to both Kai and Jacek whose suggestions made this patch much
> better.
>
> This patch includes two parts. The first (and more important) deals
> with how MSVC's intrinsics are used in mingw-w64:
>
> winnt.h:
>
> - In all cases (x86, x64, cygwin, not cygwin), r
21 matches
Mail list logo
