On 8/16/2016 5:51 AM, Jacek Caban wrote:
On 16.08.2016 14:14, dw wrote:
cpp_quote("#define MAKE_DXGI_HRESULT(x)MAKE_HRESULT(1,
_FACDXGI, x)")
+cpp_quote("")
+cpp_quote("/* These defines are (incorrectly) duplicated in winerror.h. Avoid
the&
On 8/16/2016 4:34 AM, Martin Storsjö wrote:
> On Tue, 16 Aug 2016, dw wrote:
>
>> Attempting to follow Martin's suggestions, I'm attaching the next three (I
>> *think* this is the organization he requested). Ok to push?
> uchar.patch and ntsecapi.patch are ok wit
On 8/16/2016 4:16 AM, Jacek Caban wrote:
On 16.08.2016 12:50, dw wrote:
--- a/mingw-w64-headers/include/mfidl.h
+++ b/mingw-w64-headers/include/mfidl.h
This file is auto generated. You should not touch it, please change .idl
file instead.
Strictly speaking, I believe the (duplicate
gs in ntsecapi.h.
- These redefine values that are unconditionally defined earlier in
the same file.
dw
diff --git a/mingw-w64-crt/crt/gs_support.c b/mingw-w64-crt/crt/gs_support.c
index dbd95d5..f47b0fe 100644
--- a/mingw-w64-crt/crt/gs_support.c
+++ b/mingw-w64-crt/crt/gs_support.c
@@ -26,7 +
t please wait for at least somebody else
to comment on it as well.
Are you not authorized to approve patches? Who should I be looking for
email from then? Or is there something about this particular patch that
requires a closer look?
dw
diff --git a/mingw-w64-crt/complex/clog10.c b/ming
so we can find them.
Sure
Attached. Ok to push?
dw
diff --git a/mingw-w64-crt/complex/clog10.c b/mingw-w64-crt/complex/clog10.c
index f8545cd..8553e00 100644
--- a/mingw-w64-crt/complex/clog10.c
+++ b/mingw-w64-crt/complex/clog10.c
@@ -44,5 +44,6 @@
/* double version of the functions
On 8/14/2016 9:23 AM, NightStrike wrote:
> On Sun, Aug 14, 2016 at 9:02 AM, Martin Storsjö wrote:
>> On Sat, 13 Aug 2016, dw wrote:
>>
>>> I still have some more fixes for ARM, but this patch is getting too
>>> big.
>>> This is a logical point to b
extern (implying that the actual definition
is elsewhere), since the code also initializes the variable. And
we don't need 'extern "C"' since this entire section is already
wrapped with one. Using both 'extern' and initializing generates
a warning.
ntd
old that "autoreconf -fiv" regenerates all the files using
the current version. But after seeing the dozen files it changed and
realizing I didn't actually know what any of them were, I chickened out.
If there's something I can do to help, let me know.
dw
-
Hopefully someone who knows more about this stuff than I do can check in
the 'right' fix to get things back in sync.
dw
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
pattern
onfigured by
someone who knows the mingw-w64-public list password.
So, with any luck at all, my 4 (renamed) patches will be attached to
this email.
dw
On 8/8/2016 4:06 PM, David Wohlferd wrote:
By request, I am re-sending 4 recent patches. These fix a number of
issues (see below). I am hop
I see SF ate my attachment again. As a reminder, warn1.patch is
available at http://www.limegreensocks.com/mingw-w64/Home.html.
Other comments inline.
dw
On 8/8/2016 6:07 AM, Martin Storsjö wrote:
> On Mon, 8 Aug 2016, dw wrote:
>
>> Q3: ARM is giving a bunch of warnings
LargeAddressAware
(https://msdn.microsoft.com/en-us/library/wz223b1z.aspx) "tells the
linker that the application can handle addresses larger than 2
gigabytes." For 64bit applications, that's kind of a given.
Are you having some specific issue?
dw
On 8/3/2016 12:05 AM, Datta
we
don't need 'extern "C"' since this entire section is already wrapped
with one. Using both 'extern' and initializing generates a warning.
ntdef.h:
* Redefine errors.
ntsecapi.h:
* These redefine values that are unconditionally defined earlier in
the
On 7/23/2016 3:15 AM, André Hentschel wrote:
> Am 23.07.2016 um 01:15 schrieb dw:
> I currently have no perfect setup, but Martell Malone wanted to clean
> everything up and even upload builds to sf.net
> While doing this he spotted some strange issues which only happened on linux,
On 7/27/2016 6:40 PM, dw wrote:
> I've gotten a couple of binutils to build, but I'm not 100% certain
> they are correct. Should armv7-w64-ming32 support CFI? Windows is a
> COFF system, and CFI is normally associated with ELF. However
> compiling C programs with i686-w
On 7/27/2016 1:50 PM, Jim Michaels wrote:
> On 7/26/2016 12:21 PM, André Hentschel wrote:
>> Am 25.07.2016 um 12:21 schrieb dw:
>>> Thank you for the link, I was not aware of this. I'm using Msys2, so
>>> the linux issues should not affect me.
>>>
>>
to git a 3
year old version of gcc (~215509) instead? Would -e prevent makepkg
from trying to update it?
My end goal here is to test a mingw-w64 source code change to make sure
I'm not breaking ARM builds.
I gotta wonder: How do other people do ARM builds?
dw
On 7/23/2016 3:15 AM, Andr
re params did you use for mingw-w64 build?
Any advice from someone who got this working would be helpful.
dw
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level.
e of you long-time mingw-w64 experts can
provide some guidance here.
But if the existing code doesn't do this detection (and if no one is
objecting), maybe the answer here is to just accept that the project is
defined for specific compilers. Trying to make mingw-w64 generic enough
to com
annot use more
than one __try1 in a function. Using ".text" causes problems with some
build options (-ffunction-sections). Using ".seh_code" should resolve
this, but requires a fairly new gas
(https://sourceware.org/ml/binutils/2014-03/msg00260.html).
That's my exp
On 7/7/2016 4:49 PM, Ozkan Sezer wrote:
> On 7/8/16, dw wrote:
>> In any case, did you have a chance to look at the patch?
> Unfortunately no. Kai would be the guy for reviewing asm stuff.
Ok then. I hope he has the time.
How about the .c files? They become pretty simple after t
he list.
In any case, did you have a chance to look at the patch?
dw
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech lu
On 7/7/2016 6:45 AM, Ozkan Sezer wrote:
On 7/7/16, dw wrote:
I was looking to see if there was any more inline asm that could be
removed from mingw-w64. That brought me to vsscanf (and friends). This
looked to be a messy bit of code that could probably use a review.
As I started looking
ts and advice are welcome. Remember to regen Makefile.in if you
want to build this.
dw
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tec
bt $0, %ebx
jc .L5 <----- Use the flags directly
leaq.LC1(%rip), %rcx
callprintf
dw
commit 527ef2be12fefe658cdf9a43fdc69601d005057c
Author: David Wohlferd
Date: Tue Nov 17 13:13:30 2015 -0800
Support gcc 6 flag constraints
Signed-off-b
the #undef's if we see that
the buggy version of x86intrin.h was included. Otherwise, we leave
x86intrin's definitions there in case intrin.h is never included.
Hope this helps explain my thinking here. If I have missed something,
please let me know.
dw
On 2/21/2015 12:03 PM, dw wro
rotl always returns the same result is the better plan.
There may be circumstances I haven't considered that would change my
mind, but currently I see no reason to change this patch.
dw
On Wed, Feb 11, 2015 at 9:56 AM, dw <mailto:limegreenso...@yahoo.com>> wrote:
I w
ings, but that just leads to
conflicts with other headers and undefined symbols.
Comments? Suggestions? Or can we finally call this done?
dw
>From d11d4e0560e9c086d9b8d85005bee28a1a0de787 Mon Sep 17 00:00:00 2001
From: David Wohlferd
Date: Wed, 11 Feb 2015 01:20:30 -0800
Subject: [PATCH] S
7;s memory
regions so it can write to them suggests this may be what you are
looking for.
dw
On 2/9/2015 11:06 PM, niXman wrote:
> niXman 2015-02-09 15:15:
>> Hi,
>>
>> I use VMProtect[1] in a project that I build using MinGW-W64.
>> VMProtect, among other things, provides
's, but does that make any sense at all?
If mingw-w64's stdlib.h doesn't need to support 8 byte longs, this patch
gets much easier. But if it does, what's the approach to test it?
dw
--
Dive into the
I'm told *is* a supported scenario), the
attached patch should help.
dw
>From f5ab3539141364be67ab27ec9393fa6fdb3faf09 Mon Sep 17 00:00:00 2001
From: David Wohlferd
Date: Thu, 4 Dec 2014 17:46:56 -0800
Subject: [PATCH] Resolve problem where clang doesn't support %z in asm
templates.
S
ute. And
ffd.dwReserved0 shows IO_REPARSE_TAG_SYMLINK.
FWIW.
dw
On 1/14/2015 9:33 AM, Greg Jung wrote:
Hi Folks,
I've been trying to program a recognition of NTFS symbolic link
files; What I;ve gleaned
from MSDN procedures don't seem to work. Below are coded three methods
1)
were asking for, but perhaps it can give you
what you need?
dw
On 12/5/2014 2:26 PM, bulk 88 wrote:
> Date: Fri, 5 Dec 2014 09:49:55 +0100
> From: ktiet...@googlemail.com
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] adding dos stub program with ld
luding the file name, that's less than 30 bytes.
Room to spare. So now when my32bitapp.exe is run, it turns around and
launches 16.exe. Tada!
dw
On 12/5/2014 2:26 PM, bulk 88 wrote:
> Date: Fri, 5 Dec 2014 09:49:55 +0100
> From: ktiet...@googlemail.com
> To: mingw-w64-public@li
program). Probably makes sense to
leave this alone. Not sure what the 16byte thing is, but it doesn't
seem to be cumulative, so I'm not much motivated to seek it out.
dw
On 10/31/2014 11:27 PM, lh_mouse wrote:
> I have applied the patch and here are
x27;s not much of a leak, and the memory can't be freed until
application shutdown (or possibly at dll unload time) since it is used
right up until the last minute.
dw
>From e9adda2479244cbf3681c379b2573362eace6308 Mon Sep 17 00:00:00 2001
From: David Wohlferd
Date: Fri, 31 Oct 2014
> Ups, that was unintended to send an empty mail :)
I did wonder. I assumed it was just a ping.
> So, here is a patch.
Your patch does not look right. You have added the new checks using "||"?
> It would be great if somebody could verify that the reported
> issue is solved by it.
Yes, this
ght end up in different sections, please feel free to
enlighten me.
dw
On 8/19/2014 1:02 PM, Vadim Chugunov wrote:
No, sorry, I don't have the setup to build mingw. Not likely that I
will have time to do it any time soon either.
I meant this as a bug report. I hope the problem has bee
On 9/20/2014 8:07 AM, André Hentschel wrote:
> Am 19.09.2014 um 17:30 schrieb Kai Tietz:
>> 2014-09-19 1:34 GMT+02:00 dw :
>>> For the parts that are "working around a compiler bug":
>>>
>>> - Does it make sense to list the bug number in the commen
For the parts that are "working around a compiler bug":
- Does it make sense to list the bug number in the comment?
- If the bug has been fixed, what about using __GNUC__ and
__GNUC_MINOR__ to limit the code?
dw
On 9/18/2014 3:23 PM, André Hentschel wrote:
Please review, i&#x
Well, I've done what I can to diagnose this. It's up to the mingw devs
from here.
dw
On 8/19/2014 1:04 PM, Vadim Chugunov wrote:
No, sorry, I don't have the setup to build mingw. Not likely that I
will have time to do it any time soon either.
I meant this as a bug report. I h
it anyway.
Also, this code snippet only fixes 2 of the 3 places that use
PAGE_EXECUTE_WRITECOPY. Remember to change the comparison in
mark_section_writable() as well.
FWIW,
dw
On 8/15/2014 8:17 PM, Vadim Chugunov wrote:
Okay, I was wrong about __MINGW64_VERSION_MAJOR: it *was* defined.
ense to do this incrementally, but
perhaps I should have gone straight to the final answer. This patch
adds _lrotl/_lrotr to intrin-impl instead of just fixing the
prototypes. Shouldn't be any surprises. Note that this is a
replacement for the other patch, not in addition to.
dw
diff --git
On 7/26/2014 9:29 AM, JonY wrote:
> On 7/26/2014 22:39, Ozkan Sezer wrote:
>> On 7/26/14, dw wrote:
>>> Well, since no one else has responded, what would you say to this
>>> (attached)?
>>>
>>> If you like, I can write up a detailed description about
LLP64.
If this is approved, someone else will have to commit it. git is not my
thing.
dw
On 7/20/2014 2:18 AM, Ozkan Sezer wrote:
Regarding gcc PR target/61662:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662
http://gcc.gnu.org/viewcvs/gcc?view=revision&sortby=date&revision=212826
heory it could get freed in ___w64_mingwthr_remove_key_dtor (at
least there is a free for it there), but apparently that routine never
gets called.
Maybe it was supposed to be freed in __mingwthr_run_key_dtors when it
gets called?
dw
---
A few thoughts:
1) Shouldn't global_lock be __LONG32?
2) Would it make sense for the exchange on global_lock to be done as a
single operation (ie InterlockedCompareExchange)?
dw
On 12/5/2013 10:45 AM, Fanael Linithien wrote:
I came up with a patch that fixes the issue for me.
The
Are you setting the dwLength member to the size of the structure?
dw
On 11/17/2013 1:18 AM, niXman wrote:
> Jim Michaels 2013-11-17 11:27:
>> it's returning failure.
>> I have even filled the MEMORYSTATUSEX struct with 0's using memset().
>> nothing about th
issues. I'll look again
if we are serious about using it.
dw
--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
F
It sounds like you are missing libmsvcr100.a
dw
On 11/13/2013 9:34 AM, André Guerreiro wrote:
Hello all,
sorry if this is a really basic question, I'm a MingW newbie.
I'm trying to build this code with Mingw-w64 4.6.3
#include
int main()
{
FILE *fp = fopen("
/man3/sem_wait.3.html> I read: "If the
timeout has already expired by the time of the call" implies that an
absolute time is being specified, not a duration. While I think your
definition is more useful, this may result in u
cumentation of msdn.
I agree. Which is exactly what I did
<http://msdn.microsoft.com/en-us/library/a0w705h5.aspx>.
To address that in x86intrin.h header
would be fine, but was rejected in the past already.
Do you have a link to the last discussion? Before I try to convin
ng time, and I haven't seen anyone
(besides me) screaming for a fix. If we needed an immediate fix, I
could see going with #2, but the cleanest (and my current preference) is
#3.
I'm prepared to write #2 or #3 (or #4 if someone has a better idea), but
before I spend the time, I&
7;s some type of issue with long vs long32. Is
sizeof(long) 32 or 64?
It might also be worth looking at the -E output. Perhaps you are
grabbing intrin.h and winbase.h from different mingw-w64 builds?
dw
--
LIMITED
ping kai.
Whatever problems there may be with intrin.h, I believe the patch in
this thread (for _lrotl) is correct and should be checked in. I'm still
waiting for your ok.
dw
On 9/15/2013 1:35 PM, dw wrote:
>> IIRC, it is included in sdk versions earlier than 7 too, e.g. the sdk
will need to be re-written. Perhaps that's
something that should wait until after v3.
At this point, I see no reason not to accept this lrotl patch.
dw
--
LIMITED TIME SALE - Full Year of Microsoft Training F
4 includes it seemed appropriate. However, if the text isn't
clear, I can re-word it.
dw
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, W
eneral comment
(incomplete how?). All that's clear is I should not commit this change
yet. I look forward to hearing details about what problems you see.
Since the next patch I want to send also updates winnt.h, I'm blocked
until we
patch like
http://pastebin.com/DsEzNxRx might be a good idea, but we still need to
deal with it in the meantime.
dw
Index: mingw-w64-headers/crt/intrin.h
===
--- mingw-w64-headers/crt/intrin.h (revision 6283)
+++ mingw-w64-headers
_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
__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:
__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
>> 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 separat
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'
d so odd that I had to ask.
If we did add some type of #define here, it would also be a good place
to document all this. I'm a big believer in capturing this kind of
knowledge, but you've got to have a place where people will find it.
dw
-
t of 127 & 129
"Removed _CRTIMP from POSIX API."
I'm no posix expert, but wouldn't creating a define using #ifdef _POSIX_
be a better solution? In addition to allowing these functions to work
optimally with ms crt, it would also implicitl
<__imp_feof>
Is this intentional? Or a bug?
I'm asking about feof, but it appears there are a bunch of functions in
stdio that don't have this (and a bunch that do). If there's a pattern
here, I don't see it.
dw
RM, I'll need more details so I can
reproduce the problem here.
This signature stuff has to stop.
dw
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is
? Apply your patch? Define BOOST_USE_WINDOWS_H?
dw
On 8/20/2013 7:46 AM, Ruben Van Boxem wrote:
2013/8/20 Alex Hultman <mailto:alexhult...@gmail.com>>
Hey!
I'm trying to figure out what libs to link with to get the
Interlocked*-API working. Google points me in th
to NOT be inline allows them to?
I used to think forcing them inline meant you couldn't take the address
of the routine, but that doesn't appear to be true?
dw
--
Get 100% visibility into Java/.NET code wit
ust remain, just let me know, and I'll
re-submit the patch with the deletes deleted.
dw
On 8/6/2013 4:23 PM, dw wrote:
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 possibl
e no #if's around it to limit it to
that platform. Note that winnt.h has inlines for x86/x64 for these.
*Files deleted from intrincs*.
dw
Index: mingw-w64-crt/intrincs/__movsb.c
===
--- mingw-w64-crt/intrincs/__movsb.c (revis
intrincs\readcr*.c.
Look at intrin-impl.h. There are several #if blocks there
- defined(__x86_64__)
- defined(__x86_64__) || (defined(_X86_)
- defined(_X86_)
The readcr* functions appear in both the __x86_64__ and _X86_ blocks
using differ
ia32intrin.h. Since a scan of the entire mingw-w64 tree didn't find any
of these functions, I just assumed it was using msvcr*.dll for
everything. Hopefully I'm making more sense this time.
dw
--
Get your SQL d
Jacek, while I have checked in this patch so that I could continue work,
I would still be interested in any comments you might have on this.
dw
On 8/2/2013 12:12 AM, Kai Tietz wrote:
> Jacek, do you have any objections about that pa
, int _Shift);
Note that mingw-w64-headers\crt\stdlib.h and
mingw-w64-headers\include\winnt.h do the same thing.
dw
--
Get your SQL database under version control now!
Version control is standard for application code, but d
> Comments, flames, or questions?
I like this idea too.
dw
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can
c) Several changes to inputs, outputs, constraints and clobbers.
d) Use macros & symbolic names.
e) Support both att and intel asm formats.
dw
Index: mingw-w64-crt/intrincs/bittest.c
===
--- mingw-w64-crt/intrincs/bittest.c
Minor tweaks to bring defs in line with MS.
dw
Index: winnt.h
===
--- winnt.h (revision 5973)
+++ winnt.h (working copy)
@@ -1620,7 +1620,7 @@
#else
#define YieldProcessor __buildpause()
VOID MemoryBarrier(VOID);
-__CRT_INLINE
Done as 5980.
dw
On 7/23/2013 4:33 PM, dw wrote:
The patch looks good to me.
This patch requires re-building mingw-w64-crt/Makefile.in. Can
someone with the right autoconf do this checkin please? The
description should be something like:
Remove non-intrinsic function from intrinsic
,
dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of
to MSDN
<http://msdn.microsoft.com/en-us/library/ms684208%28v=VS.85%29.aspx>
It's just an macro that's defined in winnt.h. Which we already do.
The attached patch does the delete. I can create the other patch
instead if that seems like a better approach.
dw
have finally done
this. Apparently patch files don't show deletions, so the attached
patch only shows the merged content in intrin-impl.h.
dw
Index: mingw-w64-headers/include/psdk_inc/intrin-impl.h
===
--- mingw-w64-heade
#ifdef for __MINGW_INTRIN_INLINE that jacek wanted for
intrin-impl.h.
dw
Index: mingw-w64-headers/include/psdk_inc/intrin-impl.h
===
--- mingw-w64-headers/include/psdk_inc/intrin-impl.h (revision 5971)
+++ mingw-w64-headers/include
> Attached is the patch I came up with to fix the build issue.
You are checking for defined(__MINGW64_VERSION_MAJOR). Would it make
sense to do (__MINGW64_VERSION_MAJOR >= 3)?
dw
--
See everything from the brow
ally bad at.
So, who decides? If it's me, I'm probably going to wimp out and add the
defs back to avoid the conflict.
dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visi
rent set of options is a bad idea. If defining
BOOST_USE_WINDOWS_H is what's needed to work with our v3, this doesn't
seem to me like an unreasonable burden. Especially when it also gains
them performance improvements.
dw
---
's no fundamental problems with
> the changes.
While I could write the email, I'm not sure they'd listen to me. It's
not like they know who I am. Also, I've been told that my posts are
sometimes perceived as c
n't defined, is it likely
__MINGW_GNUC_PREREQ will be? Seems like we're just changing where the
compiler error occurs.
> I hope Kai is okay with it and will review it when he's back.
Kai said that in his absence, you were
prepared to add the defs back to the library if that
seems like the right thing to do. But I could use some guidance about
what the right thing to do is.
dw
--
See everything from the browser to the database wit
undefined
> by default.
Why? What problems do you envision?
> To me this looks like trading future proof solution for speed.
Since MS has omitted these functions from the x64 version of
kernel32.dll and replaced them with inline versions, I'm not clear what
future problems yo
_NO_INLINE. In fact, I removed the check for
__MINGW_INTRIN_INLINE. If that's important, then intrin-impl.h needs to
be updated as well.
I'd hope for better fallback on older (well, all currently released) GCC
versions, but I'm out of ideas now.
Between the gcc bug and people copying p
This gets us back to always_inline if we can use inlines, and uses
dllimport as a fallback.
dw
Index: mingw-w64-headers/include/winbase.h
===
--- mingw-w64-headers/include/winbase.h (revision 5955)
+++ mingw-w64-headers/include/winbase.h (wor
Ping.
These have nothing to do with the boost/Interlocked* issues.
dw
On 7/15/2013 2:37 PM, dw wrote:
1) Move these functions to intrin-impl.h:
_bittest, _bittest64
_bittestandset, _bittestandreset, _bittestandcomplement
_bittestandset64, _bittestandreset64, _bittestandcomplement64
2
for this specific issue,
it seems like we're trying to trick the compiler into doing something it
normally forbids. That seldom ends well.
I'd like to see this work. But I'm starting to lean back towards just
using the imports for x86.
dw
-
ckedExchange@8. -Os has
_InterlockedExchange@8.constprop.0 and
__imp__InterlockedExchange@8.constprop.0.
Something is getting tangled here, but I'm not quite sure what.
dw
--
See everything from the browser to the
inable/
This would work if boost didn't have their own copy of the function
prototype.
Sorry Jacek, I liked your idea of changing this to inlining.
Before we surrender, is it worth talking to the boost people? Or should
I just change this back to use the DLL?
dw
On 7/15/2013 6:26 PM
h (if he does all 6 stdcall functions) should
resolve this problem.
dw
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlene
changes to inputs, outputs, and constraints.
d) add "cc" clobber.
e) Use symbolic names.
f) Support both att and intel asm formats.
dw
Index: mingw-w64-crt/intrincs/bittest.c
===
--- mingw-w64-crt/intrincs/bittest.c(revision
1 - 100 of 149 matches
Mail list logo
