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 library. Function is
available in winnt.h.
Thanks,
On 7/23/13 11:20 PM, dw wrote:
There is a compile warning coming from intrincs/membarrier.c:
/../../mingw-w64/mingw-w64-crt/intrincs/membarrier.c:4:6: warning: no
previous prototype for 'MemoryBarrier' [-Wmissing-prototypes]/
There are two ways to fix it.
1) The easy, non-controversial way i
On 7/23/13 10:53 PM, Erik van Pienbroek wrote:
> Jacek Caban schreef op ma 22-07-2013 om 11:50 [+0200]:
>> On 07/21/13 23:24, dw wrote:
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 (__MING
Hi,
There is a problem in Ruben's builds
"x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z" and
"x86_64-w64-mingw32-gcc-4.8.0-linux64_rubenvb.tar.xz". The simple code
snippet below with argument "-static -O2 -flto" can reproduce the problem:
#include
int main(){
std::cout << "Foo = " << 101 << std::e
Hello,
I have a project which requires a lot of optimizations (SIMD instructions,
OpenMP) that works for now under linux without any problem.
On the same computer under windows with Mingw64 (gcc 4.8), the performances are
worse using OpenMP than with a single thread.
I made a very simple progra
There is a compile warning coming from intrincs/membarrier.c:
/../../mingw-w64/mingw-w64-crt/intrincs/membarrier.c:4:6: warning: no
previous prototype for 'MemoryBarrier' [-Wmissing-prototypes]/
There are two ways to fix it.
1) The easy, non-controversial way is to just add the prototype to t
Jacek Caban schreef op ma 22-07-2013 om 11:50 [+0200]:
> On 07/21/13 23:24, dw wrote:
> >> 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)?
>
> IMO, if the change
Hi LRN
thank you for the heads up. Sure, it would me vety appreachiated if you
would take care for this update.
You should have commit rights. So please sent mail with attached patch,
get approval for it, and then apply.
JonY, Jacek, Ozkan, or dw can give you assistance, if you require.
Aloha
K
On 7/23/2013 20:37, Corinna Vinschen wrote:
> On Jul 23 19:49, JonY wrote:
>> On 7/23/2013 17:57, JonY wrote:
>>> On 7/23/2013 17:03, Jacek Caban wrote:
>>> Simply adding the typedefs looks to be the simplest fix. As mentioned
>>> earlier, Cygwin has its own CRT, the mingw-w64 parts are used for wi
On Jul 23 19:49, JonY wrote:
> On 7/23/2013 17:57, JonY wrote:
> > On 7/23/2013 17:03, Jacek Caban wrote:
> > Simply adding the typedefs looks to be the simplest fix. As mentioned
> > earlier, Cygwin has its own CRT, the mingw-w64 parts are used for win32
> > APIs.
> >
> >
>
> New patch attached
On Jul 23 11:03, Jacek Caban wrote:
> On 07/20/13 03:57, JonY wrote:
> > Hi,
> >
> > Cygwin errno.h does not define non-Posix errno_t, neither does Cygwin
> > stdlib.h knows about _invalid_parameter_handler.
> >
> > In theory, any Cygwin code should not be using libmsvcrt.a at all, but
> > this is
On 7/23/2013 17:57, JonY wrote:
> On 7/23/2013 17:03, Jacek Caban wrote:
>> On 07/20/13 03:57, JonY wrote:
>>> Hi,
>>>
>>> Cygwin errno.h does not define non-Posix errno_t, neither does Cygwin
>>> stdlib.h knows about _invalid_parameter_handler.
>>>
>>> In theory, any Cygwin code should not be usin
On 7/23/2013 17:03, Jacek Caban wrote:
> On 07/20/13 03:57, JonY wrote:
>> Hi,
>>
>> Cygwin errno.h does not define non-Posix errno_t, neither does Cygwin
>> stdlib.h knows about _invalid_parameter_handler.
>>
>> In theory, any Cygwin code should not be using libmsvcrt.a at all, but
>> this is curr
On 07/20/13 03:57, JonY wrote:
> Hi,
>
> Cygwin errno.h does not define non-Posix errno_t, neither does Cygwin
> stdlib.h knows about _invalid_parameter_handler.
>
> In theory, any Cygwin code should not be using libmsvcrt.a at all, but
> this is currently a stopgap measure while I investigate how
On 07/23/13 07:07, dw wrote:
> At one point jacek suggested that intrin-mac.h should be merged into
> intrin-impl.h. Intrin-impl is the only place intrin-mac is used.
> Since I had just created intrin-mac a few days before, I wasn't ready
> to delete it quite that fast.
>
> However, time has shown
15 matches
Mail list logo
