Re: [Mingw-w64-public] [PATCH 1/2] Make dnsapi.def up to date.

[Dongsheng Song]

On Thu, Feb 4, 2016 at 6:18 PM, Kai Tietz  wrote:
> Hi Dongsheng,
>
> zes, adjusting the UTF8 variant sounds to me sensible.  As it is a
> real prototype we can adjust that here AFAICS.  If there are no
> objections by other people, I am fine with that.
>
> Thanks,
> Kai
>

Since no one objected, pushed as 1113f35f39e22687f4cec4bdedd44d039ef60c4f

Thanks,
Dongsheng

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[Dongsheng Song]

If we use  --enable-threads=win32-win7 , the result gcc running on and
target to win7 or later looks reasonable.

On Thu, Apr 14, 2016 at 2:34 PM, Martin Mitáš <m...@morous.org> wrote:
>
>
> Dne 14. 4. 2016 v 5:02 Dongsheng Song napsal(a):
>> Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
>>
>> --enable-threads=win32-vista
>> --enable-threads=win32-win7   // Windows 7 and Windows Server 2008 R2
>> --enable-threads=win32-win8   // Windows 8 and Windows Server 2012
>> --enable-threads=win32-win8.1 // Windows 8.1 and Windows Server 2012 R2
>> --enable-threads=win32-win10  // Windows 10 and Windows Server 2016
>>
>> to gthr-windows.{h|c} with the corresponding _WIN32_WINNT macros ?
>
> Please don't.
>
> Consider that something like -D_WIN32_WINNT=xy -DWINVER=_WIN32_WINNT
> is often used by projects to see newer Win32API structures and #defines,
> but the project often still supports older windows in run time. A lot
> of code out there plays with GetProcAddress() but doesn't want to redefine
> all the new types and constants.
>
> Best regards,
> Martin
>
>
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[Dongsheng Song]

Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map

--enable-threads=win32-vista
--enable-threads=win32-win7   // Windows 7 and Windows Server 2008 R2
--enable-threads=win32-win8   // Windows 8 and Windows Server 2012
--enable-threads=win32-win8.1 // Windows 8.1 and Windows Server 2012 R2
--enable-threads=win32-win10  // Windows 10 and Windows Server 2016

to gthr-windows.{h|c} with the corresponding _WIN32_WINNT macros ?

Regards,
Dongsheng

On Thu, Apr 14, 2016 at 10:24 AM, lh_mouse  wrote:
> Yes I learnt those *ByAddress* functions a few months ago and was shocked 
> that Microsoft had plagiarized futex from Linux.
> As you have pointed out already, those APIs are only available on  Windows 8 
> and later.
>
> If we need fuex semantics on Windows 7 and earlier, we must simulate it.
> However, since futexes and keyed events work differently, simulation of 
> futexes using keyed events would:
>   0) require a lot of work, and
>   1) suffer from performance penalty just like if we simulate keyed events on 
> Windows 2000.
>
> The major difference is that, the FUTEX_WAIT syscall is an atomic 
> compare-and-sleep operation, while the NtWaitForKeyedEvent syscall provides 
> no comparison.
> Instead, the NtReleasedKeyedEvent syscall blocks the current thread until one 
> thread is woken up, while FUTEX_WAKE does nothing and returns immediately.
>
> So here is my condition: in no event shall portability harm either efficiency 
> or maintainability.
> Linux and Windows work differently. I consider it 'harmful' to make one look 
> like the other.
>
>
> --
> Best regards,
> lh_mouse
> 2016-04-14
>
> -
> 发件人：Torvald Riegel 
> 发送日期：2016-04-14 01:40
> 收件人：lh_mouse
> 抄送：gcc,mingw-w64-public
> 主题：Re: Adding a new thread model to GCC
>
> On Wed, 2016-04-13 at 17:17 +0800, lh_mouse wrote:
>> Hi all,
>>
>> The 'win32' thread model of gcc has been there since long long ago, being 
>> compatible with very old Windows versions, also having a number of drawbacks:
>>   0) its implementation is very inefficient, and
>>   1) its mutexes and condition variables require dynamic initialization and 
>> are unusable in C++11 as std::mutex requires a `constexpr` constructor, and
>>   2) allocating a number of rarely used mutexes or condition variables would 
>> eventually make the system run out of kernel objects.
>>
>> As a solution for 1) and 2), Microsoft introduced keyed events, details of 
>> which can be found here:
>> http://joeduffyblog.com/2006/11/28/windows-keyed-events-critical-sections-and-new-vista-synchronization-features/
>
> Have you looked at WaitOnAddress and WakeByAddressSingle /
> WakeByAddressAll too?  AFAIK this is new in Windows 8, and seems similar
> to futexes.
>
> I think it might be better to get a std::synchronic (or similar)
> implementation into GCC, and then use these to implement at least the
> mutexes:
> https://github.com/ogiroux/synchronic/blob/master/include/synchronic
>
> One benefit would be that we then have one place where we have optimized
> spinning/blocking in libstdc++ on Windows, and less platform-specific
> code.
>
>
>

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fix mkstemp implementation

[Dongsheng Song]

On Wed, Mar 2, 2016 at 2:10 AM, İsmailDönmez <ism...@i10z.com> wrote:
>
> Dongsheng Song <dongsheng.song@...> writes:
>
> > On Tue, Mar 1, 2016 at 8:42 PM, Ismail Donmez  pik7zc4d...@public.gmane.org> wrote:Hi,
> > mingw-w64's current mkstemp implementation wrongly uses _O_TEMPORARY
> which
> > doesn't make sense. Here is a patch from openSUSE we apply to fix it:
> > From: Jan Engelhardt <jeng...@inai.de>
> > Date: 2015-03-31 18:57:45.887248277 +0200
> > References: https://sourceforge.net/p/mingw-w64/bugs/471/
> > When closing the file handle obtained from mkstemp(), the file
> > ought _not_ to be deleted.
> >
> >
> > Why did you make such assertion ?
> >
> > I can not see such statement in POSIX, Linux, FreeBSD or OpenBSD:
> >
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/mkstemp.html
> > http://man7.org/linux/man-pages/man3/mkstemp.3.html
> > https://www.freebsd.org/cgi/man.cgi?query=mkstemp
>
> I just tested the relevant Windows function _mkstemp_s
> (https://msdn.microsoft.com/en-us/library/t8ex5e91.aspx) and it does not
> remove the temp file on close.
>
> Also tested on Linux with glibc 2.22 and it doesn't remove the temporary
> file either.
>
> So mingw-w64's current behaviour is not compatible with any of them. IMHO
> patch should be applied.
>

OK, for compatible reason, I have no objections now.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fix mkstemp implementation

[Dongsheng Song]

On Tue, Mar 1, 2016 at 8:42 PM, Ismail Donmez  wrote:

> Hi,
>
> mingw-w64's current mkstemp implementation wrongly uses _O_TEMPORARY which
> doesn't make sense. Here is a patch from openSUSE we apply to fix it:
>
> From: Jan Engelhardt 
> Date: 2015-03-31 18:57:45.887248277 +0200
> References: https://sourceforge.net/p/mingw-w64/bugs/471/
>
> When closing the file handle obtained from mkstemp(), the file
> ought _not_ to be deleted.
>

Why did you make such assertion ?

I can not see such statement in POSIX, Linux, FreeBSD or OpenBSD:

http://pubs.opengroup.org/onlinepubs/009695399/functions/mkstemp.html
http://man7.org/linux/man-pages/man3/mkstemp.3.html
https://www.freebsd.org/cgi/man.cgi?query=mkstemp
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/mkdtemp.3
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Patch for locking printf

[Dongsheng Song]

On Mon, Aug 3, 2015 at 12:26 PM, lh_mouse lh_mo...@126.com wrote:
 ISO C11 requires operations on the same stream (or whatever a FILE struct 
 handles) _not_ to interleave with each other.
 This should include outputting each character using puts() or printf() 
 functions, since they both manipulate the `stdout` stream.

 It should be noted that mingw-w64 has never claimed C11 compatibility. On the 
 other hand, GCC has enabled -std=gnu11 since GCC 5.
 Such interleaving behavior would conflict with GCC's new default expectation.


Thanks for reminder.

 ---
 WG14 N1570 (a.k.a. draft for ISO C11)

 7.21.2 Streams
 7 Each stream has an associated lock that is used to prevent data races when 
 multiple
 threads of execution access a stream, and to restrict the interleaving of 
 stream operations
 performed by multiple threads. Only one thread may hold this lock at a time. 
 The lock is
 reentrant: a single thread may hold the lock multiple times at a given time.
 8 All functions that read, write, position, or query the position of a stream 
 lock the stream
 before accessing it. They release the lock associated with the stream when 
 the access is
 complete.


Thanks for your information.
The lock in the patch is not reentrant, correct ?

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Patch for locking printf

[Dongsheng Song]

On Sat, Aug 1, 2015 at 6:56 AM, JonY jo...@users.sourceforge.net wrote:

 On 7/23/2015 06:24, JonY wrote:
  Hi,
 
  Patch introduces a new macro __MINGW_PRINTF_LOCKING for fprintf and
  vfprintf so when called on the same FILE stream, the operations are not
  overlapped. __USE_MINGW_ANSI_STDIO must also be set for the new macro to
  take effect.
 
  The reason why it is done in such a way is so programs that already
  doing their own locking will not be affected.
 
  Idea from user Mateusz of Sourceforge. Patch OK?
 

 Ping?


I like the idea. But  AFAIK, this code is not portable since it's
neither a standard extension nor the standards of practice.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW-64 - GCC-5.x?

[Dongsheng Song]

On Sat, Jun 27, 2015 at 12:13 PM, Developer 1 arbol...@hotmail.ca wrote:

   Is there a MinGW64 with gcc5.x?


http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/dongsheng-daily/
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] printf speedup [PATCH]

[Dongsheng Song]

On Wed, Apr 1, 2015 at 4:33 PM, Martin Mitáš m...@morous.org wrote:



 Dne 1. 4. 2015 v 10:13 Mattias Engdegård napsal(a):
  1 apr 2015 kl. 05.35 skrev Dongsheng Song dongsheng.s...@gmail.com:
 
  In my testing, getenv() is very fast.
 
  *) unset PRINTF_EXPONENT_DIGITS
 
  preheat 1 times, then perform 100 times (use 4.6 seconds)
  getenv cost: 4.6 us
 
  *) set PRINTF_EXPONENT_DIGITS=3
  preheat 1 times, then perform 100 times (use 3.41991 seconds)
  getenv: 3.41991 us
 
  4 µs is a lot on a modern CPU, and an unacceptable overhead for a basic
 library function such as sprintf.

 If I assume getenv() iterates over complete environment in most cases (when
 PRINTF_EXPONENT_DIGITS is not set), then there is probably much worse
 overhead
 in a real world programs which is not likely covered in a trivial test
 program.

 The function getenv() shall replace data in CPU cache, which are likely
 useful
 for the ongoing program computation, with a lot of junk (the complete
 process
 environment).

 Morous


I'm certainly not opposed your patch, but a bit curious why getenv() slow
your program. we can always simplify a real world program to a test program
to discourse the performance issue.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] printf speedup [PATCH]

[Dongsheng Song]

Hi Mattias,

Could you share your micro benchmark data ?

In my testing, getenv() is very fast.

*) unset PRINTF_EXPONENT_DIGITS

preheat 1 times, then perform 100 times (use 4.6 seconds)
getenv cost: 4.6 us

*) set PRINTF_EXPONENT_DIGITS=3
preheat 1 times, then perform 100 times (use 3.41991 seconds)
getenv: 3.41991 us

My CPU is Core2 E6550 at 2.33 GHz.

On Wed, Apr 1, 2015 at 10:26 AM, Dongsheng Song dongsheng.s...@gmail.com
wrote:

 Cache getenv() looks a good idea !
 Patch is OK for me.

 On Wed, Apr 1, 2015 at 4:16 AM, Mattias Engdegård matti...@acm.org
 wrote:

 The functions in the __mingw_printf family are very slow because of the
 getenv(”PRINTF_EXPONENT_DIGITS”) call that is made every time, even when
 that information isn’t actually needed.

 Please consider this patch. It only calls getenv once, caching the result
 (as is traditionally done in libraries that use environment variables this
 way). It also only computes the minimum exponent digits when actually
 needed, at most once per format call.

 With this patch, __mingw_sprintf(buf, ”x”) goes from being several orders
 of magnitude slower than the MSVCRT sprintf, to about 66% faster. You don’t
 see this kind of improvement every day.



#include winsock2.h
#include stdlib.h
#include stdio.h
#include errno.h

#define NUMBER_PREHEAT  1
#define NUMBER_PERFORM  100

int main(int argc, char *argv[])
{
int i;
double t;
LARGE_INTEGER freq, pc, pc2;

QueryPerformanceFrequency(freq);

for (i = 0; i  NUMBER_PREHEAT; i++) {
getenv(PRINTF_EXPONENT_DIGITS);
}

QueryPerformanceCounter(pc);
for (i = 0; i  NUMBER_PERFORM; i++) {
getenv(PRINTF_EXPONENT_DIGITS);
}
QueryPerformanceCounter(pc2);

t = (pc2.QuadPart - pc.QuadPart) / (double) freq.QuadPart;

fprintf(stdout, preheat %d times, then perform %d times (use %.5lf seconds)\n, NUMBER_PREHEAT, NUMBER_PERFORM, t);
fprintf(stdout, getenv cost: %.5lf us\n, t * 100.0 / NUMBER_PERFORM);

return 0;
}
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] stdlib.h: Add mkstemp implementation.

[Dongsheng Song]

On Thu, Jan 22, 2015 at 5:59 PM, Alexpux alex...@gmail.com wrote:

 22 янв. 2015 г., в 12:50, Jacek Caban ja...@codeweavers.com написал(а):

 On 01/22/15 06:05, Dongsheng Song wrote:
 Passed full gcc 4.9 32 bit and 64 bit building,  then pushed.

 Did anyone review the patch before you pushed? You shouldn't mark is as
 DATA until it has emulation code.

 Agree with it.


Sorry push lib32/msvcrt.def.in changes by mistake.

The commit efc07ae1f91561e0be21ed108ac33a3511dfd548 just intend to fix
mkstemp.c on XP only.

The lib32/msvcrt.def.in changes is part of the next patch.

Please review.

Regards,
Dongsheng
New _sopen_s emulation.

 mingw-w64-crt/Makefile.am   |  1 +
 mingw-w64-crt/lib32/msvcr100.def.in |  2 +-
 mingw-w64-crt/lib32/msvcr110.def.in |  2 +-
 mingw-w64-crt/lib32/msvcr90.def.in  |  2 +-
 mingw-w64-crt/lib32/msvcr90d.def.in |  2 +-
 mingw-w64-crt/lib32/msvcrt.def.in   |  2 +-
 mingw-w64-crt/lib64/msvcr100.def.in |  2 +-
 mingw-w64-crt/lib64/msvcr110.def.in |  2 +-
 mingw-w64-crt/lib64/msvcr90.def.in  |  2 +-
 mingw-w64-crt/lib64/msvcr90d.def.in |  2 +-
 mingw-w64-crt/lib64/msvcrt.def.in   |  2 +-
 mingw-w64-crt/libarm32/msvcr110.def |  2 +-
 mingw-w64-crt/libarm32/msvcr120_clr0400.def |  2 +-
 mingw-w64-crt/libarm32/msvcrt.def   |  2 +-
 mingw-w64-crt/secapi/_sopen_s.c | 43 +
 mingw-w64-headers/crt/io.h  |  2 +-
 16 files changed, 58 insertions(+), 14 deletions(-)

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 3348ea2..4c5bf28 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -170,6 +170,7 @@ src_msvcrt=\
   secapi/_localtime32_s.c \
   secapi/_localtime64_s.c \
   secapi/_mktemp_s.c \
+  secapi/_sopen_s.c \
   secapi/_strdate_s.c \
   secapi/_strtime_s.c \
   secapi/_umask_s.c \
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in 
b/mingw-w64-crt/lib32/msvcr100.def.in
index a1d7447..2472320 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -1344,7 +1344,7 @@ _snwscanf_l
 _snwscanf_s
 _snwscanf_s_l
 _sopen
-_sopen_s
+; _sopen_s replaced by emu
 _spawnl
 _spawnle
 _spawnlp
diff --git a/mingw-w64-crt/lib32/msvcr110.def.in 
b/mingw-w64-crt/lib32/msvcr110.def.in
index f9f0294..d9854dc 100644
--- a/mingw-w64-crt/lib32/msvcr110.def.in
+++ b/mingw-w64-crt/lib32/msvcr110.def.in
@@ -1477,7 +1477,7 @@ _snwscanf_l
 _snwscanf_s
 _snwscanf_s_l
 _sopen
-_sopen_s
+; _sopen_s replaced by emu
 _spawnl
 _spawnle
 _spawnlp
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in 
b/mingw-w64-crt/lib32/msvcr90.def.in
index 394d7f5..7d8ef3c 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -978,7 +978,7 @@ _snwscanf_l
 _snwscanf_s
 _snwscanf_s_l
 _sopen
-_sopen_s
+; _sopen_s replaced by emu
 _spawnl
 _spawnle
 _spawnlp
diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in 
b/mingw-w64-crt/lib32/msvcr90d.def.in
index 8846e13..a3f587a 100644
--- a/mingw-w64-crt/lib32/msvcr90d.def.in
+++ b/mingw-w64-crt/lib32/msvcr90d.def.in
@@ -1042,7 +1042,7 @@ _snwscanf_l
 _snwscanf_s
 _snwscanf_s_l
 _sopen
-_sopen_s
+; _sopen_s replaced by emu
 _spawnl
 _spawnle
 _spawnlp
diff --git a/mingw-w64-crt/lib32/msvcrt.def.in 
b/mingw-w64-crt/lib32/msvcrt.def.in
index 496e8cf..71bdf56 100644
--- a/mingw-w64-crt/lib32/msvcrt.def.in
+++ b/mingw-w64-crt/lib32/msvcrt.def.in
@@ -1039,7 +1039,7 @@ _snwprintf_s_l
 _snwscanf_l
 _snwscanf_s
 _snwscanf_s_l
-_sopen_s DATA
+; _sopen_s replaced by emu
 _splitpath_s
 _sprintf_l
 _sprintf_p_l
diff --git a/mingw-w64-crt/lib64/msvcr100.def.in 
b/mingw-w64-crt/lib64/msvcr100.def.in
index a3ba8cd..384fc64 100644
--- a/mingw-w64-crt/lib64/msvcr100.def.in
+++ b/mingw-w64-crt/lib64/msvcr100.def.in
@@ -1292,7 +1292,7 @@ _snwscanf_l
 _snwscanf_s
 _snwscanf_s_l
 _sopen
-_sopen_s
+; _sopen_s replaced by emu
 _spawnl
 _spawnle
 _spawnlp
diff --git a/mingw-w64-crt/lib64/msvcr110.def.in 
b/mingw-w64-crt/lib64/msvcr110.def.in
index 6e8a487..65f3122 100644
--- a/mingw-w64-crt/lib64/msvcr110.def.in
+++ b/mingw-w64-crt/lib64/msvcr110.def.in
@@ -1416,7 +1416,7 @@ _snwscanf_l
 _snwscanf_s
 _snwscanf_s_l
 _sopen
-_sopen_s
+; _sopen_s replaced by emu
 _spawnl
 _spawnle
 _spawnlp
diff --git a/mingw-w64-crt/lib64/msvcr90.def.in 
b/mingw-w64-crt/lib64/msvcr90.def.in
index 7b74907..5fd5749 100644
--- a/mingw-w64-crt/lib64/msvcr90.def.in
+++ b/mingw-w64-crt/lib64/msvcr90.def.in
@@ -912,7 +912,7 @@ _snwscanf_l
 _snwscanf_s
 _snwscanf_s_l
 _sopen
-_sopen_s
+; _sopen_s replaced by emu
 _spawnl
 _spawnle
 _spawnlp
diff --git a/mingw-w64-crt/lib64/msvcr90d.def.in 
b/mingw-w64-crt/lib64/msvcr90d.def.in
index 4649135..1454d29 100644
--- a/mingw-w64-crt/lib64/msvcr90d.def.in
+++ b/mingw-w64-crt/lib64/msvcr90d.def.in
@@ -970,7 +970,7 @@ _snwscanf_l
 _snwscanf_s
 _snwscanf_s_l
 _sopen
-_sopen_s
+; _sopen_s replaced by emu
 _spawnl
 _spawnle
 _spawnlp
diff

Re: [Mingw-w64-public] [PATCH 1/2] stdlib.h: Add mkstemp implementation.

[Dongsheng Song]

Passed full gcc 4.9 32 bit and 64 bit building,  then pushed.

On Thu, Jan 22, 2015 at 10:27 AM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
 On Thu, Jan 22, 2015 at 10:24 AM, Óscar Fuentes o...@wanadoo.es wrote:
 I can attest that _sopen_s is not present on the msvcrt.dll version
 7.0.2600.5512 installed on Windows XP SP3.

 Please note that MSDN says that _sopen_s is present since Windows 95,
 which is absurd, so don't rely on that either. (The *_s functions
 appeared on VS 2005 [2].)


 Thanks.

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] time.h: Merge time_s.h into time.h.

[Dongsheng Song]

On Thu, Jan 22, 2015 at 1:16 PM, LRN lrn1...@gmail.com wrote:
 And, of course, i've just stepped on the same rake... Here's a patch that
 *actually* fixes this.


Still have 'define _INC_WTIME_INL' and ' !defined (_INC_WTIME_S_INL)'
not match issue.

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] time.h: Merge time_s.h into time.h.

[Dongsheng Song]

On Thu, Jan 22, 2015 at 1:34 PM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
 On Thu, Jan 22, 2015 at 1:16 PM, LRN lrn1...@gmail.com wrote:
 And, of course, i've just stepped on the same rake... Here's a patch that
 *actually* fixes this.


 Still have 'define _INC_WTIME_INL' and ' !defined (_INC_WTIME_S_INL)'
 not match issue.

Sorry, I'm reading the wrong patch.

Now it's looks OK for me.

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] stdlib.h: Add mkstemp implementation.

[Dongsheng Song]

On Thu, Jan 22, 2015 at 1:03 AM, Alexey Pavlov alex...@gmail.com wrote:

 Current mkstemp implementation call _sopen_s that is not present in
 WinXP msvcrt.dll. So this break supporting WinXP.


I have no WinXP now, but '_sopen_s' in the msvcrt.def file:

$ grep _sopen_s mingw-w64-crt/def-include/msvcrt-common.def.in
mingw-w64-crt/lib32/msvcrt.def.in

mingw-w64-crt/lib32/msvcrt.def.in:_sopen_s

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] stdlib.h: Add mkstemp implementation.

[Dongsheng Song]

On Thu, Jan 22, 2015 at 10:24 AM, Óscar Fuentes o...@wanadoo.es wrote:
 I can attest that _sopen_s is not present on the msvcrt.dll version
 7.0.2600.5512 installed on Windows XP SP3.

 Please note that MSDN says that _sopen_s is present since Windows 95,
 which is absurd, so don't rely on that either. (The *_s functions
 appeared on VS 2005 [2].)


Thanks.

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] stdlib.h: Add mkstemp implementation.

[Dongsheng Song]

On Thu, Jan 22, 2015 at 10:15 AM, LRN lrn1...@gmail.com wrote:
 On 22.01.2015 5:01, Dongsheng Song wrote:
 On Thu, Jan 22, 2015 at 1:03 AM, Alexey Pavlov alex...@gmail.com wrote:

 Current mkstemp implementation call _sopen_s that is not present in
 WinXP msvcrt.dll. So this break supporting WinXP.


 I have no WinXP now, but '_sopen_s' in the msvcrt.def file:

 $ grep _sopen_s mingw-w64-crt/def-include/msvcrt-common.def.in
 mingw-w64-crt/lib32/msvcrt.def.in

 mingw-w64-crt/lib32/msvcrt.def.in:_sopen_s

 That means nothing.


I don't think so. This file based on XP msvcrt.dll. If we add symbols
which did not in the XP, all functions should be marked with DATA.

Anyway, I will push a patch which use _sopen instead of _sopen_s.

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] stdlib.h: Add mkstemp implementation.

[Dongsheng Song]

On Wed, Jan 7, 2015 at 4:50 PM, niXman i.nix...@autistici.org wrote:
 Dongsheng Song 2015-01-07 11:34:

 Since the last 6 characters must be XX is mandatory, I think no
 need such tricks.
 You do not know what will change through the 1,5,10 years.


No, it should not changed, this is widely used API. Such changes will
break lots of application.
Maybe another function will defined, e.g. mkstemp2.


 I think the merged condition statement is not very complicated.
 But why is it deliberately complicated?


I don‘t thinks the following  code (V1):

if (template_name == NULL || (len = strlen (template_name))  6
|| memcmp (template_name + (len - 6), XX, 6)) {
errno = EINVAL;
return -1;
}

bad than (V2):

if (template_name == NULL) {
errno = EINVAL;
return -1;
}

if ((len = strlen (template_name))  6
|| memcmp (template_name + (len - 6), XX, 6)) {
errno = EINVAL;
return -1;
}

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/2] stdlib.h: Add mkstemp implementation.

[Dongsheng Song]

On Wed, Jan 7, 2015 at 4:00 PM, niXman i.nix...@autistici.org wrote:
 +int __cdecl mkstemp (char *template_name)
 +{
 +errno_t ec;
 +int i, j, fd, len, index;
 +
 +/* These are the (62) characters used in temporary filenames. */
 +static const char letters[] =
 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789;
 +
 +/* The last six characters of template must be XX */
 +if (template_name == NULL || (len = strlen (template_name))  6
 +|| memcmp (template_name + (len - 6), XX, 6)) {
 +errno = EINVAL;
 +return -1;
 +}

 It will be better if XX and '6' will be variables:
 static const char x_template[] = XX;
 static const int x_template_len = sizeof(x_template)-1;


Since the last 6 characters must be XX is mandatory, I think no
need such tricks.

 and the test for 'template_name == NULL' I propose to move to the top of
 the function.

 in this case, the code look like this:
 if (template_name == NULL) {
  errno = EINVAL;
  return -1;
 }


I think the merged condition statement is not very complicated.

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] asctime_r duplications

[Dongsheng Song]

On Wed, Jan 7, 2015 at 7:33 PM, Jacek Caban ja...@codeweavers.com wrote:
 Hi Alexey,

 On 01/07/15 09:06, Alexey Pavlov wrote:
 Ladt changes to time functions lead to multiple definitions of
 asctime_r in some programs. For example,

 I just pushed a fixup:
 http://sourceforge.net/p/mingw-w64/mingw-w64/ci/9f52135b2fa1336d63cda12c502f1790797387fa

 I wonder why it didn't cause errors in my case...


Thanks. It cause gcc build failure because more than one source file
include time.h, then asctime_r got implemented more than once.

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 1/2] stdlib.h: Add mkstemp implementation.

[dongsheng . song]

From: 宋冬生 songdongsh...@live.cn

---
 mingw-w64-crt/Makefile.am  |  2 +-
 mingw-w64-crt/misc/mkstemp.c   | 91 ++
 mingw-w64-headers/crt/stdlib.h |  1 +
 3 files changed, 93 insertions(+), 1 deletion(-)
 create mode 100644 mingw-w64-crt/misc/mkstemp.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index b0ac2f2..3348ea2 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -263,7 +263,7 @@ src_libmingwex=\
   misc/gettimeofday.cmisc/imaxabs.c misc/imaxdiv.c  
misc/isblank.c   misc/iswblank.c\
   misc/mbrtowc.c misc/mbsinit.c misc/mempcpy.c  
misc/mingw-aligned-malloc.c  misc/mingw-fseek.c \
   misc/mingw_matherr.c   misc/mingw_mbwc_convert.c  misc/mingw_usleep.c 
misc/mingw_wcstod.c  misc/mingw_wcstof.c\
-  misc/mingw_wcstold.c   misc/seterrno.cmisc/sleep.c
misc/spawnv.c  \
+  misc/mingw_wcstold.c   misc/mkstemp.c misc/seterrno.c 
misc/sleep.c misc/spawnv.c  \
   misc/spawnve.c misc/spawnvp.c misc/spawnvpe.c 
misc/strnlen.c   misc/strsafe.c \
   misc/strtoimax.c   misc/strtold.c misc/strtoumax.c
misc/tdelete.c   misc/tfind.c   \
   misc/tsearch.c misc/twalk.c   misc/uchar_c16rtomb.c   
misc/uchar_c32rtomb.cmisc/uchar_mbrtoc16.c  \
diff --git a/mingw-w64-crt/misc/mkstemp.c b/mingw-w64-crt/misc/mkstemp.c
new file mode 100644
index 000..081b512
--- /dev/null
+++ b/mingw-w64-crt/misc/mkstemp.c
@@ -0,0 +1,91 @@
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include io.h
+#include errno.h
+#include share.h
+#include fcntl.h
+#include sys/stat.h
+
+/*
+The mkstemp() function generates a unique temporary filename from template,
+creates and opens the file, and returns an open file descriptor for the
+file.
+
+The template may be any file name with at least six trailing Xs, for 
example
+/tmp/temp.. The trailing Xs are replaced with a unique digit and
+letter combination that makes the file name unique. Since it will be
+modified, template must not be a string constant, but should be declared as
+a character array.
+
+The file is created with permissions 0600, that is, read plus write for
+owner only. The returned file descriptor provides both read and write 
access
+to the file.
+ */
+int __cdecl mkstemp (char *template_name)
+{
+errno_t ec;
+int i, j, fd, len, index;
+
+/* These are the (62) characters used in temporary filenames. */
+static const char letters[] = 
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789;
+
+/* The last six characters of template must be XX */
+if (template_name == NULL || (len = strlen (template_name))  6
+|| memcmp (template_name + (len - 6), XX, 6)) {
+errno = EINVAL;
+return -1;
+}
+
+/* User may supply more than six trailing Xs */
+for (index = len - 6; index  0  template_name[index - 1] == 'X'; 
index--);
+
+/*
+Like OpenBSD, mkstemp() will try at least 2 ** 31 combinations before
+giving up.
+ */
+for (i = 0; i = 0; i++) {
+for(j = index; j  len; j++) {
+template_name[j] = letters[rand () % 62];
+}
+
+ec = _sopen_s (fd, template_name,
+_O_RDWR | _O_CREAT | _O_EXCL | _O_TEMPORARY | _O_BINARY,
+SH_DENYRW, _S_IREAD | _S_IWRITE);
+if (ec == 0) return fd;
+if (ec != EEXIST) return -1;
+}
+
+return -1;
+}
+
+#if 0
+int main (int argc, char *argv[])
+{
+int i, fd;
+
+for (i = 0; i  10; i++) {
+char template_name[] = { temp_XX };
+fd = mkstemp (template_name);
+if (fd = 0) {
+fprintf (stderr, fd=%d, name=%s\n, fd, template_name);
+_close (fd);
+} else {
+fprintf (stderr, errno=%d\n, errno);
+}
+}
+
+for (i = 0; i  10; i++) {
+char template_name[] = { temp_ };
+fd = mkstemp (template_name);
+if (fd = 0) {
+fprintf (stderr, fd=%d, name=%s\n, fd, template_name);
+_close (fd);
+} else {
+fprintf (stderr, errno=%d\n, errno);
+}
+}
+
+return 0;
+}
+#endif
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 7743452..fe44195 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -378,6 +378,7 @@ extern C {
   _CRTIMP int __cdecl _mbtowc_l(wchar_t * __restrict__ _DstCh,const char * 
__restrict__ _SrcCh,size_t _SrcSizeInBytes,_locale_t _Locale);
   size_t __cdecl mbstowcs(wchar_t * __restrict__ _Dest,const char * 
__restrict__ _Source,size_t _MaxCount);
   _CRTIMP size_t __cdecl _mbstowcs_l(wchar_t * __restrict__ 

Re: [Mingw-w64-public] [PATCH] Do not include non-existent header file 'ansidecl.h'

[Dongsheng Song]

Yes, I can cross build binutils 2.24, gdb 7.8.1, gcc 4.8/4.9/5.0 (both
32 bit and 64 bit). Then use these cross build compiler (gcc
4.8/4.9/5.0) can build the native compiler (gcc 4.8/4.9/5.0) without
any regress.

PS: this patch did not remove any header files, it just fix compile errors:

fatal error: ansidecl.h: No such file or directory│
 #include ansidecl.h
  ^
compilation terminated.

On Fri, Jan 2, 2015 at 5:47 PM, Kai Tietz ktiet...@googlemail.com wrote:
 AFAI remember was this header necessary for some of this header users.
 Have you tried to bootstrap binutils/gcc with this change?  I remember
 there was a reason to depend on this header, but I can recall why
 exactly.
 Anyway, if boostrap of binutils/gcc is fine without regressions, then
 I am ok with that patch.

 Thanks,
 Kai

 2014-12-31 9:42 GMT+01:00 Alexpux alex...@gmail.com:

 31 дек. 2014 г., в 6:19, dongsheng.s...@gmail.com написал(а):


 The header file 'ansidecl.h' did not in the repo, and not generated by any 
 script.

 OK for commit ?

 ansidecl.h is part of binutils/gdb

 Regards,
 Dongsheng

 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Do not include non-existent header file 'ansidecl.h'

[dongsheng . song]

From: Dongsheng Song dongsheng.s...@gmail.com

---
 mingw-w64-headers/crt/ieeefp.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mingw-w64-headers/crt/ieeefp.h b/mingw-w64-headers/crt/ieeefp.h
index d22a4b5..d8bbf40 100644
--- a/mingw-w64-headers/crt/ieeefp.h
+++ b/mingw-w64-headers/crt/ieeefp.h
@@ -3,7 +3,6 @@
 
 #include crtdefs.h
 #include math.h
-#include ansidecl.h
 
 #endif /* _IEEE_FP_H_ */
 
-- 
2.1.3


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] dongsheng daily builds

[Dongsheng Song]

On Fri, Dec 26, 2014 at 5:14 AM, Chuckles oblanu...@gmail.com wrote:
 Daily win-32 builds of GCC 5.0 from November 12, 2014 does not include the
 following files.

 bin folder : missing libgcc_s_seh.dll, libstdc++-6.dll, libsspp-0.dll,
 libquadmath-0.dll...

 include folder: c++ folder.


Thanks, fix in gcc-5.0-win32_5.0.0-20141228.7z and
gcc-5.0-win64_5.0.0-20141228.7z.

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] dongsheng 5.0.0 20141215 missing algorithm

[Dongsheng Song]

On Fri, Dec 19, 2014 at 1:32 AM, Jim Michaels jmich...@yahoo.com wrote:
 not sure what else is missing.


Thanks for reporting. my cross compile have algorithm, but when I use
this cross compiler to gererate the native compiler, these headers not
installed, it maybe a gcc build system bug.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] dongdheng 20141215 seriously gutted

[Dongsheng Song]

On Fri, Dec 19, 2014 at 3:30 AM, Jim Michaels jmich...@yahoo.com wrote:
 there is like all of 5 header files in the include dir.
 not sure what's going on.


you are looking in the wrong directory. you shoud looking it in the
platform direcoty, e.g. i686-w64-mingw32/include/ or
x86_64-w64-mingw32/include/ .

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] UINT64_MAX in stdint.h has 1 too few f's, bits/c++config.h missing

[Dongsheng Song]

On Fri, Dec 19, 2014 at 4:10 AM, Jim Michaels jmich...@yahoo.com wrote:
 my program has a forever loop because of in invalid value in this.

 stdint.h line 89
 #define UINT64_MAX 0xULL /* 18446744073709551615ULL */


UINT64_MAX is 64 bit unsigned interger.

 bits/c++config.h is also missing.


It's another gcc 5 bug.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Build MinGW-w64 from Git on Linux

[Dongsheng Song]

On Thu, Nov 27, 2014 at 7:16 AM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
 Hi all,

 I'm having a bit of trouble building MinGW-w64 from source.

 I asked on IRC and was told something along the lines of:

 export MYPREFIX=$HOME/MinGW/64
 (cd mingw-w64-headers  ./configure --prefix=$MYPREFIX  make install)
 ./configure --prefix=$MYPREFIX  make

 When I run that I get:

 configure: error: Please check if the mingw-w64 header set and the
 build/host option are set properly.
 configure: error: ./configure failed for mingw-w64-crt

 but the configure --help output doesn't really help me very much.

 Clues?


Please see the doc in the folder mingw-w64-doc/howto-build/.

If you want build from source, you must do the following 5 steps:

*) build and install binutils for target x86_64-w64-mingw32
*) build and install mingw-w64-headers for target x86_64-w64-mingw32
*) build (all-gcc) and install (install-gcc) for target x86_64-w64-mingw32
*) build and install mingw-w64-crt for target x86_64-w64-mingw32
*) build and install gcc for target x86_64-w64-mingw32

If you want build with pthread support, it will be 7 steps, more
complex, please read the document carefully.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] FPU control word on startup

[Dongsheng Song]

On 2014-11-26 04:58, Kai Tietz wrote:

2014-11-25 21:49 GMT+01:00 Carl Kleffner cmkleff...@gmail.com:

Hi Kai,

you may take notice of some inconsistent behaviour. The master thread starts
with extended precision. Newly created threads start with the MSVC standard
double precision.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761175


Yes, we can do here something.  Question is here the following:  Do we
want to do this only if executable is generated by mingw-w64, or do we
want it for each loaded DLL?

Kai



It's really  strange thing, can we just set to extended precision in the 
function pthread_create ?


Regards,
Cauchy



smime.p7s
Description: S/MIME Cryptographic Signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] Add qsort_s declaration.

[Dongsheng Song]

On Mon, Nov 24, 2014 at 5:40 PM, Alexey Pavlov alex...@gmail.com wrote:

 Use qsort_s from msvcrt according to:
 http://msdn.microsoft.com/en-us/library/4xc60xas.aspx


As MSDN said, both VS 2005, 2008,  2010, 2012 and 2013 have 'qsort_s',
 please do not only update msvcr80, but also msvcr90, msvcr100,
msvcr110 and msvcr120.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch] Missing defines for ws2tcpip

[Dongsheng Song]

Looks better if you align the values of AI_*.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Reformatting the values of AI_*.

[Dongsheng Song]

OK, here is it.

---
 mingw-w64-headers/include/ws2tcpip.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/mingw-w64-headers/include/ws2tcpip.h 
b/mingw-w64-headers/include/ws2tcpip.h
index 4afdfca..3cb29b9 100644
--- a/mingw-w64-headers/include/ws2tcpip.h
+++ b/mingw-w64-headers/include/ws2tcpip.h
@@ -209,21 +209,21 @@ typedef __MINGW_NAME_AW(ADDRINFO) ADDRINFOT,*PADDRINFOT;
 
 typedef ADDRINFOA ADDRINFO,*LPADDRINFO;
 
-#define AI_PASSIVE 0x1
-#define AI_CANONNAME 0x2
-#define AI_NUMERICHOST 0x4
+#define AI_PASSIVE  0x0001
+#define AI_CANONNAME0x0002
+#define AI_NUMERICHOST  0x0004
 #if (_WIN32_WINNT = 0x0600)
-#define AI_NUMERICSERV0x0008
-#define AI_ALL0x0100
-#define AI_ADDRCONFIG 0x0400
-#define AI_V4MAPPED   0x0800
-#define AI_NON_AUTHORITATIVE  0x04000
-#define AI_SECURE 0x08000
-#define AI_RETURN_PREFERRED_NAMES 0x01
+#define AI_NUMERICSERV  0x0008
+#define AI_ALL  0x0100
+#define AI_ADDRCONFIG   0x0400
+#define AI_V4MAPPED 0x0800
+#define AI_NON_AUTHORITATIVE0x4000
+#define AI_SECURE   0x8000
+#define AI_RETURN_PREFERRED_NAMES   0x0001
 #endif
 #if (_WIN32_WINNT = 0x0601)
-#define AI_FQDN   0x02
-#define AI_FILESERVER 0x04
+#define AI_FQDN 0x0002
+#define AI_FILESERVER   0x0004
 #endif
 
 #ifdef __cplusplus
-- 
2.1.3


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] r217364 - in /trunk: ChangeLog Makefile.def Mak...

[Dongsheng Song]

On Wed, Nov 12, 2014 at 3:14 PM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
 On Wed, Nov 12, 2014 at 3:07 PM, Tobias Burnus bur...@net-b.de wrote:
 Hi Dongsheng,

 Did you do a new bootstrap or an incremental build? I got a similar error
 when I built (on a different system) when I just updated the trunk and hit
 make. It did work correctly after doing a build into an empty directory.
 It *might* be sufficient to delete graphite-interchange.o and try again.

 Tobias


 Yes, I do a new bootstrap. My build is out of tree build, I re-create
 the obj directory every time.

 Maybe is the dependency issue ? I use gcc 4.7.2 on Debian x64 7.7, gmp
 5.1.3, mpfr 3.1.2 p10, mpc 1.0.2 and isl 0.12.2, is it OK ?

I have rechecked error.log, found that make had checked gmp, mpfr and
mpc, but NOT ISL, then build gcc. Maybe you can make gcc depend ISL to
fix this build issue ?

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Remove the Macros of the time_r functions and replace them with actual functions

[Dongsheng Song]

Pushed with delete mysterious U+200B  characters.

Unicode Character 'ZERO WIDTH SPACE' (U+200B)

+tmp = localtime(_Time);
+if (tmp != NULL)
+memcpy(_Tm, tmp, sizeof(struct tm);
+return tmp;200b200b
+200b}200b
+

On Wed, Nov 12, 2014 at 11:59 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Well,

 ascitime is in msvcrt thread-save too ... anyway, from my POOV patch
 is ok.  If there are no objections by others, please apply.

 Thanks,
 Kai

 2014-11-12 15:50 GMT+01:00 Martell Malone martellmal...@gmail.com:
 Added a guard to every function and handle errno values
 Used memcpy in gmtime_r as discussed

 This version should address all concerns.
 Please commit

 On Wed, Nov 12, 2014 at 2:41 PM, Martell Malone martellmal...@gmail.com
 wrote:

 Arg I changed the old patch with including errno.h
 Can someone delete the previous email from the thread
 Sorry

 On Wed, Nov 12, 2014 at 2:38 PM, Martell Malone martellmal...@gmail.com
 wrote:

 Caching stopped me from including errno.h

 On Wed, Nov 12, 2014 at 2:34 PM, Martell Malone martellmal...@gmail.com
 wrote:

 Dongsheng Song
 Thank you for your suggested changes.

 I would like to note that my implementation was the exact same as the
 Macros apart from the _r in acrtime which I did change but somehow didn't
 end up in the attached patch due to caching or something heh
 The fact that these functions destroys the result of the previous
 calls mean that the Macros has a major bug in them.

 Should I also guard ctime_r and gmtime_r from NULL pointer arguments
 like this?

 +if (_Time == NULL || _Tm == NULL)
 +{
 +errno = EINVAL;
 +return NULL;
 +}

 Ktietz what is your take on the tread safeness of asctime_r
 I remember you recently telling me that MSDN was often incorrect
 As you implemented winpthreads you may be able to tell us :)

 If anyone needs me to address any more changes I'll be glad to
 Please Review for commit





 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Remove the Macros of the time_r functions and replace them with actual functions

[Dongsheng Song]

On Wed, Nov 12, 2014 at 12:24 AM, Ray Donnelly mingw.andr...@gmail.com
wrote:
 On Tue, Nov 11, 2014 at 2:02 PM, Dongsheng Song
 dongsheng.s...@gmail.com wrote:
 I think you need add 1 line like this:

 TODO: real thread safe implementation.


 Why? msvcrt is thread safe already.


MSDN not said asctime[1] is thread safe, it only said gmtime, mktime,
mkgmtime, and localtime [2] use one common tm structure per thread for the
conversion.

[1] http://msdn.microsoft.com/en-us/library/kys1801b.aspx
[2] http://msdn.microsoft.com/en-us/library/0z9czt0w.aspx

Then you can not assume asctime is thread safe.

*) typo

+char *__cdecl asctime(const struct tm *_Tm, char * _Str)
+{
+char *tmp = asctime(_Tm);
+if (tmp)
+tmp = strcpy(_Str,tmp);
+return tmp;
+}

should changed to:

+ /* TODO: thread safe implementation */
+char *__cdecl asctime_r(const struct tm *_Tm, char * _Str)
+{
+char *tmp;
+
+if (_Tm == NULL || _Str == NULL)
+{
+errno = EINVAL;
+return NULL;

+}
+
+tmp = asctime(_Tm);
+if (tmp != NULL)
+tmp = strcpy(_Str,tmp);
+
+return tmp;
+}

*) bad structure copy

+struct tm *__cdecl localtime_r(const time_t *_Time, struct tm *_Tm)
+{
+struct tm *tmp = localtime(_Time);
+if (tmp)
+*_Tm = *tmp;
+return tmp;
​​

​​
+}

should changed to:

+ /* Both the 32-bit and 64-bit versions of gmtime, mktime, mkgmtime,
+  * and localtime all use one common tm structure per thread for the
+  * conversion. Each call to one of these functions destroys the
+  * result of any previous call.
+  */
+struct tm *__cdecl localtime_r(const time_t *_Time, struct tm *_Tm)
+{
+struct tm *tmp;
+
+if (_Time == NULL || _Tm == NULL)
+{
+errno = EINVAL;
+return NULL;
+}
+
+tmp = localtime(_Time);
+if (tmp)
+memcpy(_Tm, tmp, sizeof(struct tm);
+return tmp;
​​
​+}​
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] r217364 - in /trunk: ChangeLog Makefile.def Mak...

[Dongsheng Song]

On Wed, Nov 12, 2014 at 2:54 AM,  bur...@gcc.gnu.org wrote:
 Author: burnus
 Date: Tue Nov 11 18:54:16 2014
 New Revision: 217364

 URL: https://gcc.gnu.org/viewcvs?rev=217364root=gccview=rev
 Log:
 2014-11-11  Tobias Burnus  bur...@net-b.de

 * config/cloog.m4: Remove.
 * Makefile.def: Remove CLooG.
 * Makefile.tpl: Ditto.
 * configure.ac: Ditto.
 * configure: Regenerate.
 * Makefile.in: Ditto.


 Removed:
 trunk/config/cloog.m4
 Modified:
 trunk/ChangeLog
 trunk/Makefile.def
 trunk/Makefile.in
 trunk/Makefile.tpl
 trunk/configure
 trunk/configure.ac


Windows target (32 bit and 64 bit) broken with this commit.

...
g++   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -static-libstdc++
-static-libgcc  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o
c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o
c/c-objc-common.o c/c-parser.o c/c-array-notation.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o
c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o
c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o
i386-c.o winnt-c.o msformat-c.o \
  cc1-checksum.o libbackend.a main.o  libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-L/home/cauchy/obj/i686-w64-mingw32-gcc-5.0/gcc/./isl/.libs  -lisl
-L/home/cauchy/obj/i686-w64-mingw32-gcc-5.0/gcc/./gmp/.libs
-L/home/cauchy/obj/i686-w64-mingw32-gcc-5.0/gcc/./mpfr/src/.libs
-L/home/cauchy/obj/i686-w64-mingw32-gcc-5.0/gcc/./mpc/src/.libs -lmpc
-lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz
libbackend.a(graphite-interchange.o): In function
`build_linearized_memory_access':
/home/cauchy/vcs/svn/gcc/trunk/gcc/graphite-interchange.c:109:
undefined reference to `isl_val_int_from_ui'
/home/cauchy/vcs/svn/gcc/trunk/gcc/graphite-interchange.c:122:
undefined reference to `isl_val_copy'
/home/cauchy/vcs/svn/gcc/trunk/gcc/graphite-interchange.c:123:
undefined reference to `isl_constraint_set_coefficient_val'
/home/cauchy/vcs/svn/gcc/trunk/gcc/graphite-interchange.c:127:
undefined reference to `isl_set_max_val'
/home/cauchy/vcs/svn/gcc/trunk/gcc/graphite-interchange.c:129:
undefined reference to `isl_val_mul'
/home/cauchy/vcs/svn/gcc/trunk/gcc/graphite-interchange.c:132:
undefined reference to `isl_val_free'
...


error.log
Description: Binary data
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] r217364 - in /trunk: ChangeLog Makefile.def Mak...

[Dongsheng Song]

On Wed, Nov 12, 2014 at 3:07 PM, Tobias Burnus bur...@net-b.de wrote:
 Hi Dongsheng,

 Did you do a new bootstrap or an incremental build? I got a similar error
 when I built (on a different system) when I just updated the trunk and hit
 make. It did work correctly after doing a build into an empty directory.
 It *might* be sufficient to delete graphite-interchange.o and try again.

 Tobias


Yes, I do a new bootstrap. My build is out of tree build, I re-create
the obj directory every time.

Maybe is the dependency issue ? I use gcc 4.7.2 on Debian x64 7.7, gmp
5.1.3, mpfr 3.1.2 p10, mpc .0.2 and isl 0.12.2, is it OK ?

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] rand_r location

[Dongsheng Song]

OK, pushed for you.

On Tue, Nov 11, 2014 at 1:01 AM, Martell Malone martellmal...@gmail.com wrote:
 Hi Kai,

 I don't think this was applied to trunk.
 On the list the messages from this look deleted ?

 I get a message saying
 There are no messages in this thread.
 on the public archive

 Regards
 Martell


 On Fri, Nov 7, 2014 at 8:16 AM, Kai Tietz ktiet...@googlemail.com wrote:

 Looks good to me.  Please apply to trunk.

 Regards,
 Kai


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 1/3] Move _putenv and _wputenv out of _POSIX_ guard.

[dongsheng . song]

From: 宋冬生 songdongsh...@live.cn

See http://msdn.microsoft.com/en-us/library/83zh4e6k.aspx
for more details.
---
 mingw-w64-headers/crt/stdlib.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 839cace..7743452 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -520,6 +520,9 @@ float __cdecl __MINGW_NOTHROW strtof(const char * 
__restrict__ _Str,char ** __re
   __MINGW_EXTENSION _CRTIMP unsigned __int64 __cdecl _wcstoui64_l(const 
wchar_t *_Str ,wchar_t **_EndPtr,int _Radix,_locale_t _Locale);
 #endif
 
+  _CRTIMP int __cdecl _putenv(const char *_EnvString);
+  _CRTIMP int __cdecl _wputenv(const wchar_t *_EnvString);
+
 #ifndef _POSIX_
 #define _CVTBUFSIZE (309+40)
   _CRTIMP char *__cdecl _fullpath(char *_FullPath,const char *_Path,size_t 
_SizeInBytes);
@@ -553,7 +556,6 @@ float __cdecl __MINGW_NOTHROW strtof(const char * 
__restrict__ _Str,char ** __re
 #define _CRT_PERROR_DEFINED
   void __cdecl perror(const char *_ErrMsg);
 #endif
-  _CRTIMP int __cdecl _putenv(const char *_EnvString);
 #pragma push_macro (_rotr64)
 #pragma push_macro (_rotl64)
 #undef _rotl64
@@ -583,7 +585,6 @@ float __cdecl __MINGW_NOTHROW strtof(const char * 
__restrict__ _Str,char ** __re
 #define _CRT_WPERROR_DEFINED
   _CRTIMP void __cdecl _wperror(const wchar_t *_ErrMsg);
 #endif
-  _CRTIMP int __cdecl _wputenv(const wchar_t *_EnvString);
   _CRTIMP void __cdecl _wsearchenv(const wchar_t *_Filename,const wchar_t 
*_EnvVar,wchar_t *_ResultPath) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
   _CRTIMP void __cdecl _wsplitpath(const wchar_t *_FullPath,wchar_t 
*_Drive,wchar_t *_Dir,wchar_t *_Filename,wchar_t *_Ext) 
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
 #endif
-- 
2.1.2


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 2/3] Move _wspawn functions from process.h to stdio.h and wchar.h.

[dongsheng . song]

From: 宋冬生 songdongsh...@live.cn

See http://msdn.microsoft.com/en-us/library/20y988d2.aspx
for more details.
---
 mingw-w64-headers/crt/process.h | 11 ---
 mingw-w64-headers/crt/stdio.h   | 12 
 mingw-w64-headers/crt/wchar.h   | 12 
 3 files changed, 28 insertions(+), 7 deletions(-)

diff --git a/mingw-w64-headers/crt/process.h b/mingw-w64-headers/crt/process.h
index 901a886..9b36daa 100644
--- a/mingw-w64-headers/crt/process.h
+++ b/mingw-w64-headers/crt/process.h
@@ -78,8 +78,8 @@ extern C {
   int __cdecl system(const char *_Command);
 #endif
 
-#ifndef _WPROCESS_DEFINED
-#define _WPROCESS_DEFINED
+#ifndef _WEXEC_DEFINED
+#define _WEXEC_DEFINED
   _CRTIMP intptr_t __cdecl _wexecl(const wchar_t *_Filename,const wchar_t 
*_ArgList,...);
   _CRTIMP intptr_t __cdecl _wexecle(const wchar_t *_Filename,const wchar_t 
*_ArgList,...);
   _CRTIMP intptr_t __cdecl _wexeclp(const wchar_t *_Filename,const wchar_t 
*_ArgList,...);
@@ -88,6 +88,10 @@ extern C {
   _CRTIMP intptr_t __cdecl _wexecve(const wchar_t *_Filename,const wchar_t 
*const *_ArgList,const wchar_t *const *_Env);
   _CRTIMP intptr_t __cdecl _wexecvp(const wchar_t *_Filename,const wchar_t 
*const *_ArgList);
   _CRTIMP intptr_t __cdecl _wexecvpe(const wchar_t *_Filename,const wchar_t 
*const *_ArgList,const wchar_t *const *_Env);
+#endif
+
+#ifndef _WSPAWN_DEFINED
+#define _WSPAWN_DEFINED
   _CRTIMP intptr_t __cdecl _wspawnl(int _Mode,const wchar_t *_Filename,const 
wchar_t *_ArgList,...);
   _CRTIMP intptr_t __cdecl _wspawnle(int _Mode,const wchar_t *_Filename,const 
wchar_t *_ArgList,...);
   _CRTIMP intptr_t __cdecl _wspawnlp(int _Mode,const wchar_t *_Filename,const 
wchar_t *_ArgList,...);
@@ -96,11 +100,12 @@ extern C {
   _CRTIMP intptr_t __cdecl _wspawnve(int _Mode,const wchar_t *_Filename,const 
wchar_t *const *_ArgList,const wchar_t *const *_Env);
   _CRTIMP intptr_t __cdecl _wspawnvp(int _Mode,const wchar_t *_Filename,const 
wchar_t *const *_ArgList);
   _CRTIMP intptr_t __cdecl _wspawnvpe(int _Mode,const wchar_t *_Filename,const 
wchar_t *const *_ArgList,const wchar_t *const *_Env);
+#endif
+
 #ifndef _CRT_WSYSTEM_DEFINED
 #define _CRT_WSYSTEM_DEFINED
   _CRTIMP int __cdecl _wsystem(const wchar_t *_Command);
 #endif
-#endif
 
   void __cdecl __security_init_cookie(void);
 #if (defined(_X86_)  !defined(__x86_64))
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 32bcca1..825281f 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -950,6 +950,18 @@ void __cdecl __mingw_str_free(void *ptr);
 
 #endif /* __MINGW_MBWC_CONVERT_DEFINED */
 
+#ifndef _WSPAWN_DEFINED
+#define _WSPAWN_DEFINED
+  _CRTIMP intptr_t __cdecl _wspawnl(int _Mode,const wchar_t *_Filename,const 
wchar_t *_ArgList,...);
+  _CRTIMP intptr_t __cdecl _wspawnle(int _Mode,const wchar_t *_Filename,const 
wchar_t *_ArgList,...);
+  _CRTIMP intptr_t __cdecl _wspawnlp(int _Mode,const wchar_t *_Filename,const 
wchar_t *_ArgList,...);
+  _CRTIMP intptr_t __cdecl _wspawnlpe(int _Mode,const wchar_t *_Filename,const 
wchar_t *_ArgList,...);
+  _CRTIMP intptr_t __cdecl _wspawnv(int _Mode,const wchar_t *_Filename,const 
wchar_t *const *_ArgList);
+  _CRTIMP intptr_t __cdecl _wspawnve(int _Mode,const wchar_t *_Filename,const 
wchar_t *const *_ArgList,const wchar_t *const *_Env);
+  _CRTIMP intptr_t __cdecl _wspawnvp(int _Mode,const wchar_t *_Filename,const 
wchar_t *const *_ArgList);
+  _CRTIMP intptr_t __cdecl _wspawnvpe(int _Mode,const wchar_t *_Filename,const 
wchar_t *const *_ArgList,const wchar_t *const *_Env);
+#endif
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
index 3fbd17f..88cb24c 100644
--- a/mingw-w64-headers/crt/wchar.h
+++ b/mingw-w64-headers/crt/wchar.h
@@ -300,9 +300,8 @@ extern FILE (* __MINGW_IMP_SYMBOL(_iob))[]; /* A pointer to 
an array of FILE */
   _CRTIMP wchar_t *__cdecl _wsetlocale(int _Category,const wchar_t *_Locale);
 #endif
 
-#ifndef _WPROCESS_DEFINED
-#define _WPROCESS_DEFINED
-
+#ifndef _WEXEC_DEFINED
+#define _WEXEC_DEFINED
   _CRTIMP intptr_t __cdecl _wexecl(const wchar_t *_Filename,const wchar_t 
*_ArgList,...);
   _CRTIMP intptr_t __cdecl _wexecle(const wchar_t *_Filename,const wchar_t 
*_ArgList,...);
   _CRTIMP intptr_t __cdecl _wexeclp(const wchar_t *_Filename,const wchar_t 
*_ArgList,...);
@@ -311,6 +310,10 @@ extern FILE (* __MINGW_IMP_SYMBOL(_iob))[];/* A 
pointer to an array of FILE */
   _CRTIMP intptr_t __cdecl _wexecve(const wchar_t *_Filename,const wchar_t 
*const *_ArgList,const wchar_t *const *_Env);
   _CRTIMP intptr_t __cdecl _wexecvp(const wchar_t *_Filename,const wchar_t 
*const *_ArgList);
   _CRTIMP intptr_t __cdecl _wexecvpe(const wchar_t *_Filename,const wchar_t 
*const *_ArgList,const wchar_t *const *_Env);
+#endif
+
+#ifndef _WSPAWN_DEFINED
+#define _WSPAWN_DEFINED
   _CRTIMP intptr_t __cdecl _wspawnl(int _Mode,const wchar_t *_Filename,const 
wchar_t *_ArgList,...);
   

[Mingw-w64-public] [PATCH 3/3] Functions _spawnv, _spawnve, _spawnvp and _spawnvpe should be decared in both stdio.h and process.h.

[dongsheng . song]

From: 宋冬生 songdongsh...@live.cn

See http://msdn.microsoft.com/en-us/library/20y988d2.aspx
for more details.
---
 mingw-w64-headers/crt/process.h |  6 ++
 mingw-w64-headers/crt/stdio.h   | 20 
 2 files changed, 26 insertions(+)

diff --git a/mingw-w64-headers/crt/process.h b/mingw-w64-headers/crt/process.h
index 9b36daa..8034d41 100644
--- a/mingw-w64-headers/crt/process.h
+++ b/mingw-w64-headers/crt/process.h
@@ -16,6 +16,7 @@
 extern C {
 #endif
 
+#ifndef _P_WAIT
 #define _P_WAIT 0
 #define _P_NOWAIT 1
 #define _OLD_P_OVERLAY 2
@@ -25,6 +26,7 @@ extern C {
 
 #define _WAIT_CHILD 0
 #define _WAIT_GRANDCHILD 1
+#endif
 
   _CRTIMP uintptr_t __cdecl _beginthread(void (__cdecl *_StartAddress) (void 
*),unsigned _StackSize,void *_ArgList);
   _CRTIMP void __cdecl _endthread(void) __MINGW_ATTRIB_NORETURN;
@@ -68,10 +70,14 @@ extern C {
   _CRTIMP intptr_t __cdecl _spawnle(int _Mode,const char *_Filename,const char 
*_ArgList,...);
   _CRTIMP intptr_t __cdecl _spawnlp(int _Mode,const char *_Filename,const char 
*_ArgList,...);
   _CRTIMP intptr_t __cdecl _spawnlpe(int _Mode,const char *_Filename,const 
char *_ArgList,...);
+
+#ifndef _SPAWNV_DEFINED
+#define _SPAWNV_DEFINED
   _CRTIMP intptr_t __cdecl _spawnv(int _Mode,const char *_Filename,const char 
*const *_ArgList);
   _CRTIMP intptr_t __cdecl _spawnve(int _Mode,const char *_Filename,const char 
*const *_ArgList,const char *const *_Env);
   _CRTIMP intptr_t __cdecl _spawnvp(int _Mode,const char *_Filename,const char 
*const *_ArgList);
   _CRTIMP intptr_t __cdecl _spawnvpe(int _Mode,const char *_Filename,const 
char *const *_ArgList,const char *const *_Env);
+#endif
 
 #ifndef _CRT_SYSTEM_DEFINED
 #define _CRT_SYSTEM_DEFINED
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 825281f..3b49ddd 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -962,6 +962,26 @@ void __cdecl __mingw_str_free(void *ptr);
   _CRTIMP intptr_t __cdecl _wspawnvpe(int _Mode,const wchar_t *_Filename,const 
wchar_t *const *_ArgList,const wchar_t *const *_Env);
 #endif
 
+#ifndef _P_WAIT
+#define _P_WAIT 0
+#define _P_NOWAIT 1
+#define _OLD_P_OVERLAY 2
+#define _P_NOWAITO 3
+#define _P_DETACH 4
+#define _P_OVERLAY 2
+
+#define _WAIT_CHILD 0
+#define _WAIT_GRANDCHILD 1
+#endif
+
+#ifndef _SPAWNV_DEFINED
+#define _SPAWNV_DEFINED
+  _CRTIMP intptr_t __cdecl _spawnv(int _Mode,const char *_Filename,const char 
*const *_ArgList);
+  _CRTIMP intptr_t __cdecl _spawnve(int _Mode,const char *_Filename,const char 
*const *_ArgList,const char *const *_Env);
+  _CRTIMP intptr_t __cdecl _spawnvp(int _Mode,const char *_Filename,const char 
*const *_ArgList);
+  _CRTIMP intptr_t __cdecl _spawnvpe(int _Mode,const char *_Filename,const 
char *const *_ArgList,const char *const *_Env);
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.1.2


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Copy getpid declaration in process.h to unistd.h

[Dongsheng Song]

OK for apply ?

---
 mingw-w64-headers/crt/process.h | 3 +++
 mingw-w64-headers/crt/unistd.h  | 5 +
 2 files changed, 8 insertions(+)

diff --git a/mingw-w64-headers/crt/process.h b/mingw-w64-headers/crt/process.h
index f43befb..5f635c8 100644
--- a/mingw-w64-headers/crt/process.h
+++ b/mingw-w64-headers/crt/process.h
@@ -156,7 +156,10 @@ extern C {
   intptr_t __cdecl spawnle(int,const char *_Filename,const char
*_ArgList,...) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
   intptr_t __cdecl spawnlp(int,const char *_Filename,const char
*_ArgList,...) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
   intptr_t __cdecl spawnlpe(int,const char *_Filename,const char
*_ArgList,...) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+#ifndef _CRT_GETPID_DEFINED
+#define _CRT_GETPID_DEFINED  /* Also in unistd.h */
   int __cdecl getpid(void) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+#endif
 #ifdef __GNUC__
   /* Those methods are predefined by gcc builtins to return int. So to prevent
  stupid warnings, define them in POSIX way.  This is save, because those
diff --git a/mingw-w64-headers/crt/unistd.h b/mingw-w64-headers/crt/unistd.h
index 14725b2..0de8c7d 100644
--- a/mingw-w64-headers/crt/unistd.h
+++ b/mingw-w64-headers/crt/unistd.h
@@ -93,6 +93,11 @@ __CRT_INLINE int ftruncate(int __fd, _off_t __length)
   void __cdecl swab(char *_Buf1,char *_Buf2,int _SizeInBytes)
__MINGW_ATTRIB_DEPRECATED_MSVC2005;
 #endif

+#ifndef _CRT_GETPID_DEFINED
+#define _CRT_GETPID_DEFINED /* Also in process.h */
+  int __cdecl getpid(void) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+#endif
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.1.2


0001-Copy-getpid-in-process.h-declaration-to-unistd.h.patch
Description: Binary data
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Copy getpid declaration in process.h to unistd.h

[Dongsheng Song]

On Fri, Nov 7, 2014 at 4:44 PM, lh_mouse lh_mo...@126.com wrote:
 Minor suggestion: use the word `DECLARED` instead `DEFINED` please.


I don't known which is better:-)
Here is some stats:

$ grep -r _DEFINED[^A-Z0-9] . | wc -l
26145

$ grep -r _DECLARED[^A-Z0-9] . | wc -l
15

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] getpid issue

[Dongsheng Song]

On Fri, Nov 7, 2014 at 7:51 PM, Ozkan Sezer seze...@gmail.com wrote:
 On 11/7/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 On Fri, Nov 7, 2014 at 11:10 AM, Ozkan Sezer seze...@gmail.com wrote:
 On 11/7/14, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:
 2014-11-07 9:25 GMT+01:00 Ozkan Sezer seze...@gmail.com:

 On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
  If we define _POSIX_, then getpid (process.h) was hidden.
  Is it correct ?
 
  PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do not
  use _POSIX_ anymore.
  MSVC 2012/2013 guard getpid with !__STDC__.

 I believe (but not necessarily correct about iıt) that MSVC's _POSIX
 symbol is intended for diffrerent purposes, i.e. windows posix
 subsystem,
 and I believe that we are doing a wrong thing with having those _POSIX
 ifdefs in our headers..  Someone correct me if I'm wrong.


 I have no idea, but be aware at least one reference in GCC showed up:
 https://gcc.gnu.org/bugzilla/attachment.cgi?id=20034action=edit

 But maybe that's there exactly because _POSIX is in the MinGW-w64
 headers...

 I remember that they defined _POSIX only because mingw-w64 headers
 required it for certain declarations

 Also, should we consider renaming _POSIX to _POSIX_SOURCE?


 What I am saying is that those two have different meanings.
 If we ever get rid of _POSIX we will possibly need to remove
 certain stuff too. Things that currently are guarded by _POSIX
 but should actually be guarded by _POSIX_SOURCE are there too
 and they are another part of the story.


During port libressl to Windows, I feel very painful on such macros.
I want to use _POSIX_C_SOURCE to replace _POSIX, _POSIX_,
_POSIX_SOURCE in all headers.
The first is normalization in _mingw.h.in:

--- a/mingw-w64-headers/crt/_mingw.h.in
+++ b/mingw-w64-headers/crt/_mingw.h.in
@@ -7,6 +7,26 @@
 #ifndef _INC__MINGW_H
 #define _INC__MINGW_H

+#if defined(_POSIX) || defined(_POSIX_) \
+   || defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE)  \
+   || defined(_REENTRANT) || defined(_THREAD_SAFE) ||
defined(_POSIX_THREAD_SAFE_FUNCTIONS)
+
+/* This has been superseded by _POSIX_C_SOURCE. */
+#ifndef _POSIX_SOURCE
+#define _POSIX_SOURCE 1
+#endif
+
+/* Functions like wcscasecmp() and strnlen() were only added in POSIX.1-2008 */
+#ifndef _POSIX_C_SOURCE
+#define _POSIX_C_SOURCE 200809L
+#endif
+
+#if (defined(_REENTRANT) || defined(_THREAD_SAFE)) 
!defined(_POSIX_THREAD_SAFE_FUNCTIONS)
+#define _POSIX_THREAD_SAFE_FUNCTIONS 200809L
+#endif
+
+#endif
+

comments ?

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Copy getpid declaration in process.h to unistd.h

[Dongsheng Song]

On Fri, Nov 7, 2014 at 9:48 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2014-11-07 14:45 GMT+01:00 Dongsheng Song dongsheng.s...@gmail.com:

 On Fri, Nov 7, 2014 at 4:44 PM, lh_mouse lh_mo...@126.com wrote:
  Minor suggestion: use the word `DECLARED` instead `DEFINED` please.
 

 I don't known which is better:-)
 Here is some stats:

 $ grep -r _DEFINED[^A-Z0-9] . | wc -l
 26145

 $ grep -r _DECLARED[^A-Z0-9] . | wc -l
 15


 That bit in your patch is clearly declaring a function. I don't see how a
 pop poll helps decide proper wording?

 Ruben


I following the previous usage.

$ cat mingw-w64-headers/crt/unistd.h | grep _DEFINED
#ifndef FTRUNCATE_DEFINED
#define FTRUNCATE_DEFINED
#endif /* FTRUNCATE_DEFINED */
#ifndef _CRT_SWAB_DEFINED
#define _CRT_SWAB_DEFINED /* Also in stdlib.h */
#ifndef _CRT_GETPID_DEFINED
#define _CRT_GETPID_DEFINED /* Also in process.h */

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] getpid issue

[Dongsheng Song]

On Sat, Nov 8, 2014 at 12:05 AM, Ozkan Sezer seze...@gmail.com wrote:
 On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
 On Fri, Nov 7, 2014 at 7:51 PM, Ozkan Sezer seze...@gmail.com wrote:
 On 11/7/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 On Fri, Nov 7, 2014 at 11:10 AM, Ozkan Sezer seze...@gmail.com wrote:
 On 11/7/14, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:
 2014-11-07 9:25 GMT+01:00 Ozkan Sezer seze...@gmail.com:

 On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
  If we define _POSIX_, then getpid (process.h) was hidden.
  Is it correct ?
 
  PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do
  not
  use _POSIX_ anymore.
  MSVC 2012/2013 guard getpid with !__STDC__.

 I believe (but not necessarily correct about iıt) that MSVC's _POSIX
 symbol is intended for diffrerent purposes, i.e. windows posix
 subsystem,
 and I believe that we are doing a wrong thing with having those _POSIX
 ifdefs in our headers..  Someone correct me if I'm wrong.


 I have no idea, but be aware at least one reference in GCC showed up:
 https://gcc.gnu.org/bugzilla/attachment.cgi?id=20034action=edit

 But maybe that's there exactly because _POSIX is in the MinGW-w64
 headers...

 I remember that they defined _POSIX only because mingw-w64 headers
 required it for certain declarations

 Also, should we consider renaming _POSIX to _POSIX_SOURCE?


 What I am saying is that those two have different meanings.
 If we ever get rid of _POSIX we will possibly need to remove
 certain stuff too. Things that currently are guarded by _POSIX
 but should actually be guarded by _POSIX_SOURCE are there too
 and they are another part of the story.


 During port libressl to Windows, I feel very painful on such macros.
 I want to use _POSIX_C_SOURCE to replace _POSIX, _POSIX_,
 _POSIX_SOURCE in all headers.
 The first is normalization in _mingw.h.in:

 --- a/mingw-w64-headers/crt/_mingw.h.in
 +++ b/mingw-w64-headers/crt/_mingw.h.in
 @@ -7,6 +7,26 @@
  #ifndef _INC__MINGW_H
  #define _INC__MINGW_H

 +#if defined(_POSIX) || defined(_POSIX_) \
 +   || defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE)  \
 +   || defined(_REENTRANT) || defined(_THREAD_SAFE) ||
 defined(_POSIX_THREAD_SAFE_FUNCTIONS)
 +
 +/* This has been superseded by _POSIX_C_SOURCE. */
 +#ifndef _POSIX_SOURCE
 +#define _POSIX_SOURCE 1
 +#endif
 +
 +/* Functions like wcscasecmp() and strnlen() were only added in
 POSIX.1-2008 */
 +#ifndef _POSIX_C_SOURCE
 +#define _POSIX_C_SOURCE 200809L
 +#endif
 +
 +#if (defined(_REENTRANT) || defined(_THREAD_SAFE)) 
 !defined(_POSIX_THREAD_SAFE_FUNCTIONS)
 +#define _POSIX_THREAD_SAFE_FUNCTIONS 200809L
 +#endif
 +
 +#endif
 +

 comments ?

 I'd say that this is lazy and wrong.  IMO, doing it right way should be
 changing the correct (only the correct) _POSIX guards to _POSIX_SOURCE
 instead, and hope that the project requesting such features are actually
 defining _POSIX_SOURCE. (you should possily also cover _GNU_SOURCE, etc)

 --
 O.S.


If you use _POSIX_SOURCE guard, no more _POSIX guard, you must make
_POSIX_SOURCE defined automatically when _POSIX defined for
compatibility.

PS：_POSIX_SOURCE has been superseded by _POSIX_C_SOURCE.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] rand_r location

[Dongsheng Song]

On Fri, Nov 7, 2014 at 7:03 AM, Martell Malone martellmal...@gmail.com wrote:
 Here is a patch to move rand_r from pthread.h to stdlib.h
 Typical POSIX programs expect this to be in stdlib

 Very similar to the previously applied patches in moving localtime_r.
 Using the same guards to try best to ensure legacy support with
 win32-pthreads.

 Comments and suggestions are welcome

 Martell


Looks good to me, I like it.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] getpid issue

[Dongsheng Song]

If we define _POSIX_, then getpid (process.h) was hidden.
Is it correct ?

PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do not
use _POSIX_ anymore.
MSVC 2012/2013 guard getpid with !__STDC__.

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] unistd.h: Added definitions for SHUT_RD, SHUT_WR and SHUT_RDWR.

[Dongsheng Song]

OK for apply ?

---
 mingw-w64-headers/crt/unistd.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/mingw-w64-headers/crt/unistd.h b/mingw-w64-headers/crt/unistd.h
index 919a377..5763a35 100644
--- a/mingw-w64-headers/crt/unistd.h
+++ b/mingw-w64-headers/crt/unistd.h
@@ -25,6 +25,18 @@
 #define STDERR_FILENO 2
 #endif

+/* Used by shutdown(2). */
+#ifdef _POSIX_SOURCE
+
+/* MySql connector already defined SHUT_RDWR. */
+#ifndef SHUT_RDWR
+#define SHUT_RD   0x00
+#define SHUT_WR   0x01
+#define SHUT_RDWR 0x02
+#endif
+
+#endif
+
 #ifdef __cplusplus
 extern C {
 #endif
--
2.1.2

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mstcpip.h: Added definitions for RCVALL_IPLEVEL.

[Dongsheng Song]

On Fri, Oct 24, 2014 at 11:57 PM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
 When I write raw socket program, I found RCVALL_IPLEVEL missing, so
 here is the patch.

 Please review.

 ---
  mingw-w64-headers/include/mstcpip.h |1 +
  1 file changed, 1 insertion(+)

 diff --git a/mingw-w64-headers/include/mstcpip.h
 b/mingw-w64-headers/include/mstcpip.h
 index 99e57ab..b040ba7 100644
 --- a/mingw-w64-headers/include/mstcpip.h
 +++ b/mingw-w64-headers/include/mstcpip.h
 @@ -36,6 +36,7 @@ struct tcp_keepalive {
  #define RCVALL_OFF 0
  #define RCVALL_ON 1
  #define RCVALL_SOCKETLEVELONLY 2
 +#define RCVALL_IPLEVEL 3

  #if (_WIN32_WINNT = 0x0502)
  typedef enum _SOCKET_SECURITY_PROTOCOL {
 --
 1.7.10.4

ping.

Can I push it and cherry-pick to v3.x ?

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] mstcpip.h: Added definitions for RCVALL_IPLEVEL.

[Dongsheng Song]

When I write raw socket program, I found RCVALL_IPLEVEL missing, so
here is the patch.

Please review.

---
 mingw-w64-headers/include/mstcpip.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/mingw-w64-headers/include/mstcpip.h
b/mingw-w64-headers/include/mstcpip.h
index 99e57ab..b040ba7 100644
--- a/mingw-w64-headers/include/mstcpip.h
+++ b/mingw-w64-headers/include/mstcpip.h
@@ -36,6 +36,7 @@ struct tcp_keepalive {
 #define RCVALL_OFF 0
 #define RCVALL_ON 1
 #define RCVALL_SOCKETLEVELONLY 2
+#define RCVALL_IPLEVEL 3

 #if (_WIN32_WINNT = 0x0502)
 typedef enum _SOCKET_SECURITY_PROTOCOL {
--
1.7.10.4

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] _mingw.h.in: drop 'extern' from __forceinline macro

[Dongsheng Song]

The daily build report errors on the commit:

/home/cauchy/cross/i686-windows-gcc-4.9/i686-w64-mingw32/include/winbase.h:999:
multiple definition of `InterlockedIncrement64'
/home/cauchy/obj/i686-w64-mingw32-gcc-4.9/gcc/./gcc/crtbegin.o:cygming-crtbegin.c:(.text+0x200):
first defined here
emutls_s.o: In function `InterlockedDecrement64':

--
Dongsheng


On Tue, Sep 30, 2014 at 10:12 PM, JonY jo...@users.sourceforge.net wrote:
 On 9/30/2014 18:56, Marat Radchenko wrote:
 On Tue, Sep 30, 2014 at 06:49:42PM +0800, JonY wrote:
 On 9/28/2014 20:29, Marat Radchenko wrote:
  1. In 6500e4fd, FORCEINLINE in winnt.h was fixed to omit 'extern'
  2. In d66ee5e8, FORCEINLINE was also fixed in ntdef.h


 Hi,

 Sorry about the slow reply, but what does removing extern do?

 Removing extern fixes `static FORCEINLINE` functions: function
 can't be static and extern at the same time.

 Should it be:
 __forceinline static __inline__ __attribute__((__always_inline__))

 for all cases? So no actual definitions are ever emitted?



 No. Typical forceinline usage is `static FORCEINLINE void foo(bar)`:

 If you add `static` to macro, `static` will appear twice on final definition.


 Done, removed from master.



 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fix compile error in commctrl.h

[Dongsheng Song]

Did ARM target support these features or defined _WIN32 ?

On Wed, Sep 3, 2014 at 3:27 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Hi,

 To move code up is ok.  Patch is ok, but one nit.  Why do you check
 here _WIN32 as guard.  Do we have targets where _WIN32 isn't defined?

 Cheers,
 Kai

 2014-09-03 5:33 GMT+02:00 Dongsheng Song dongsheng.s...@gmail.com:
 Hi,

 This patch fix compile error in commctrl.h

 Ok for apply?

 Regards,
 Dongsheng


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fix compile error in commctrl.h

[Dongsheng Song]

Thanks, pushed without _WIN32 guard.

On Wed, Sep 3, 2014 at 6:18 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Sure, it has to.

 Kai

 2014-09-03 12:06 GMT+02:00 Dongsheng Song dongsheng.s...@gmail.com:
 Did ARM target support these features or defined _WIN32 ?

 On Wed, Sep 3, 2014 at 3:27 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Hi,

 To move code up is ok.  Patch is ok, but one nit.  Why do you check
 here _WIN32 as guard.  Do we have targets where _WIN32 isn't defined?

 Cheers,
 Kai

 2014-09-03 5:33 GMT+02:00 Dongsheng Song dongsheng.s...@gmail.com:
 Hi,

 This patch fix compile error in commctrl.h

 Ok for apply?

 Regards,
 Dongsheng


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Fix compile error in commctrl.h

[Dongsheng Song]

Hi,

This patch fix compile error in commctrl.h

Ok for apply?

Regards,
Dongsheng

From 8b0831b0a5b778379f50023e6c8e16c8851f8a43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E5=86=AC=E7=94=9F?= dongsheng.s...@gmail.com
Date: Wed, 3 Sep 2014 10:57:19 +0800
Subject: [PATCH] Fix compile error in commctrl.h

---
 mingw-w64-headers/include/commctrl.h |   55 +-
 1 file changed, 28 insertions(+), 27 deletions(-)

diff --git a/mingw-w64-headers/include/commctrl.h 
b/mingw-w64-headers/include/commctrl.h
index 8e694fc..3c51da3 100644
--- a/mingw-w64-headers/include/commctrl.h
+++ b/mingw-w64-headers/include/commctrl.h
@@ -2194,6 +2194,33 @@ extern C {
 #define CCS_RIGHT (CCS_VERT | CCS_BOTTOM)
 #define CCS_NOMOVEX (CCS_VERT | CCS_NOMOVEY)
 
+#ifdef _WIN32
+#define INVALID_LINK_INDEX (-1)
+#define MAX_LINKID_TEXT 48
+#define L_MAX_URL_LENGTH (2048+32+sizeof(://))
+
+#define WC_LINK LSysLink
+
+  typedef struct tagLITEM {
+UINT mask;
+int iLink;
+UINT state;
+UINT stateMask;
+WCHAR szID[MAX_LINKID_TEXT];
+WCHAR szUrl[L_MAX_URL_LENGTH];
+  } LITEM,*PLITEM;
+
+  typedef struct tagLHITTESTINFO {
+POINT pt;
+LITEM item;
+  } LHITTESTINFO,*PLHITTESTINFO;
+
+  typedef struct tagNMLINK {
+NMHDR hdr;
+LITEM item;
+  } NMLINK,*PNMLINK;
+#endif
+
 #ifndef NOLISTVIEW
 
 #define WC_LISTVIEWA SysListView32
@@ -5109,12 +5136,6 @@ typedef struct tagTVDISPINFOEXW {
 
 #endif
 
-#define INVALID_LINK_INDEX (-1)
-#define MAX_LINKID_TEXT 48
-#define L_MAX_URL_LENGTH (2048+32+sizeof(://))
-
-#define WC_LINK LSysLink
-
 #define LWS_TRANSPARENT 0x1
 #define LWS_IGNORERETURN 0x2
 #if NTDDI_VERSION = 0x0600
@@ -5136,25 +5157,6 @@ typedef struct tagTVDISPINFOEXW {
 #define LIS_DEFAULTCOLORS 0x10
 #endif
 
-  typedef struct tagLITEM {
-UINT mask;
-int iLink;
-UINT state;
-UINT stateMask;
-WCHAR szID[MAX_LINKID_TEXT];
-WCHAR szUrl[L_MAX_URL_LENGTH];
-  } LITEM,*PLITEM;
-
-  typedef struct tagLHITTESTINFO {
-POINT pt;
-LITEM item;
-  } LHITTESTINFO,*PLHITTESTINFO;
-
-  typedef struct tagNMLINK {
-NMHDR hdr;
-LITEM item;
-  } NMLINK,*PNMLINK;
-
 #define LM_HITTEST (WM_USER+0x300)
 #define LM_GETIDEALHEIGHT (WM_USER+0x301)
 #define LM_SETITEM (WM_USER+0x302)
@@ -5343,8 +5345,7 @@ typedef struct tagTVDISPINFOEXW {
 #if NTDDI_VERSION = 0x0600
   WINCOMMCTRLAPI HDSA WINAPI DSA_Clone (HDSA hdsa);
   WINCOMMCTRLAPI ULONGLONG WINAPI DSA_GetSize (HDSA hdsa);
-  WINCOMMCTRLAPI WINBOOL WINAPI DSA_Sort (HDSA pdsa, PFNDACOMPARE pfnCompare, 
LP
-ARAM lParam);
+  WINCOMMCTRLAPI WINBOOL WINAPI DSA_Sort (HDSA pdsa, PFNDACOMPARE pfnCompare, 
LPARAM lParam);
 #ifdef __cplusplus
   extern C++ __inline WINBOOL DSA_Sort (HDSA hdsa, PFNDACOMPARECONST 
pfnCompare, LPARAM lParam) {
 return DSA_Sort (hdsa,(PFNDACOMPARE) (pfnCompare), lParam);
-- 
1.7.10.4

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Move syslink control constants behind of common control styles.

[Dongsheng Song]

Please ignore this patch, it's not complete.

On Wed, Sep 3, 2014 at 10:45 AM, 宋冬生 dongsheng.s...@gmail.com wrote:
 This commit fix this compiler error:

 commctrl.h:3360:20: error: 'L_MAX_URL_LENGTH' undeclared here (not in a 
 function)
  WCHAR szMarkup[L_MAX_URL_LENGTH];
 ---
  mingw-w64-headers/include/commctrl.h |   14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

 diff --git a/mingw-w64-headers/include/commctrl.h 
 b/mingw-w64-headers/include/commctrl.h
 index 8e694fc..56bf32c 100644
 --- a/mingw-w64-headers/include/commctrl.h
 +++ b/mingw-w64-headers/include/commctrl.h
 @@ -2194,6 +2194,14 @@ extern C {
  #define CCS_RIGHT (CCS_VERT | CCS_BOTTOM)
  #define CCS_NOMOVEX (CCS_VERT | CCS_NOMOVEY)

 +#ifdef _WIN32
 +#define INVALID_LINK_INDEX (-1)
 +#define MAX_LINKID_TEXT 48
 +#define L_MAX_URL_LENGTH (2048+32+sizeof(://))
 +
 +#define WC_LINK LSysLink
 +#endif
 +
  #ifndef NOLISTVIEW

  #define WC_LISTVIEWA SysListView32
 @@ -5109,12 +5117,6 @@ typedef struct tagTVDISPINFOEXW {

  #endif

 -#define INVALID_LINK_INDEX (-1)
 -#define MAX_LINKID_TEXT 48
 -#define L_MAX_URL_LENGTH (2048+32+sizeof(://))
 -
 -#define WC_LINK LSysLink
 -
  #define LWS_TRANSPARENT 0x1
  #define LWS_IGNORERETURN 0x2
  #if NTDDI_VERSION = 0x0600
 --
 1.7.10.4


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] r212448 - in /trunk: gcc/ChangeLog gcc/Makefile...

[Dongsheng Song]

Thank you very much, sorry for the delay response.

With '--disable-gcov-tool', gcc 4.10 can be build successfully.
Both patch2 and patch3 failed, please found the attachment for details.

--
Dongsheng

On Tue, Aug 12, 2014 at 2:29 AM, Rong Xu x...@google.com wrote:

 Here is the patch that makes the build of gcov-tool configurable.
 --disable-gcov-tool to disable the build.

 Note the default is to build gcov-tool for mingw. Please help to test
 this. Thanks,

 -Rong



 On Fri, Aug 8, 2014 at 2:28 PM, Rong Xu x...@google.com wrote:
  OK. I'll work on this.
 
  At the same time, could you try the attached patch which fixes the
  problems mentioned in patchset1?
  I had hard time to setup your build environment.
 
  -Rong
 
  On Fri, Aug 8, 2014 at 1:27 AM, Dongsheng Song dongsheng.s...@gmail.com 
  wrote:
  On Fri, Jul 25, 2014 at 5:16 PM, JonY jo...@users.sourceforge.net wrote:
  On 7/25/2014 12:36, Dongsheng Song wrote:
  This just fix the ftw issue. But still have %lld, mkdir, GCC poison
  strerror issue on gcov.
  You can following the build instructions at:
 
  http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-doc/howto-build/mingw-w64-howto-build.txt
 
 
  The guide is fairly outdated, please use mingw-w64 from git and
  disregard the part about SVN checkout.
 
  Link: git://git.code.sf.net/p/mingw-w64/mingw-w64
 
 
  Hi Rong,
 
  Could you add an build argument like '--disable-gcov' to make gcc
  trunk buildable for Windows ?
 
  Thanks,
  Dongsheng


gcov-win32_patch2.log
Description: Binary data


gcov-win32_patch3.log
Description: Binary data
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw32-w64 32bit access violation under 32bit OS and under wow64 it works

[Dongsheng Song]

On Fri, Aug 22, 2014 at 11:14 PM, Stefan Ruppert s...@myarm.com wrote:
 Hi all,

 I have the following problem. I managed to compile our software which
 uses Qt 4.8.6 with g++ mingw32-w64 (rubenvb-4.7.2-release) in 32bit mode
 on a 64bit Windows 7 machine. All parts of our software runs correctly
 in wow64 and in a 32bit Windows 7 native environment except all
 applications which uses Qt.

 Any application which uses Qt works fine in wow64, but not in a 32bit
 native windows 7 environment. QtCore4.dll crashes with a access
 violation directly after loaded into memory (checked with dependency
 walker).

 Any idea what could cause this strange behaviour? I have no idea whats
 going wrong in native 32bit env...

 Regards,
 Stefan


Please use gdb to run your application, and give the back trace when it crashed,
then decode some instructions ('x/10i current-ip').

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ICE caused by using __builtin_ia32_pause() inside C++11 noexcept functions

[Dongsheng Song]

On Fri, Aug 15, 2014 at 10:41 AM, lh_mouse lh_mo...@126.com wrote:
 // ice.cpp
 void foo() noexcept {
 __builtin_ia32_pause();
 }
 // EOF

 The above code will result in an ICE when compiled to i686 code:

 E:\Desktopg++ ice.cpp -std=c++14 -m32 -c
 ice.cpp: In function 'void foo()':
 ice.cpp:3:1: internal compiler error: in ix86_compute_frame_layout, at 
 config/i386/i386.c:9510
  }
  ^
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See http://sourceforge.net/projects/mingw-w64 for instructions.

 If compiled to x86_64 code it won't ICE on Windows. Neither on linux does it 
 ICE. (gcc 4.9.0)
 Any ideas?

Confirmed. This is a gcc assert failed:

gcc_assert (preferred_alignment = stack_alignment_needed);

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] r212448 - in /trunk: gcc/ChangeLog gcc/Makefile...

[Dongsheng Song]

On Fri, Jul 25, 2014 at 5:16 PM, JonY jo...@users.sourceforge.net wrote:
 On 7/25/2014 12:36, Dongsheng Song wrote:
 This just fix the ftw issue. But still have %lld, mkdir, GCC poison
 strerror issue on gcov.
 You can following the build instructions at:

 http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-doc/howto-build/mingw-w64-howto-build.txt


 The guide is fairly outdated, please use mingw-w64 from git and
 disregard the part about SVN checkout.

 Link: git://git.code.sf.net/p/mingw-w64/mingw-w64


Hi Rong,

Could you add an build argument like '--disable-gcov' to make gcc
trunk buildable for Windows ?

Thanks,
Dongsheng

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Patch] Add memmove_s emu

[Dongsheng Song]

This commit broken the gcc 4.9 building:

$ make
make  all-am
make[1]: Entering directory
`/home/cauchy/obj/x86_64-w64-mingw32-gcc-4.9/mingw-w64-crt'
make[1]: *** No rule to make target `secapi/memmove_s.c', needed by
`secapi/lib64_libmsvcrt_a-memmove_s.o'.  Stop.
make[1]: Leaving directory
`/home/cauchy/obj/x86_64-w64-mingw32-gcc-4.9/mingw-w64-crt'
make: *** [all] Error 2


You forgot commit memmove_s.c

On Wed, Jul 30, 2014 at 6:37 PM, JonY jo...@users.sourceforge.net wrote:

 On 7/29/2014 04:04, Ruben De Smet wrote:
  Some applications, like CryptoPP, won't run on Windows XP, because
  memmove_s isn't defined in that OS. As I needed CryptoPP to compile
  easily, I wrote this patch. It emulates the method by checking for the
  availability and falling back on memmove (without s).
 
  I mimicked memcpy_s.
 
  I'm not subscribed to the list, so please make sure my email address is
  in the recipients list when replying on this email.
 

 Thanks, applied to master.



 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.
 http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] r212448 - in /trunk: gcc/ChangeLog gcc/Makefile...

[Dongsheng Song]

This just fix the ftw issue. But still have %lld, mkdir, GCC poison
strerror issue on gcov.
You can following the build instructions at:

http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-doc/howto-build/mingw-w64-howto-build.txt

Regards,
Dongsheng

On Thu, Jul 24, 2014 at 2:38 AM, Rong Xu x...@google.com wrote:
 +cc honza

 Here is the patch I created to fix the issue. The problem is I don't
 know how to test it. Can you give me the instructions for you build,
 or you can test it for me (at least the build part).

 Thanks,

 -Rong

 On Wed, Jul 16, 2014 at 2:44 AM, Dongsheng Song
 dongsheng.s...@gmail.com wrote:
 On Wed, Jul 16, 2014 at 12:37 AM, Rong Xu x...@google.com wrote:
 On Mon, Jul 14, 2014 at 11:02 PM, Dongsheng Song
 dongsheng.s...@gmail.com wrote:
 Hi Rong,

 Your commit r212448 broken Windows target 4 days.
 Since windows target no ftw.h, this caused the following errors:

 Sorry for this. Do you know if there is a similar API in windows?
 If the answer is no, I will have to disable gcov-tool in windows.


 Windows have FindFirstFile/FindNextFile/FindClose.

 PS: The ftw() function is marked obsolescent.
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/ftw.html

 Thanks,

 -Rong


 make[2]: Entering directory
 `/home/cauchy/obj/native/gcc-4.10-win64/gcc/libdecnumber'
 make[2]: Nothing to be done for `all'.
 make[2]: Leaving directory
 `/home/cauchy/obj/native/gcc-4.10-win64/gcc/libdecnumber'
 make[2]: Entering directory 
 `/home/cauchy/obj/native/gcc-4.10-win64/gcc/gcc'
 x86_64-w64-mingw32-g++ -c   -g -O2 -DIN_GCC-fno-exceptions
 -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
 -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
 -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
 -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/.
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include
 -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./gmp
 -I/home/cauchy/vcs/svn/gcc/trunk/gmp
 -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./mpfr/src
 -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src
 -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid
 -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace
 -DCLOOG_INT_GMP
 -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./cloog/include
 -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include
 -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./isl/include
 -I/home/cauchy/vcs/svn/gcc/trunk/isl/include  -o gcov-tool.o -MT
 gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo
 /home/cauchy/vcs/svn/gcc/trunk/gcc/gcov-tool.c
 /home/cauchy/vcs/svn/gcc/trunk/gcc/gcov-tool.c:38:17: fatal error:
 ftw.h: No such file or directory
  #include ftw.h
  ^
 compilation terminated.
 make[2]: *** [gcov-tool.o] Error 1
 make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.10-win64/gcc/gcc'
 make[1]: *** [all-gcc] Error 2
 make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.10-win64/gcc'
 make: *** [all] Error 2

 Regards,
 Dongsheng

 On Fri, Jul 11, 2014 at 1:48 PM,  x...@gcc.gnu.org wrote:
 Author: xur
 Date: Fri Jul 11 05:48:07 2014
 New Revision: 212448

 URL: https://gcc.gnu.org/viewcvs?rev=212448root=gccview=rev
 Log:
 2014-07-10  Rong Xu  x...@google.com

 Add gcov-tool: an offline gcda profile processing tool
 Support.
 * gcc/gcov-io.c (gcov_position): Make avaialble to gcov-tool.
 (gcov_is_error): Ditto.
 (gcov_read_string): Ditto.
 (gcov_read_sync): Ditto.
 * gcc/gcov-io.h: Move counter defines to gcov-counter.def.
 * gcc/gcov-dump.c (tag_counters): Use gcov-counter.def.
 * gcc/coverage.c: Ditto.
 * gcc/gcov-tool.c: Offline gcda profile processing tool.
 (unlink_gcda_file): Remove one gcda file.
 (unlink_profile_dir): Remove gcda files from the profile path.
 (gcov_output_files): Output gcda files to an output dir.
 (profile_merge): Merge two profiles in directory.
 (print_merge_usage_message): Print merge usage.
 (merge_usage): Print merge usage and exit.
 (do_merge): Driver for profile merge sub-command.
 (profile_rewrite): Rewrite profile.
 (print_rewrite_usage_message): Print rewrite usage.
 (rewrite_usage): Print rewrite usage and exit.
 (do_rewrite): Driver for profile rewrite sub-command.
 (print_usage): Print gcov-info usage and exit.
 (print_version): Print gcov-info version.
 (process_args): Process arguments.
 (main): Main routine for gcov-tool.
 * gcc/Makefile.in: Build and install gcov-tool.
 * gcc/gcov-counter.def: New file split from gcov-io.h.
 * libgcc/libgcov-driver.c (gcov_max_filename): Make available
 to gcov-tool

Re: [Mingw-w64-public] r212448 - in /trunk: gcc/ChangeLog gcc/Makefile...

[Dongsheng Song]

On Wed, Jul 16, 2014 at 12:37 AM, Rong Xu x...@google.com wrote:
 On Mon, Jul 14, 2014 at 11:02 PM, Dongsheng Song
 dongsheng.s...@gmail.com wrote:
 Hi Rong,

 Your commit r212448 broken Windows target 4 days.
 Since windows target no ftw.h, this caused the following errors:

 Sorry for this. Do you know if there is a similar API in windows?
 If the answer is no, I will have to disable gcov-tool in windows.


Windows have FindFirstFile/FindNextFile/FindClose.

PS: The ftw() function is marked obsolescent.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/ftw.html

 Thanks,

 -Rong


 make[2]: Entering directory
 `/home/cauchy/obj/native/gcc-4.10-win64/gcc/libdecnumber'
 make[2]: Nothing to be done for `all'.
 make[2]: Leaving directory
 `/home/cauchy/obj/native/gcc-4.10-win64/gcc/libdecnumber'
 make[2]: Entering directory `/home/cauchy/obj/native/gcc-4.10-win64/gcc/gcc'
 x86_64-w64-mingw32-g++ -c   -g -O2 -DIN_GCC-fno-exceptions
 -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
 -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
 -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
 -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/.
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include
 -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./gmp
 -I/home/cauchy/vcs/svn/gcc/trunk/gmp
 -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./mpfr/src
 -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src
 -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber
 -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid
 -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace
 -DCLOOG_INT_GMP
 -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./cloog/include
 -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include
 -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./isl/include
 -I/home/cauchy/vcs/svn/gcc/trunk/isl/include  -o gcov-tool.o -MT
 gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo
 /home/cauchy/vcs/svn/gcc/trunk/gcc/gcov-tool.c
 /home/cauchy/vcs/svn/gcc/trunk/gcc/gcov-tool.c:38:17: fatal error:
 ftw.h: No such file or directory
  #include ftw.h
  ^
 compilation terminated.
 make[2]: *** [gcov-tool.o] Error 1
 make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.10-win64/gcc/gcc'
 make[1]: *** [all-gcc] Error 2
 make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.10-win64/gcc'
 make: *** [all] Error 2

 Regards,
 Dongsheng

 On Fri, Jul 11, 2014 at 1:48 PM,  x...@gcc.gnu.org wrote:
 Author: xur
 Date: Fri Jul 11 05:48:07 2014
 New Revision: 212448

 URL: https://gcc.gnu.org/viewcvs?rev=212448root=gccview=rev
 Log:
 2014-07-10  Rong Xu  x...@google.com

 Add gcov-tool: an offline gcda profile processing tool
 Support.
 * gcc/gcov-io.c (gcov_position): Make avaialble to gcov-tool.
 (gcov_is_error): Ditto.
 (gcov_read_string): Ditto.
 (gcov_read_sync): Ditto.
 * gcc/gcov-io.h: Move counter defines to gcov-counter.def.
 * gcc/gcov-dump.c (tag_counters): Use gcov-counter.def.
 * gcc/coverage.c: Ditto.
 * gcc/gcov-tool.c: Offline gcda profile processing tool.
 (unlink_gcda_file): Remove one gcda file.
 (unlink_profile_dir): Remove gcda files from the profile path.
 (gcov_output_files): Output gcda files to an output dir.
 (profile_merge): Merge two profiles in directory.
 (print_merge_usage_message): Print merge usage.
 (merge_usage): Print merge usage and exit.
 (do_merge): Driver for profile merge sub-command.
 (profile_rewrite): Rewrite profile.
 (print_rewrite_usage_message): Print rewrite usage.
 (rewrite_usage): Print rewrite usage and exit.
 (do_rewrite): Driver for profile rewrite sub-command.
 (print_usage): Print gcov-info usage and exit.
 (print_version): Print gcov-info version.
 (process_args): Process arguments.
 (main): Main routine for gcov-tool.
 * gcc/Makefile.in: Build and install gcov-tool.
 * gcc/gcov-counter.def: New file split from gcov-io.h.
 * libgcc/libgcov-driver.c (gcov_max_filename): Make available
 to gcov-tool.
 * libgcc/libgcov-merge.c (__gcov_merge_add): Replace
 gcov_read_counter() with a Macro.
 (__gcov_merge_ior): Ditto.
 (__gcov_merge_time_profile): Ditto.
 (__gcov_merge_single): Ditto.
 (__gcov_merge_delta): Ditto.
 * libgcc/libgcov-util.c (void gcov_set_verbose): Set the verbose 
 flag
 in the utility functions.
 (set_fn_ctrs): Utility function for reading gcda files to in-memory
 gcov_list object link lists.
 (tag_function): Ditto.
 (tag_blocks): Ditto.
 (tag_arcs): Ditto.
 (tag_lines): Ditto.
 (tag_counters): Ditto

Re: [Mingw-w64-public] r212448 - in /trunk: gcc/ChangeLog gcc/Makefile...

[Dongsheng Song]

Hi Rong,

Your commit r212448 broken Windows target 4 days.
Since windows target no ftw.h, this caused the following errors:

make[2]: Entering directory
`/home/cauchy/obj/native/gcc-4.10-win64/gcc/libdecnumber'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/cauchy/obj/native/gcc-4.10-win64/gcc/libdecnumber'
make[2]: Entering directory `/home/cauchy/obj/native/gcc-4.10-win64/gcc/gcc'
x86_64-w64-mingw32-g++ -c   -g -O2 -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I/home/cauchy/vcs/svn/gcc/trunk/gcc
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/.
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include
-I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./gmp
-I/home/cauchy/vcs/svn/gcc/trunk/gmp
-I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./mpfr/src
-I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src
-I/home/cauchy/vcs/svn/gcc/trunk/mpc/src
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid
-I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace
-DCLOOG_INT_GMP
-I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./cloog/include
-I/home/cauchy/vcs/svn/gcc/trunk/cloog/include
-I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./isl/include
-I/home/cauchy/vcs/svn/gcc/trunk/isl/include  -o gcov-tool.o -MT
gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo
/home/cauchy/vcs/svn/gcc/trunk/gcc/gcov-tool.c
/home/cauchy/vcs/svn/gcc/trunk/gcc/gcov-tool.c:38:17: fatal error:
ftw.h: No such file or directory
 #include ftw.h
 ^
compilation terminated.
make[2]: *** [gcov-tool.o] Error 1
make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.10-win64/gcc/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.10-win64/gcc'
make: *** [all] Error 2

Regards,
Dongsheng

On Fri, Jul 11, 2014 at 1:48 PM,  x...@gcc.gnu.org wrote:
 Author: xur
 Date: Fri Jul 11 05:48:07 2014
 New Revision: 212448

 URL: https://gcc.gnu.org/viewcvs?rev=212448root=gccview=rev
 Log:
 2014-07-10  Rong Xu  x...@google.com

 Add gcov-tool: an offline gcda profile processing tool
 Support.
 * gcc/gcov-io.c (gcov_position): Make avaialble to gcov-tool.
 (gcov_is_error): Ditto.
 (gcov_read_string): Ditto.
 (gcov_read_sync): Ditto.
 * gcc/gcov-io.h: Move counter defines to gcov-counter.def.
 * gcc/gcov-dump.c (tag_counters): Use gcov-counter.def.
 * gcc/coverage.c: Ditto.
 * gcc/gcov-tool.c: Offline gcda profile processing tool.
 (unlink_gcda_file): Remove one gcda file.
 (unlink_profile_dir): Remove gcda files from the profile path.
 (gcov_output_files): Output gcda files to an output dir.
 (profile_merge): Merge two profiles in directory.
 (print_merge_usage_message): Print merge usage.
 (merge_usage): Print merge usage and exit.
 (do_merge): Driver for profile merge sub-command.
 (profile_rewrite): Rewrite profile.
 (print_rewrite_usage_message): Print rewrite usage.
 (rewrite_usage): Print rewrite usage and exit.
 (do_rewrite): Driver for profile rewrite sub-command.
 (print_usage): Print gcov-info usage and exit.
 (print_version): Print gcov-info version.
 (process_args): Process arguments.
 (main): Main routine for gcov-tool.
 * gcc/Makefile.in: Build and install gcov-tool.
 * gcc/gcov-counter.def: New file split from gcov-io.h.
 * libgcc/libgcov-driver.c (gcov_max_filename): Make available
 to gcov-tool.
 * libgcc/libgcov-merge.c (__gcov_merge_add): Replace
 gcov_read_counter() with a Macro.
 (__gcov_merge_ior): Ditto.
 (__gcov_merge_time_profile): Ditto.
 (__gcov_merge_single): Ditto.
 (__gcov_merge_delta): Ditto.
 * libgcc/libgcov-util.c (void gcov_set_verbose): Set the verbose flag
 in the utility functions.
 (set_fn_ctrs): Utility function for reading gcda files to in-memory
 gcov_list object link lists.
 (tag_function): Ditto.
 (tag_blocks): Ditto.
 (tag_arcs): Ditto.
 (tag_lines): Ditto.
 (tag_counters): Ditto.
 (tag_summary): Ditto.
 (read_gcda_finalize): Ditto.
 (read_gcda_file): Ditto.
 (ftw_read_file): Ditto.
 (read_profile_dir_init): Ditto.
 (gcov_read_profile_dir): Ditto.
 (gcov_read_counter_mem): Ditto.
 (gcov_get_merge_weight): Ditto.
 (merge_wrapper): A wrapper function that calls merging handler.
 (gcov_merge): Merge two gcov_info objects with weights.
 (find_match_gcov_info): Find the matched gcov_info in the list.
 

Re: [Mingw-w64-public] r210215 - in /trunk/gcc: ChangeLog wide-int.cc

[Dongsheng Song]

i686-w64-mingw32 daily build failed: error: unable to emulate 'TI'

...
make[2]: Leaving directory
`/home/cauchy/obj/native/gcc-4.10-win32/gcc/libdecnumber'
make[2]: Entering directory `/home/cauchy/obj/native/gcc-4.10-win32/gcc/gcc'
i686-w64-mingw32-g++ -c   -g -O2 -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-DHAVE_CONFIG_H -I. -I. -I/home/cauchy/vcs/svn/gcc/trunk/gcc
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/.
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include
-I/home/cauchy/obj/native/gcc-4.10-win32/gcc/./gmp
-I/home/cauchy/vcs/svn/gcc/trunk/gmp
-I/home/cauchy/obj/native/gcc-4.10-win32/gcc/./mpfr/src
-I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src
-I/home/cauchy/vcs/svn/gcc/trunk/mpc/src
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber
-I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid
-I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace
-DCLOOG_INT_GMP
-I/home/cauchy/obj/native/gcc-4.10-win32/gcc/./cloog/include
-I/home/cauchy/vcs/svn/gcc/trunk/cloog/include
-I/home/cauchy/vcs/svn/gcc/trunk/cloog/include
-I/home/cauchy/obj/native/gcc-4.10-win32/gcc/./isl/include
-I/home/cauchy/vcs/svn/gcc/trunk/isl/include  -o wide-int.o -MT
wide-int.o -MMD -MP -MF ./.deps/wide-int.TPo
/home/cauchy/vcs/svn/gcc/trunk/gcc/wide-int.cc
/home/cauchy/vcs/svn/gcc/trunk/gcc/wide-int.cc:37:56: error: unable to
emulate 'TI'
 typedef unsigned int UTItype __attribute__ ((mode (TI)));
^
make[2]: *** [wide-int.o] Error 1
make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.10-win32/gcc/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.10-win32/gcc'
make: *** [all] Error 2


On Thu, May 8, 2014 at 10:23 PM,  ram...@gcc.gnu.org wrote:
 Author: ramana
 Date: Thu May  8 14:23:11 2014
 New Revision: 210215

 URL: http://gcc.gnu.org/viewcvs?rev=210215root=gccview=rev
 Log:
 Define UDWtype for longlong.h inclusion in wide-int.cc

 2014-05-08  Ramana Radhakrishnan  ramana.radhakrish...@arm.com

 * wide-int.cc (UTItype): Define.
 (UDWtype): Define for appropriate W_TYPE_SIZE.


 Modified:
 trunk/gcc/ChangeLog
 trunk/gcc/wide-int.cc


--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw-w64 may move to git in the future

[Dongsheng Song]

On Sun, May 4, 2014 at 10:09 PM, JonY jo...@users.sourceforge.net wrote:
 On 5/4/2014 12:17, NightStrike wrote:

 Now... that said, there's a few things that I didn't see addressed
 anywhere in this thread.

 1) Jon, you had asked me to setup a mailing list for svn commits.  I
 did so.  Then SF added their own thing that just sends the commit
 message without the patch in the body.  So now we have both.  What is
 your plan with doing that for git?  Are you going to still email
 messages to a list?  Are you going to do it per commit, or per merge?
 Binutils recently tackled this same question, and they settled on 1
 email per commit.  Also, would you only want emails on a certain
 branch?


 Per commit please, all branches.

Due to git merge, the commit maybe out of order, could you consider 1
email per push?

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Sat, Apr 26, 2014 at 3:24 PM, JonY jo...@users.sourceforge.net wrote:
 On 4/26/2014 13:44, Dongsheng Song wrote:
 On Sat, Apr 26, 2014 at 10:24 AM, niXman i.nix...@autistici.org wrote:
 Dongsheng Song 2014-04-26 06:17:
 Not help, still no 'Add File' or 'Add Folder'.

 I also can't see this buttons(bug?), but I use ShellService:
 https://sourceforge.net/p/forge/documentation/Shell%20Service/


 Thanks for your information.

 When I use ssh login, then 'sf-help --frs' said I did't have FRS on 
 mingw-w64.
 When I use sftp, 'docbook' and 'osb' is OK, mingw-w64 faild:

 $  sftp dongsheng,docb...@web.sourceforge.net
 Connected to web.sourceforge.net.
 sftp exit

 $ sftp dongsheng,o...@web.sourceforge.net
 Connected to web.sourceforge.net.
 sftp exit

 $ sftp dongsheng,mingw-...@web.sourceforge.net
 Password:

 Try frs.sourceforge.net.


Still no luck.

$ sftp dongsheng,mingw-...@frs.sourceforge.net
Password:
Password:
Password:

$ sftp dongsheng,docb...@frs.sourceforge.net
Connected to frs.sourceforge.net.
sftp exit

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Sat, Apr 26, 2014 at 3:22 PM, Adrien Nader adr...@notk.org wrote:
 On Sat, Apr 26, 2014, Dongsheng Song wrote:
 On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote:
  I believe --with-arch=core2 is a big issue for generic toolchains. It
  will create troubles which will be very annoying to pinpoint.
 
  Any x86_64/amd64/EM64T (I love how Intel always makes up awful names)
  already has SSE2 and there is little value in restricting this except in
  very specific situation which are better dealt on a case-by-case basis.
 
  Regards,
  Adrien Nader
 

 Do you really meet this issue ? I can not image someone still running
 64 bit Windows on such old CPU.

 Intel core2 release in July 2006, shutdown in January 2010.
 http://en.wikipedia.org/wiki/Intel_Core_2

 I have troubles believing people still run XP but many do. :P

 The issue is rather when you look at the AMD CPUs.
 First models with SSE3 are from the end of 2007 (meaning you would still
 easily see machines with them at the end of 2008, even beginning of
 2009).
 The real issue is with SSSE3 (one more 'S') since the first mobile CPUs
 with it have been released beginning of 2011 and the first desktop CPUs
 with it have been released end of 2011 are are still easily found.

 I have a machine without SSE3 in my living room (albeit it needs a new
 PSU), along with a machine without SSSE3 which is definitely running
 strong (in particular since the rate of CPU speed improvement has
 dramatically slowed down in the last few years).

 I don't think there is a point in making core2 the default; I don't
 think it will bring any improvements except when building multimedia
 stuff and even then it's not unlikely they don't provide hand-tuned
 assembly but even then, -mtune should do be able to bring the
 performance benefits on the newer CPUs while still running on the older
 ones.


I agree with you the performance view.

But from gcc view, Intel 64 cpu is: nocona, core2 or later. In my
memory, I never hear someone can run 64 bit windows on nocona without
problem. I know it's unfair for AMD CPUs, but both without -march and
with -march=amd cpu type give 3DNow defined, it's not acceptable for
Intel CPUs.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Sat, Apr 26, 2014 at 4:47 PM, JonY jo...@users.sourceforge.net wrote:
 On 4/26/2014 10:27, Matthew Brett wrote:

 I've had problems with sourceforge before.  It looks like, to allow
 people to upload, you have add the person as Developer or Admin, and
 then (this for the project 'numpy'):

 Go the 'tools' sidebar:
   https://sourceforge.net/p/numpy/admin/tools
 Under Files, select Release Technicians:
   https://sourceforge.net/p/numpy/admin/downloads/releasers/
 Click the box next to the developer's name.

 That seemed to work for other projects at least.

 Release manager can't release...

 Anyway, try again Dongsheng.


Thanks, both web and sftp are OK now.
How do you fix this issue ?

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Sat, Apr 26, 2014 at 10:25 PM, Adrien Nader adr...@notk.org wrote:
 On Sat, Apr 26, 2014, Dongsheng Song wrote:
 On Sat, Apr 26, 2014 at 3:22 PM, Adrien Nader adr...@notk.org wrote:
  On Sat, Apr 26, 2014, Dongsheng Song wrote:
  On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote:
   I believe --with-arch=core2 is a big issue for generic toolchains. It
   will create troubles which will be very annoying to pinpoint.
  
   Any x86_64/amd64/EM64T (I love how Intel always makes up awful names)
   already has SSE2 and there is little value in restricting this except in
   very specific situation which are better dealt on a case-by-case basis.
  
   Regards,
   Adrien Nader
  
 
  Do you really meet this issue ? I can not image someone still running
  64 bit Windows on such old CPU.
 
  Intel core2 release in July 2006, shutdown in January 2010.
  http://en.wikipedia.org/wiki/Intel_Core_2
 
  I have troubles believing people still run XP but many do. :P
 
  The issue is rather when you look at the AMD CPUs.
  First models with SSE3 are from the end of 2007 (meaning you would still
  easily see machines with them at the end of 2008, even beginning of
  2009).
  The real issue is with SSSE3 (one more 'S') since the first mobile CPUs
  with it have been released beginning of 2011 and the first desktop CPUs
  with it have been released end of 2011 are are still easily found.
 
  I have a machine without SSE3 in my living room (albeit it needs a new
  PSU), along with a machine without SSSE3 which is definitely running
  strong (in particular since the rate of CPU speed improvement has
  dramatically slowed down in the last few years).
 
  I don't think there is a point in making core2 the default; I don't
  think it will bring any improvements except when building multimedia
  stuff and even then it's not unlikely they don't provide hand-tuned
  assembly but even then, -mtune should do be able to bring the
  performance benefits on the newer CPUs while still running on the older
  ones.
 

 I agree with you the performance view.

 But from gcc view, Intel 64 cpu is: nocona, core2 or later. In my
 memory, I never hear someone can run 64 bit windows on nocona without
 problem. I know it's unfair for AMD CPUs, but both without -march and
 with -march=amd cpu type give 3DNow defined, it's not acceptable for
 Intel CPUs.

 Intel 64 is a name that doesn't exist. It's either AMD64 (AMD
 parlance), EM64T (Intel parlance), x64 (Microsoft parlance) or x86_64
 (parlance of anyone not interested in marketing and propaganda). The
 first CPUs handling x86_64 date from 2003 and were server-class CPUs.

 Using --with-arch=core2 means that there many CPUs sold during pretty
 much *10* years will not be able to run the programs compiled with these
 toolchains and will crash at surprising times in surprising ways.

 Right now I have a Windows 8 x86_64 VM running on a CPU from 2009 or
 2010 without SSSE3. Actually it maybe doesn't have SSE3 either. I've
 never had issues with x86_64 stuff on it.
 I've also grabbed my XP 64 box and there's a cute logo of a Pentium 4.
 While everyone will agree XP 64 was far from perfect, I think it's a
 good indication that it worked at least for some people.


 As for not specifying any arch, I wasn't able to quickly find a
 reference or documentation on the matter. However, Linux distributions
 are a good example however: they run on all x86_64 CPUs and don't set
 anything specific and that's what a generic toolchain should do too.

 In any case, if not setting --with-arch makes code that cannot run on
 the triplet specified during the build of GCC (which I do not believe)
 then this is an issue in GCC and should be dealt in GCC and not
 worked-around (but again, I believe it is not the case).

 --
 Adrien Nader


Just pick Linux 64 bit gcc:

gcc -dM -E -  /dev/null | grep -i k8
#define __k8 1
#define __k8__ 1

From http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html , k8 is:

Processors based on the AMD K8 core with x86-64 instruction set
support, including the AMD Opteron, Athlon 64, and Athlon 64 FX
processors. (This supersets MMX, SSE, SSE2, 3DNow!, enhanced 3DNow!
and 64-bit instruction set extensions.)

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Sat, Apr 26, 2014 at 11:49 PM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
 On Sat, Apr 26, 2014 at 10:25 PM, Adrien Nader adr...@notk.org wrote:
 On Sat, Apr 26, 2014, Dongsheng Song wrote:
 On Sat, Apr 26, 2014 at 3:22 PM, Adrien Nader adr...@notk.org wrote:
  On Sat, Apr 26, 2014, Dongsheng Song wrote:
  On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote:
   I believe --with-arch=core2 is a big issue for generic toolchains. It
   will create troubles which will be very annoying to pinpoint.
  
   Any x86_64/amd64/EM64T (I love how Intel always makes up awful names)
   already has SSE2 and there is little value in restricting this except 
   in
   very specific situation which are better dealt on a case-by-case basis.
  
   Regards,
   Adrien Nader
  
 
  Do you really meet this issue ? I can not image someone still running
  64 bit Windows on such old CPU.
 
  Intel core2 release in July 2006, shutdown in January 2010.
  http://en.wikipedia.org/wiki/Intel_Core_2
 
  I have troubles believing people still run XP but many do. :P
 
  The issue is rather when you look at the AMD CPUs.
  First models with SSE3 are from the end of 2007 (meaning you would still
  easily see machines with them at the end of 2008, even beginning of
  2009).
  The real issue is with SSSE3 (one more 'S') since the first mobile CPUs
  with it have been released beginning of 2011 and the first desktop CPUs
  with it have been released end of 2011 are are still easily found.
 
  I have a machine without SSE3 in my living room (albeit it needs a new
  PSU), along with a machine without SSSE3 which is definitely running
  strong (in particular since the rate of CPU speed improvement has
  dramatically slowed down in the last few years).
 
  I don't think there is a point in making core2 the default; I don't
  think it will bring any improvements except when building multimedia
  stuff and even then it's not unlikely they don't provide hand-tuned
  assembly but even then, -mtune should do be able to bring the
  performance benefits on the newer CPUs while still running on the older
  ones.
 

 I agree with you the performance view.

 But from gcc view, Intel 64 cpu is: nocona, core2 or later. In my
 memory, I never hear someone can run 64 bit windows on nocona without
 problem. I know it's unfair for AMD CPUs, but both without -march and
 with -march=amd cpu type give 3DNow defined, it's not acceptable for
 Intel CPUs.

 Intel 64 is a name that doesn't exist. It's either AMD64 (AMD
 parlance), EM64T (Intel parlance), x64 (Microsoft parlance) or x86_64
 (parlance of anyone not interested in marketing and propaganda). The
 first CPUs handling x86_64 date from 2003 and were server-class CPUs.

 Using --with-arch=core2 means that there many CPUs sold during pretty
 much *10* years will not be able to run the programs compiled with these
 toolchains and will crash at surprising times in surprising ways.

 Right now I have a Windows 8 x86_64 VM running on a CPU from 2009 or
 2010 without SSSE3. Actually it maybe doesn't have SSE3 either. I've
 never had issues with x86_64 stuff on it.
 I've also grabbed my XP 64 box and there's a cute logo of a Pentium 4.
 While everyone will agree XP 64 was far from perfect, I think it's a
 good indication that it worked at least for some people.


 As for not specifying any arch, I wasn't able to quickly find a
 reference or documentation on the matter. However, Linux distributions
 are a good example however: they run on all x86_64 CPUs and don't set
 anything specific and that's what a generic toolchain should do too.

 In any case, if not setting --with-arch makes code that cannot run on
 the triplet specified during the build of GCC (which I do not believe)
 then this is an issue in GCC and should be dealt in GCC and not
 worked-around (but again, I believe it is not the case).

 --
 Adrien Nader


 Just pick Linux 64 bit gcc:

 gcc -dM -E -  /dev/null | grep -i k8
 #define __k8 1
 #define __k8__ 1

 From http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html , k8 is:

 Processors based on the AMD K8 core with x86-64 instruction set
 support, including the AMD Opteron, Athlon 64, and Athlon 64 FX
 processors. (This supersets MMX, SSE, SSE2, 3DNow!, enhanced 3DNow!
 and 64-bit instruction set extensions.)

By the way, You can use your prefer -march when compile programs. It's
best practices, many people use -march to support newer or older CPUs,
no one default setting suits us all.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Fri, Apr 25, 2014 at 4:39 PM, niXman i.nix...@autistici.org wrote:
 Hi,

 Just now I uploaded the first builds of MinGW-W64 based on GCC-4.9.0.

 Links:
 32-bit:
  posix-sjlj:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-posix/sjlj/i686-4.9.0-release-posix-sjlj-rt_v3-rev0.7z
  posix-dwarf:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-posix/dwarf/i686-4.9.0-release-posix-dwarf-rt_v3-rev0.7z
  win32-sjlj:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/sjlj/i686-4.9.0-release-win32-sjlj-rt_v3-rev0.7z
  win32-dwarf:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/dwarf/i686-4.9.0-release-win32-dwarf-rt_v3-rev0.7z

 64-bit:
  posix-sjlj:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-posix/sjlj/x86_64-4.9.0-release-posix-sjlj-rt_v3-rev0.7z
  posix-seh:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-posix/seh/x86_64-4.9.0-release-posix-seh-rt_v3-rev0.7z
  win32-sjlj:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-win32/sjlj/x86_64-4.9.0-release-win32-sjlj-rt_v3-rev0.7z
  win32-seh:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-win32/seh/x86_64-4.9.0-release-win32-seh-rt_v3-rev0.7z



 --
 Regards, niXman


Here is GCC daily builds with default configuration:

https://sourceforge.net/projects/osb/files/gcc/

--
Dongsheng

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Fri, Apr 25, 2014 at 5:32 PM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
 On Fri, Apr 25, 2014 at 4:39 PM, niXman i.nix...@autistici.org wrote:
 Hi,

 Just now I uploaded the first builds of MinGW-W64 based on GCC-4.9.0.

 Links:
 32-bit:
  posix-sjlj:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-posix/sjlj/i686-4.9.0-release-posix-sjlj-rt_v3-rev0.7z
  posix-dwarf:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-posix/dwarf/i686-4.9.0-release-posix-dwarf-rt_v3-rev0.7z
  win32-sjlj:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/sjlj/i686-4.9.0-release-win32-sjlj-rt_v3-rev0.7z
  win32-dwarf:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-win32/dwarf/i686-4.9.0-release-win32-dwarf-rt_v3-rev0.7z

 64-bit:
  posix-sjlj:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-posix/sjlj/x86_64-4.9.0-release-posix-sjlj-rt_v3-rev0.7z
  posix-seh:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-posix/seh/x86_64-4.9.0-release-posix-seh-rt_v3-rev0.7z
  win32-sjlj:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-win32/sjlj/x86_64-4.9.0-release-win32-sjlj-rt_v3-rev0.7z
  win32-seh:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/threads-win32/seh/x86_64-4.9.0-release-win32-seh-rt_v3-rev0.7z



 --
 Regards, niXman


 Here is GCC daily builds with default configuration:

 https://sourceforge.net/projects/osb/files/gcc/

 --
 Dongsheng

It seems that mingw-w64 daily builds stopped long ago.

I'm glad to upload my daily builds to mingw-w64, if someone intersting
and give me (dongsheng) permission.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Fri, Apr 25, 2014 at 6:50 PM, JonY jo...@users.sourceforge.net wrote:
 On 4/25/2014 17:47, Dongsheng Song wrote:
 I'm glad to upload my daily builds to mingw-w64, if someone intersting
 and give me (dongsheng) permission.


 What is your configuration like? And what exactly do you have in your
 download?


For win64:
${GCC_SRC_ROOT}/configure \
--prefix=${SYS_ROOT} \
--with-sysroot=${SYS_ROOT} \
--build=${BUILD_TRIPLET} --host=${TARGET_TRIPLET}
--target=${TARGET_TRIPLET} \
--disable-multilib --disable-nls --disable-win32-registry \
--enable-checking=release --enable-languages=c,c++,fortran \
--with-arch=core2 --with-tune=generic

For win32:
${GCC_SRC_ROOT}/configure \
--prefix=${SYS_ROOT} \
--with-sysroot=${SYS_ROOT} \
--build=${BUILD_TRIPLET} --host=${TARGET_TRIPLET}
--target=${TARGET_TRIPLET} \
--disable-multilib --disable-nls --disable-win32-registry \
--enable-checking=release --enable-languages=c,c++,fortran \
--with-arch=i686 --with-tune=generic

All packages have:
version.txt: The 3rd software version and download address, the svn
version of mingw-w64 and gcc.
The binary files of binutils, make, gdb and gcc.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Fri, Apr 25, 2014 at 10:34 PM, JonY jo...@users.sourceforge.net wrote:
 Add --enable-fully-dynamic-string and
 --enable-version-specific-runtime-libs and everything is good.


I will testing with these options.

 You may need to use winpthread if you want to use --enable-libgomp.


Yes. In my situation, we dont't need winpthread. Since we only support
Windows 7.1 and Server 2008 R2 or later, winpthread is too heavy for
us.

 I have now added your login to allow uploads, please upload to somewhere
 like Toolchains targetting Win{32,64}/Personal Builds/dongsheng-daily.

I can see MinGW-w64 in my projects, but I can not see 'Add File' or
'Add Folder'  in ' /files/Toolchains targetting Win64/Personal
Builds/' or '/files/Toolchains targetting Win32/'.

 probably a good idea to rotate the files weekly to prevent uploads from
 getting too big (if there is such a thing as too big).


Yes, we can delete old files with 0 downloads periodically.

Regards,
Dongsheng

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Sat, Apr 26, 2014 at 12:31 AM, Adrien Nader adr...@notk.org wrote:
 I believe --with-arch=core2 is a big issue for generic toolchains. It
 will create troubles which will be very annoying to pinpoint.

 Any x86_64/amd64/EM64T (I love how Intel always makes up awful names)
 already has SSE2 and there is little value in restricting this except in
 very specific situation which are better dealt on a case-by-case basis.

 Regards,
 Adrien Nader


Do you really meet this issue ? I can not image someone still running
64 bit Windows on such old CPU.

Intel core2 release in July 2006, shutdown in January 2010.
http://en.wikipedia.org/wiki/Intel_Core_2

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Sat, Apr 26, 2014 at 8:32 AM, JonY jo...@users.sourceforge.net wrote:
 On 4/25/2014 22:54, Ruben Van Boxem wrote:

 Add --enable-fully-dynamic-string and


 Shouldn't this already be enabled by default (you worked on a patch for
 that which IIANM I tested back then)?



 I can't remember if I did :)

 --enable-version-specific-runtime-libs and everything is good.


 This isn't strictly necessary and in my experience is quite troublesome
 (can't find -lgcc_eh as a result)


 This is a long standing bug, it happens with Linux versions also, but
 after moving things into place, you end up with a far tidier install.
 This workaround can be scripted for post-install.

 You can drop your libdir with custom headers/libraries into a new
 version of GCC and it'll work without another version of GCC clashing in.


In my testing, gcc 4.7 got this error. gcc 4.8, 4.9 and 4.10 is OK.

This only move some version and arch specific files to compiler
specific directory. Since the binary files in the same location and
have same name, I don't think this option have value.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

[Dongsheng Song]

On Sat, Apr 26, 2014 at 10:24 AM, niXman i.nix...@autistici.org wrote:
 Dongsheng Song 2014-04-26 06:17:
 Not help, still no 'Add File' or 'Add Folder'.

 I also can't see this buttons(bug?), but I use ShellService:
 https://sourceforge.net/p/forge/documentation/Shell%20Service/


Thanks for your information.

When I use ssh login, then 'sf-help --frs' said I did't have FRS on mingw-w64.
When I use sftp, 'docbook' and 'osb' is OK, mingw-w64 faild:

$  sftp dongsheng,docb...@web.sourceforge.net
Connected to web.sourceforge.net.
sftp exit

$ sftp dongsheng,o...@web.sourceforge.net
Connected to web.sourceforge.net.
sftp exit

$ sftp dongsheng,mingw-...@web.sourceforge.net
Password:

Then I assume I have no enough permission on mingw-w64.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] How to attach version info to libstdc++-6.dll ?

[Dongsheng Song]

Hi,

The stdandard compiled output gcc DLLs (e.g. libstdc++-6.dll) have no
version info, I want attach version info to it, what's the prefered
method ?

gcc 4.7/4.8/4.9 generate same DLL name without version info, it's
really annoying.

Regards,
Dongsheng

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Add a missing leave_global_cs() call on r6411

[Dongsheng Song]

~/vcs/svn/mingw-w64/trunk/mingw-w64-libraries/winpthreads/src$ svn diff .
Index: spinlock.c
===
--- spinlock.c  (revision 6412)
+++ spinlock.c  (working copy)
@@ -114,7 +114,10 @@

   spin = (spin_t*)*lock;
   if (spin-owner  spin-owner != GetCurrentThreadId ())
-return EPERM;
+{
+  leave_global_cs ();
+  return EPERM;
+}

   DeleteCriticalSection (spin-section);
   free (spin);
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Fix old bug which loomed due to r6391

[Dongsheng Song]

$ svn diff
Index: trunk/mingw-w64-headers/include/winuser.h
===
--- trunk/mingw-w64-headers/include/winuser.h   (revision 6391)
+++ trunk/mingw-w64-headers/include/winuser.h   (working copy)
@@ -5624,7 +5624,7 @@
 WINUSERAPI HDESK WINAPI CreateDesktopExW(
   LPCWSTR lpszDesktop,
   LPCWSTR lpszDevice,
-  DEVMODE *pDevmode,
+  DEVMODEW *pDevmode,
   DWORD dwFlags,
   ACCESS_MASK dwDesiredAccess,
   LPSECURITY_ATTRIBUTES lpsa,

$ svn  blame mingw-w64-headers/include/winuser.h
...
  4190  jon_y WINUSERAPI HDESK WINAPI CreateDesktopExW(
  3198  jon_y   LPCWSTR lpszDesktop,
  3198  jon_y   LPCWSTR lpszDevice,
  3198  jon_y   DEVMODE *pDevmode,
  3198  jon_y   DWORD dwFlags,
  3198  jon_y   ACCESS_MASK dwDesiredAccess,
  3198  jon_y   LPSECURITY_ATTRIBUTES lpsa,
  3198  jon_y   ULONG ulHeapSize,
  3198  jon_y   PVOID pvoid
  3198  jon_y );
...

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour

[Dongsheng Song]

On Thu, Jul 4, 2013 at 8:40 PM, Dongsheng Song dongsheng.s...@gmail.com wrote:
 于 2013/7/4 17:18, Kai Tietz 写道:
 2013/7/4 Dongsheng Song dongsheng.s...@gmail.com:
 On 2013/7/4 4:49, Earnie Boyd wrote:
 On Wed, Jul 3, 2013 at 12:28 PM, Dongsheng Song wrote:
 On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz ktiet...@googlemail.com 
 wrote:
 That is a known issue of ld for pe-coff.  If at least one symbol is
 exported by dllexport, only those symbols are.  If there is none, then
 all symbols getting exported.

 Just for curious, why 64 bit Windows target not affected ? Why gcc 4.7
 32 bit Windows target not affected ?

 This behavior was added to binutils years ago by Danny Smith.  I'm
 guessing your affect is a bit over stated.  You can use
 --exclude-all-symbols to stop the automatic export or
 --export-all-symbols to always export all symbols.  You'll also be
 interested in --warn-duplicate-exports.

 NO. automatic export do not explain the following test results:

 gcc-4.8, mingw-w64 trunk, binutils 2.23.2, 32 bit windows target: extra 
 export InterlockedCompareExchange@12
 gcc-4.8, mingw-w64 trunk, binutils 2.23.2, 64 bit windows target: OK

 gcc-4.7, mingw-w64 v2, binutils 2.23.2, 32 bit windows target: OK
 gcc-4.7, mingw-w64 v2, binutils 2.23.2, 64 bit windows target: OK

 I can not see any reason that binutils is the criminal, gcc 4.8 or 
 mingw-w64 trunk looks more like the criminal.

 Regards,
 Dongsheng
 This issue is related to changed code for libmsvcrt.a on trunk.
 Yesterday was a patch for that, which should have fixed that issue.
 Please update trunk's crt.

 Which version ? I'm only see ___lc_codepage_func related changes of
 libmsvcrt.a on the trunk.

 I can confirm gcc 4.8 r200650 (2013-07-04 04:24:19 +0800) with mingw-w64
 trunk r5926 (2013-07-04 00:02:29 +0800) still have an extra export
 InterlockedCompareExchange@12

 Regards,
 Dongsheng


Just a heads up that this issue is fixed by r5949.

--
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 AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour

[Dongsheng Song]

On 2013/7/4 4:49, Earnie Boyd wrote:
 On Wed, Jul 3, 2013 at 12:28 PM, Dongsheng Song wrote:
 On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz ktiet...@googlemail.com wrote:
 That is a known issue of ld for pe-coff.  If at least one symbol is
 exported by dllexport, only those symbols are.  If there is none, then
 all symbols getting exported.

 Just for curious, why 64 bit Windows target not affected ? Why gcc 4.7
 32 bit Windows target not affected ?

 This behavior was added to binutils years ago by Danny Smith.  I'm
 guessing your affect is a bit over stated.  You can use
 --exclude-all-symbols to stop the automatic export or
 --export-all-symbols to always export all symbols.  You'll also be
 interested in --warn-duplicate-exports.


NO. automatic export do not explain the following test results:

gcc-4.8, mingw-w64 trunk, binutils 2.23.2, 32 bit windows target: extra export 
InterlockedCompareExchange@12
gcc-4.8, mingw-w64 trunk, binutils 2.23.2, 64 bit windows target: OK

gcc-4.7, mingw-w64 v2, binutils 2.23.2, 32 bit windows target: OK
gcc-4.7, mingw-w64 v2, binutils 2.23.2, 64 bit windows target: OK

I can not see any reason that binutils is the criminal, gcc 4.8 or mingw-w64 
trunk looks more like the criminal.

Regards,
Dongsheng




signature.asc
Description: OpenPGP digital signature
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour

[Dongsheng Song]

于 2013/7/4 17:18, Kai Tietz 写道:
 2013/7/4 Dongsheng Song dongsheng.s...@gmail.com:
 On 2013/7/4 4:49, Earnie Boyd wrote:
 On Wed, Jul 3, 2013 at 12:28 PM, Dongsheng Song wrote:
 On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz ktiet...@googlemail.com wrote:
 That is a known issue of ld for pe-coff.  If at least one symbol is
 exported by dllexport, only those symbols are.  If there is none, then
 all symbols getting exported.

 Just for curious, why 64 bit Windows target not affected ? Why gcc 4.7
 32 bit Windows target not affected ?

 This behavior was added to binutils years ago by Danny Smith.  I'm
 guessing your affect is a bit over stated.  You can use
 --exclude-all-symbols to stop the automatic export or
 --export-all-symbols to always export all symbols.  You'll also be
 interested in --warn-duplicate-exports.

 NO. automatic export do not explain the following test results:

 gcc-4.8, mingw-w64 trunk, binutils 2.23.2, 32 bit windows target: extra 
 export InterlockedCompareExchange@12
 gcc-4.8, mingw-w64 trunk, binutils 2.23.2, 64 bit windows target: OK

 gcc-4.7, mingw-w64 v2, binutils 2.23.2, 32 bit windows target: OK
 gcc-4.7, mingw-w64 v2, binutils 2.23.2, 64 bit windows target: OK

 I can not see any reason that binutils is the criminal, gcc 4.8 or mingw-w64 
 trunk looks more like the criminal.

 Regards,
 Dongsheng
 This issue is related to changed code for libmsvcrt.a on trunk.
 Yesterday was a patch for that, which should have fixed that issue.
 Please update trunk's crt.

Which version ? I'm only see ___lc_codepage_func related changes of
libmsvcrt.a on the trunk.

I can confirm gcc 4.8 r200650 (2013-07-04 04:24:19 +0800) with mingw-w64
trunk r5926 (2013-07-04 00:02:29 +0800) still have an extra export
InterlockedCompareExchange@12

Regards,
Dongsheng



signature.asc
Description: OpenPGP digital signature
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour

[Dongsheng Song]

Hi,

If source files use __attribute__ ((dllexport)) to export symbols, the
result DLL looks fine.

But if not use __attribute__ ((dllexport)), the result DLL will export
an extra symbol
'InterlockedCompareExchange@12'. I had checked the compiled and link
files, do not know why.

--- use __attribute__ ((dllexport)) ---
$ cat  EOF  t-dll.c
__attribute__ ((dllexport))
int get_int()
{
return 1;
}
EOF

$ i686-w64-mingw32-gcc -c -o t-dll.o t-dll.c
$ i686-w64-mingw32-objdump -s t-dll.o | grep -A 5 Contents of section
.drectve

Contents of section .drectve:
 202d6578 706f7274 3a226765 745f696e -export:get_in
0010 7422 t..

$ i686-w64-mingw32-gcc -shared -o t-dll.dll t-dll.o
$ i686-w64-mingw32-objdump -x t-dll.dll | grep -A 20 The Export Tables

The Export Tables (interpreted .edata section contents)

Export Flags 0
Time/Date stamp 51d43aff
Major/Minor 0/0
Name a032 t-dll.dll
Ordinal Base 1
Number in:
Export Address Table 0001
[Name Pointer/Ordinal] Table 0001
Table Addresses
Export Address Table a028
Name Pointer Table a02c
Ordinal Table a030

Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 14d0 Export RVA

[Ordinal/Name Pointer] Table
[ 0] get_int

Looks good !

--- without __attribute__ ((dllexport)) ---
$ cat  EOF  t-dll2.c
int get_int()
{
return 1;
}
EOF

$ i686-w64-mingw32-gcc -c -o t-dll2.o t-dll2.c
$ i686-w64-mingw32-objdump -s t-dll2.o | grep -A 5 Contents of section
Contents of section .text:
 5589e5b8 0100 5dc39090 U...]...
Contents of section .rdata$zzz:
 4743433a 2028474e 55292034 2e382e32 GCC: (GNU) 4.8.2
0010 20323031 33303730 33202870 72657265 20130703 (prere
0020 6c656173 6529 lease)..

 no section .drectve 

$ i686-w64-mingw32-gcc -shared -o t-dll2.dll t-dll2.o
$ i686-w64-mingw32-objdump -x t-dll2.dll | grep -A 22 The Export Tables

The Export Tables (interpreted .edata section contents)

Export Flags 0
Time/Date stamp 51d4440b
Major/Minor 0/0
Name a03c t-dll2.dll
Ordinal Base 1
Number in:
Export Address Table 0002
[Name Pointer/Ordinal] Table 0002
Table Addresses
Export Address Table a028
Name Pointer Table a030
Ordinal Table a038

Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 6f50 Export RVA
[ 1] +base[ 2] 14d0 Export RVA

[Ordinal/Name Pointer] Table
[ 0] InterlockedCompareExchange@12
[ 1] get_int

What happened ? Why we have an extra export
InterlockedCompareExchange@12 ?
Let's check the link details:


cauchy@CRM-SYSLOG:/tmp$ i686-w64-mingw32-gcc -v -shared -o t-dll2.dll
t-dll2.o
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/lto-wrapper
Target: i686-w64-mingw32
Configured with:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure
--prefix=/home/cauchy/cross/i686-windows-gcc48
--with-sysroot=/home/cauchy/cross/i686-windows-gcc48
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=i686-w64-mingw32 --disable-multilib --disable-nls
--enable-checking=release --enable-languages=c,c++,fortran
--with-arch=i686 --with-tune=generic
Thread model: win32
gcc version 4.8.2 20130703 (prerelease) (GCC)
COMPILER_PATH=/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/
LIBRARY_PATH=/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/:/home/cauchy/cross/i686-windows-gcc48/mingw/lib/../lib/:/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/:/home/cauchy/cross/i686-windows-gcc48/mingw/lib/
COLLECT_GCC_OPTIONS='-v' '-shared' '-o' 't-dll2.dll' '-mtune=generic'
'-march=i686'
/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/collect2
--sysroot=/home/cauchy/cross/i686-windows-gcc48 -m i386pe --shared
-Bdynamic -e _DllMainCRTStartup@12 --enable-auto-image-base -o
t-dll2.dll
/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o
/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/crtbegin.o
-L/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2
-L/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib/../lib
-L/home/cauchy/cross/i686-windows-gcc48/mingw/lib/../lib
-L/home/cauchy/cross/i686-windows-gcc48/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/lib

Re: [Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour

[Dongsheng Song]

On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz ktiet...@googlemail.com wrote:
 That is a known issue of ld for pe-coff.  If at least one symbol is
 exported by dllexport, only those symbols are.  If there is none, then
 all symbols getting exported.


Just for curious, why 64 bit Windows target not affected ? Why gcc 4.7
32 bit Windows target not affected ?

 You can report that to binutils,  but I don't see right now a good way
 to solve that issue.

 Regards,
 Kai


Regards,
Dongsheng

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] gcc 4.9(trunk) failed on build intrincs/__movsb.c

[Dongsheng Song]

*) 32 bit
cauchy@CRM-SYSLOG:~/obj/i686-w64-mingw32-gcc49/mingw-w64-crt$ make
make  all-am
make[1]: Entering directory
`/home/cauchy/obj/i686-w64-mingw32-gcc49/mingw-w64-crt'
i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt  -m32
-I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/include -D_CRTBLD
-I/home/cauchy/cross/i686-windows-gcc49/i686-w64-mingw32/include
-pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow
-Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn
-Wmissing-prototypes -g -O2 -MT intrincs/lib32_libkernel32_a-__movsb.o
-MD -MP -MF intrincs/.deps/lib32_libkernel32_a-__movsb.Tpo -c -o
intrincs/lib32_libkernel32_a-__movsb.o `test -f 'intrincs/__movsb.c'
|| echo '/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/'`intrincs/__movsb.c
In file included from
/home/cauchy/cross/i686-windows-gcc49/lib/gcc/i686-w64-mingw32/4.9.0/include/x86intrin.h:27:0,
 from
/home/cauchy/cross/i686-windows-gcc49/i686-w64-mingw32/include/intrin.h:32,
 from
/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/intrincs/__movsb.c:1:
/home/cauchy/cross/i686-windows-gcc49/lib/gcc/i686-w64-mingw32/4.9.0/include/ia32intrin.h:54:9:
internal compiler error: in c_builtin_function_ext_scope, at
c/c-decl.c:3633
 #pragma GCC target(sse4.2)
 ^
0x56dc3b c_builtin_function_ext_scope(tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633
0x791b08 add_builtin_function_common
/home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561
0x7923c3 add_builtin_function_ext_scope(char const*, tree_node*, int,
built_in_class, char const*, tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597
0xa3fb44 ix86_add_new_builtins
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27206
0xa3fb44 ix86_valid_target_attribute_tree(tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4520
0x5edf20 ix86_pragma_target_parse
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386-c.c:385
0x5de80d handle_pragma_target
/home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-pragma.c:805
0x5937ae c_parser_pragma
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:8749
0x5a1e2b c_parser_external_declaration
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1345
0x5a2797 c_parser_translation_unit
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1251
0x5a2797 c_parse_file()
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:11000
0x5dc364 c_common_parse_file()
/home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
make[1]: *** [intrincs/lib32_libkernel32_a-__movsb.o] Error 1
make[1]: Leaving directory
`/home/cauchy/obj/i686-w64-mingw32-gcc49/mingw-w64-crt'
make: *** [all] Error 2

*) 64 bit
cauchy@dre-syslog:~/obj/x86_64-w64-mingw32-gcc49/mingw-w64-crt$ make
make  all-am
make[1]: Entering directory
`/home/cauchy/obj/x86_64-w64-mingw32-gcc49/mingw-w64-crt'
x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt  -m64
-I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/include -D_CRTBLD
-I/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include
-pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow
-Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn
-Wmissing-prototypes -g -O2 -MT intrincs/lib64_libkernel32_a-__movsb.o
-MD -MP -MF intrincs/.deps/lib64_libkernel32_a-__movsb.Tpo -c -o
intrincs/lib64_libkernel32_a-__movsb.o `test -f 'intrincs/__movsb.c'
|| echo '/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/'`intrincs/__movsb.c
In file included from
/home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intrin.h:27:0,
 from
/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/intrin.h:32,
 from
/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/intrincs/__movsb.c:1:
/home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ia32intrin.h:54:9:
internal compiler error: in c_builtin_function_ext_scope, at
c/c-decl.c:3633
 #pragma GCC target(sse4.2)
 ^
0x53572b c_builtin_function_ext_scope(tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633
0x75e868 add_builtin_function_common
/home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561
0x75f123 add_builtin_function_ext_scope(char const*, tree_node*, int,
built_in_class, char const*, tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597
0xa11304 ix86_add_new_builtins
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27206
0xa11304 ix86_valid_target_attribute_tree(tree_node*)
/home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4520
0x5b5b90 ix86_pragma_target_parse

Re: [Mingw-w64-public] link msvcr100 problem under mingw

[Dongsheng Song]

On Thu, Jun 20, 2013 at 2:31 PM, zhangxinghai zxh19750...@163.com wrote:
 Hello
 I write a test helloworld program.I want to link it against msvcr100.My
 enviroment is
 os:xp sp3
 mingw64 version:ruben build target win32
 I compile the program as
 gcc -o hello.exe main.cpp -lmsvcr100.

 My problem is when I add -lmsvcr100 switch,I run the dependency walker on
 the hello.exe,I see it depends on both msvcrt.dll(c:\windows\system32) and
 msvcr100.dll.
 But If I write the same program under vs 2010,the output hello.exe only
 depends on msvcr100.dll

 Is is possible for mingw64 to generate executable file only depend on
 msvcr100.dll? Or do I do something wrong ?


Yes. If you see the verbose output:
crt2.o crtbegin.o cc1woImu.o -lmsvcr100 -lstdc++ -lmingw32 -lgcc_s
-lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32
-lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt
crtend.o

You can see '-lmsvcrt' in the library list. So you can do this:

g++ -dumpspecs  msvcr100.spec

Edit msvcr100.spec, change '-lmsvcrt' to '-lmsvcr100', then just execute:

g++ -specs=msvcr100.spec -s -O2 -o hello.cpp.exe hello.cpp

Then 'hello.cpp.exe' only depend on 'msvcr100.dll'. But
'hello.cpp.exe' depend on 'libstdc++-6.dll', you must compile your
self to avoid 'libstdc++-6.dll' depend on 'msvcrt.dll' too.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?

[Dongsheng Song]

On Thu, Jun 20, 2013 at 9:11 PM, Earnie Boyd
ear...@users.sourceforge.net wrote:
 On Thu, Jun 20, 2013 at 9:06 AM, Dongsheng Song wrote:

 I want to build gcc 4.8 with isl and cloog, can I put  isl and cloog
 to gcc/branches/gcc-4_8-branch/ like gmp/mpfr/mpc ?


 You should be able to determine that by looking at the top level
 configure script.  IIRC, it will look for other configure scripts in
 the sub-directories.  The issue will be prerequisite ordering.


Thanks, I see:

$ grep ^host_libs gcc-4_7-branch/configure gcc-4_8-branch/configure
gcc-4_7-branch/configure:host_libs=intl libiberty opcodes bfd
readline tcl tk itcl libgui zlib libcpp libdecnumber gmp mpfr mpc ppl
cloog libelf libiconv
gcc-4_8-branch/configure:host_libs=intl libiberty opcodes bfd
readline tcl tk itcl libgui zlib libbacktrace libcpp libdecnumber gmp
mpfr mpc isl cloog libelf libiconv

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?

[Dongsheng Song]

I can build i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc under
Linux, but when I use this compiler to compile native Windows
compiler, gcc 4.7 success, gcc 4.8 failed with same build script like
this:

make[2]: Entering directory `/home/cauchy/obj/native/gcc-4.8-win32/gcc/gcc'
g++ -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/build
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../include
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../libcpp/include
-I/home/cauchy/native/gcc-4.8-win32-3rd/include
-I/home/cauchy/native/gcc-4.8-win32-3rd/include
-I/home/cauchy/native/gcc-4.8-win32-3rd/include
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../libdecnumber
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../libdecnumber/bid
-I../libdecnumber
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../libbacktrace
   \
-o build/genconstants.o
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c
In file included from /usr/include/x86_64-linux-gnu/sys/resource.h:25:0,
 from /usr/include/x86_64-linux-gnu/sys/wait.h:32,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:352,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/x86_64-linux-gnu/bits/resource.h:133:18: error:
declaration does not declare anything [-fpermissive]
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:0:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:444:23:
error: declaration of C function ‘void* sbrk(int)’ conflicts with
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:254:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/unistd.h:1056:14: error: previous declaration ‘void*
sbrk(intptr_t)’ here
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:0:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:448:48:
error: new declaration ‘char* strstr(const char*, const char*)’
In file included from /usr/include/c++/4.7/cstring:44:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:205,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/string.h:335:1: error: ambiguates old declaration ‘const
char* strstr(const char*, const char*)’
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:0:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:500:34:
error: declaration of C function ‘const char* strsignal(int)’
conflicts with
In file included from /usr/include/c++/4.7/cstring:44:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:205,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/string.h:566:14: error: previous declaration ‘char*
strsignal(int)’ here
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:645:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../include/libiberty.h:110:36:
error: new declaration ‘char* basename(const char*)’
In file included from /usr/include/c++/4.7/cstring:44:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:205,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/string.h:603:28: error: ambiguates old declaration ‘const
char* basename(const char*)’
make[2]: *** [build/genconstants.o] Error 1
make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.8-win32/gcc/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.8-win32/gcc'
make: *** [all] Error 2

Regards,
Dongsheng

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?

[Dongsheng Song]

On Thu, Jun 20, 2013 at 12:35 AM, Christer Solskogen
christer.solsko...@gmail.com wrote:
 On 19.06.2013 11:37, Dongsheng Song wrote:
 I can build i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc under
 Linux, but when I use this compiler to compile native Windows
 compiler, gcc 4.7 success, gcc 4.8 failed with same build script like
 this:

 make[2]: Entering directory `/home/cauchy/obj/native/gcc-4.8-win32/gcc/gcc'
 g++ -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti

 ^^

 Should not be there. What you should see is x86_64-w64-mingw32-g++. And
 tells me that you probably have the wrong --host setting for configure.
 Gcc needs something like --target=x86_64-w64-mingw32
 --host=x86_64-w64-mingw32 --build=x86_64-unknown-linux-gnu

 --
 chs


This is gcc 4.8 wrong, since I have passed the correct settings:

$ echo ${GCC_SRC_ROOT}/configure \
 --prefix=${SYS_ROOT} \
 --with-sysroot=${SYS_ROOT} \
 --build=${BUILD_TRIPLET} --host=${TARGET_TRIPLET} 
 --target=${TARGET_TRIPLET} \
 --disable-multilib --disable-nls --disable-win32-registry \
 --enable-checking=release --enable-languages=c,c++,fortran \
 --with-fpmath=sse \
 --with-gmp=${SYS_3RD_ROOT} --with-mpfr=${SYS_3RD_ROOT} 
 --with-mpc=${SYS_3RD_ROOT}
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure
--prefix=/home/cauchy/native/gcc-4.8-win32
--with-sysroot=/home/cauchy/native/gcc-4.8-win32
--build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32
--target=i686-w64-mingw32 --disable-multilib --disable-nls
--disable-win32-registry --enable-checking=release
--enable-languages=c,c++,fortran --with-fpmath=sse
--with-gmp=/home/cauchy/native/gcc-4.8-win32-3rd
--with-mpfr=/home/cauchy/native/gcc-4.8-win32-3rd
--with-mpc=/home/cauchy/native/gcc-4.8-win32-3rd

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?

[Dongsheng Song]

On Thu, Jun 20, 2013 at 12:25 PM, Christer Solskogen
christer.solsko...@gmail.com wrote:

 On 20.06.2013 05:20, Dongsheng Song wrote:
  On Thu, Jun 20, 2013 at 12:35 AM, Christer Solskogen
  christer.solsko...@gmail.com wrote:
  On 19.06.2013 11:37, Dongsheng Song wrote:
  I can build i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc under
  Linux, but when I use this compiler to compile native Windows
  compiler, gcc 4.7 success, gcc 4.8 failed with same build script like
  this:
 
  make[2]: Entering directory 
  `/home/cauchy/obj/native/gcc-4.8-win32/gcc/gcc'
  g++ -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti
 
  ^^
 
  Should not be there. What you should see is x86_64-w64-mingw32-g++. And
  tells me that you probably have the wrong --host setting for configure.
  Gcc needs something like --target=x86_64-w64-mingw32
  --host=x86_64-w64-mingw32 --build=x86_64-unknown-linux-gnu
 
  --
  chs
 
 
  This is gcc 4.8 wrong, since I have passed the correct settings:
 
  $ echo ${GCC_SRC_ROOT}/configure \
   --prefix=${SYS_ROOT} \
   --with-sysroot=${SYS_ROOT} \
   --build=${BUILD_TRIPLET} --host=${TARGET_TRIPLET} 
  --target=${TARGET_TRIPLET} \
   --disable-multilib --disable-nls --disable-win32-registry \
   --enable-checking=release --enable-languages=c,c++,fortran \
   --with-fpmath=sse \
   --with-gmp=${SYS_3RD_ROOT} --with-mpfr=${SYS_3RD_ROOT} 
  --with-mpc=${SYS_3RD_ROOT}
  /home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure
  --prefix=/home/cauchy/native/gcc-4.8-win32
  --with-sysroot=/home/cauchy/native/gcc-4.8-win32
  --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32
  --target=i686-w64-mingw32 --disable-multilib --disable-nls
  --disable-win32-registry --enable-checking=release
  --enable-languages=c,c++,fortran --with-fpmath=sse
  --with-gmp=/home/cauchy/native/gcc-4.8-win32-3rd
  --with-mpfr=/home/cauchy/native/gcc-4.8-win32-3rd
  --with-mpc=/home/cauchy/native/gcc-4.8-win32-3rd
 

 Could you post $CC, $CFLAGS and/or $CXXFLAGS? Also the output of gcc -v
 and i686-w64-mingw32-gcc -v?


Not set any $CC, $CFLAGS and/or $CXXFLAGS.

cauchy@dre-syslog:~/src$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)

cauchy@dre-syslog:~/src$ i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/home/cauchy/cross/i686-windows-gcc48/libexec/gcc/i686-w64-mingw32/4.8.2/lto-wrapper
Target: i686-w64-mingw32
Configured with:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure
--prefix=/home/cauchy/cross/i686-windows-gcc48
--with-sysroot=/home/cauchy/cross/i686-windows-gcc48
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=i686-w64-mingw32 --disable-multilib --disable-nls
--enable-checking=release --enable-languages=c,c++,fortran
--with-arch=x86-64 --with-tune=generic --with-fpmath=sse
Thread model: win32
gcc version 4.8.2 20130617 (prerelease) (GCC)


Here is my building script, just change $PATH, $GCC_SRC_ROOT and
$MINGW_W64_SRC_ROOT, gcc 4.7 is fine.

cauchy@dre-syslog:~/src$ cat cross-native-win32-thin.sh

export GCC_SRC_ROOT=${HOME}/vcs/svn/gcc/branches/gcc-4_8-branch
export MINGW_W64_SRC_ROOT=${HOME}/vcs/svn/mingw-w64/trunk

export GCC_DATE_STR=`cat ${GCC_SRC_ROOT}/gcc/DATESTAMP`
export GCC_BASE_VER=`cat ${GCC_SRC_ROOT}/gcc/BASE-VER`

export ZLIB_SRC_ROOT=${HOME}/src/zlib-1.2.8
export EXPAT_SRC_ROOT=${HOME}/src/expat-2.1.0
export GMP_SRC_ROOT=${HOME}/src/gmp-5.1.2
export MPFR_SRC_ROOT=${HOME}/src/mpfr-3.1.2
export MPC_SRC_ROOT=${HOME}/src/mpc-1.0.1
export BINUTILS_SRC_ROOT=${HOME}/src/binutils-2.23.2
export GDB_SRC_ROOT=${HOME}/src/gdb-7.6
export MAKE_SRC_ROOT=${HOME}/src/make-3.82

export NR_JOBS=`cat /proc/cpuinfo | grep '^processor\s*:' | wc -l`
export BUILD_TRIPLET=`/usr/share/misc/config.guess`
export TARGET_TRIPLET=i686-w64-mingw32
export LOGGER_TAG=native-win32-gcc48
export SYS_ROOT=${HOME}/native/gcc-4.8-win32
export SYS_3RD_ROOT=${HOME}/native/gcc-4.8-win32-3rd
export OBJ_ROOT=${HOME}/obj/native/gcc-4.8-win32
export PATH=${HOME}/cross/i686-windows-gcc48/bin:/usr/sbin:/usr/bin:/sbin:/bin

logger -t ${LOGGER_TAG} -s Build started

[Mingw-w64-public] How to specify exception module separately when build gcc 4.8

[Dongsheng Song]

When I build gcc 4.8 with mingw-w64 trunk:

${GCC_SRC_ROOT}/configure \
--prefix=${SYS_ROOT} \
--with-sysroot=${SYS_ROOT} \
--build=${BUILD_TRIPLET} --host=${BUILD_TRIPLET}
--target=${TARGET_TRIPLET} \
--enable-targets=all --disable-nls \
--enable-checking=release --enable-languages=c,c++,fortran

If TARGET_TRIPLET is x86_64-w64-mingw32, the building works good.

When TARGET_TRIPLET is i686-w64-mingw32, I got errors:

/home/cauchy/obj/i686-w64-mingw32/gcc/./gcc/xgcc
-B/home/cauchy/obj/i686-w64-mingw32/gcc/./gcc/
-L/home/cauchy/cross/i686-windows/i686-w64-mingw32/lib
-L/home/cauchy/cross/i686-windows/mingw/lib -isystem
/home/cauchy/cross/i686-windows/i686-w64-mingw32/include -isystem
/home/cauchy/cross/i686-windows/mingw/include
-B/home/cauchy/cross/i686-windows/i686-w64-mingw32/bin/
-B/home/cauchy/cross/i686-windows/i686-w64-mingw32/lib/ -isystem
/home/cauchy/cross/i686-windows/i686-w64-mingw32/include -isystem
/home/cauchy/cross/i686-windows/i686-w64-mingw32/sys-include-g -O2
-m64 -O2 
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/../winsup/w32api/include
-g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -I. -I. -I../../.././gcc
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/.
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/../gcc
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/../include
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o
-MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind-dw2.c
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind-dw2.c:1698:0:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_RaiseException_Phase2':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:51:60:
error: 'struct _Unwind_Exception' has no member named 'private_2'
   match_handler = (uw_identify_context (context) == exc-private_2
^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_RaiseException':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:127:6:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   exc-private_1 = 0;
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:128:6:
error: 'struct _Unwind_Exception' has no member named 'private_2'
   exc-private_2 = uw_identify_context (cur_context);
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_ForcedUnwind_Phase2':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:145:61:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   _Unwind_Stop_Fn stop = (_Unwind_Stop_Fn) (_Unwind_Ptr) exc-private_1;
 ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:146:51:
error: 'struct _Unwind_Exception' has no member named 'private_2'
   void *stop_argument = (void *) (_Unwind_Ptr) exc-private_2;
   ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_ForcedUnwind':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:204:6:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   exc-private_1 = (_Unwind_Ptr) stop;
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:205:6:
error: 'struct _Unwind_Exception' has no member named 'private_2'
   exc-private_2 = (_Unwind_Ptr) stop_argument;
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_Resume':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:229:10:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   if (exc-private_1 == 0)
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_Resume_or_Rethrow':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:251:10:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   if (exc-private_1 == 0)
  ^
make[4]: *** [unwind-dw2.o] Error 1
make[4]: Leaving directory
`/home/cauchy/obj/i686-w64-mingw32/gcc/i686-w64-mingw32/64/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory
`/home/cauchy/obj/i686-w64-mingw32/gcc/i686-w64-mingw32/libgcc'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory
`/home/cauchy/obj/i686-w64-mingw32/gcc/i686-w64-mingw32/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving 

Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange

[Dongsheng Song]

On Fri, May 24, 2013 at 5:29 AM, Erik van Pienbroek
e...@vanpienbroek.nl wrote:
 Hi,

 During review of one of our Fedora packages we noticed an unexpected
 change in behavior in recent mingw-w64 trunk snapshots. We noticed that
 several libraries which were built against recent mingw-w64 trunk
 snapshots suddenly started to export the symbols
 _InterlockedCompareExchange and InterlockedCompareExchange@12 in their
 shared libraries.

 Libraries which now show this behavior in Fedora are:
 * libasprintf-0.dll (gettext)
 * libcrypto-10.dll (openssl)
 * libffi-6.dll
 * libgmp-10.dll
 * libgnutls-xssl-0.dll
 * libgnutlsxx-28.dll
 * libintl-8.dll (gettext)
 * libobjc-4.dll (gcc)
 * libpixman-1-0.dll
 * libspice-controller-0.dll (spice)
 * libsqlite3-0.dll
 * libusb-1.0.dll (libusbx)
 * QtUiTools4.dll (qt4)

 The thing all these libraries have in common that they were built
 against recent mingw-w64 snapshots.

 The issue can be illustrated by opening the dll in question in
 dependency walker or by running objdump:

 i686-w64-mingw32-objdump
 -p /usr/i686-w64-mingw32/sys-root/mingw/bin/libsqlite3-0.dll | grep -B1
 Interlocked
 [Ordinal/Name Pointer] Table
 [   0] InterlockedCompareExchange@12
 [   1] _InterlockedCompareExchange

 So far I've only seen this happening for the i686-w64-mingw32 target. I
 can't confirm yet if it also is happening on x86_64-w64-mingw32.


Yes, I can see this happening for the i686-w64-mingw32 target for
compile glib 2.36.2, but x86_64-w64-mingw32 target not take effected.
It's really annoying.

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] time == _time64 in .DEF not working on MS lib.exe

[Dongsheng Song]

Hi,

mingw-w64 use lots of '==' to redirect symbols, e.g.

time == _time64

dlltool -x -c -k -m i386 --input-def libtest.def  --dllname
libtest.dll  --output-lib libtest.dll.a

lib /NOLOGO /DEF:libtest.def   /OUT:libtest.lib  /MACHINE:X86

But only dlltool works correctly, MS lib.exe not works, is there a
equipment in MS lib.exe ?

Regards,
Dongsheng

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [RFC] Change the default size of time_t and off_t

[Dongsheng Song]

Since Visual C++ 2005 (released in November 2005), time_t is now a
64-bit integer by default [1] . But mingw-w64 still use 32-bit integer
by default on 32 bit Windows. I recommend use 64-bit integer by
default on 3.0 CRT.

mingw-w64 use off_t 32-bit integer on 64 bit Windows, I think this is a mistake.

[1] http://msdn.microsoft.com/en-us/library/3b2e7499.aspx

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] GCC 4.8 for W32 use __udivdi3 and __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc

[Dongsheng Song]

Hi,

Wen I use gcc 4.8 for win32, I fount gcc use __udivdi3 and __umoddi3
in libgcc_s_sjlj-1.dll but not libgcc, how can avoid it, use gcc 4.7 behavior ?

DLL Name: libgcc_s_sjlj-1.dll
vma:  Hint/Ord Member-Name Bound-To
22248 119  __udivdi3
22254 121  __umoddi3

Regards,
Dongsheng

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC 4.8 for W32 use __udivdi3 and __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc

[Dongsheng Song]

Here is example:

$ cat t-w32.c
long long do_div(long long a, long long b)
{
  return a/b;
}

i686-w64-mingw32-gcc -shared -o t-w32.dll t-w32.c
i686-w64-mingw32-objdump -x t-w32.dll  | grep DLL Name

gcc 4.8:
DLL Name: libgcc_s_sjlj-1.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll

gcc 4.7:
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll

Then I investgate why the gcc 4.8 output dll use libgcc_s_sjlj-1.dll, I found
t-w32.dll use the following symbols in libgcc_s_sjlj-1.dll:

i686-w64-mingw32-objdump -x t-w32.dll  | less

DLL Name: libgcc_s_sjlj-1.dll
vma:  Hint/Ord Member-Name Bound-To
c200   41  __divdi3
c20c  119  __udivdi3
c218  121  __umoddi3

I think this is a regress, isn't it ?


On Mon, Apr 29, 2013 at 11:37 PM, LRN lrn1...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 29.04.2013 19:28, Dongsheng Song wrote:
 Hi,

 Wen I use gcc 4.8 for win32, I fount gcc use __udivdi3 and
 __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc, how can avoid
 it, use gcc 4.7 behavior ?
 What did gcc-4.7 do?

 Also, what do you mean by but not libgcc? but not libgcc-1.dll?
 but not libgcc_s_dw2-1.dll? What?

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (MingW32)

 iQEcBAEBAgAGBQJRfpPOAAoJEOs4Jb6SI2Cwb4QIANjfkReyNqQO4sY0V6qbBd9m
 5eCgfdb96sUp6bPJTsWwH3bUmwY1L8pWD2TSRAYyeqIc6sB1Aetaosc+p3hzc3at
 +fvI4PaYb8g1clmGUY148yUYtXFi5X59gXkUUqsrgyy4UbUCe3NMvjbEtDfTDq1s
 lnEEUmJIuk6x5Ctx2pjeiiiHSn2G4oFQT6PFMiCrO1iRDQenHtHxEsOvzLOFTYIp
 yA2tpI3a/NP4uxVtBrxjaoVl1eX3tn7oLxUwTZ4VkcpkK2TXCkYd6sFo1RG2jIHc
 uq3apXuQAUJxU5ADyFxcvqpbFVVoL78IViyINI4zT08rL28jnKgTKaFoF8+yiZk=
 =iX5M
 -END PGP SIGNATURE-

 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC 4.8 for W32 use __udivdi3 and __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc

[Dongsheng Song]

On Mon, Apr 29, 2013 at 11:53 PM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
 Here is example:

 $ cat t-w32.c
 long long do_div(long long a, long long b)
 {
   return a/b;
 }

 i686-w64-mingw32-gcc -shared -o t-w32.dll t-w32.c
 i686-w64-mingw32-objdump -x t-w32.dll  | grep DLL Name

 gcc 4.8:
 DLL Name: libgcc_s_sjlj-1.dll
 DLL Name: KERNEL32.dll
 DLL Name: msvcrt.dll

 gcc 4.7:
 DLL Name: KERNEL32.dll
 DLL Name: msvcrt.dll

 Then I investgate why the gcc 4.8 output dll use libgcc_s_sjlj-1.dll, I found
 t-w32.dll use the following symbols in libgcc_s_sjlj-1.dll:

 i686-w64-mingw32-objdump -x t-w32.dll  | less

 DLL Name: libgcc_s_sjlj-1.dll
 vma:  Hint/Ord Member-Name Bound-To
 c200   41  __divdi3
 c20c  119  __udivdi3
 c218  121  __umoddi3

 I think this is a regress, isn't it ?


I found in gcc/config/i386/mingw32.h:

/* Include in the mingw32 libraries with libgcc */
#ifdef ENABLE_SHARED_LIBGCC
#define SHARED_LIBGCC_SPEC  \
 %{static|static-libgcc:-lgcc -lgcc_eh} \
 %{!static: \
   %{!static-libgcc: \
 %{!shared: \
   %{!shared-libgcc:-lgcc -lgcc_eh} \
   %{shared-libgcc:-lgcc_s -lgcc} \
  } \
 %{shared:-lgcc_s -lgcc} \
} \
  } 
#else
#define SHARED_LIBGCC_SPEC  -lgcc 
#endif

If I change '-lgcc_s -lgcc' to '-lgcc -lgcc_s', then gcc 4.8 will not
use such symbols like
__divdi3 in libgcc_s_sjlj-1.dll, it back to gcc 4.7 behavior.

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC 4.8 for W32 use __udivdi3 and __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc

[Dongsheng Song]

On Tue, Apr 30, 2013 at 6:13 AM, JonY jo...@users.sourceforge.net wrote:
 On 4/30/2013 00:15, Dongsheng Song wrote:

 If I change '-lgcc_s -lgcc' to '-lgcc -lgcc_s', then gcc 4.8 will not
 use such symbols like
 __divdi3 in libgcc_s_sjlj-1.dll, it back to gcc 4.7 behavior.


 I think this is a deliberate change and not a bug, have you tried
 -static-libgcc instead?


It not works. Because both lib/libgcc_s.a (libgcc_s_sjlj-1.dll）and
lib/gcc/i686-w64-mingw32/4.8.1/libgcc.a
export these symbols:

___absvdi2
___absvsi2
___addtf3
___addvdi3
___addvsi3
___ashldi3
___ashrdi3
___bswapdi2
___bswapsi2
___clear_cache
___clrsbdi2
___clrsbsi2
___clzdi2
___clzsi2
___cmpdi2
___ctzdi2
___ctzsi2
___divdc3
___divdi3
___divsc3
___divtc3
___divtf3
___divxc3
___enable_execute_stack
___eqtf2
___extenddftf2
___extendsftf2
___extendxftf2
___ffsdi2
___ffssi2
___fixdfdi
___fixsfdi
___fixtfdi
___fixtfsi
___fixunsdfdi
___fixunsdfsi
___fixunssfdi
___fixunssfsi
___fixunstfdi
___fixunstfsi
___fixunsxfdi
___fixunsxfsi
___fixxfdi
___floatdidf
___floatdisf
___floatditf
___floatdixf
___floatsitf
___floatundidf
___floatundisf
___floatunditf
___floatundixf
___floatunsitf
___getf2
___gttf2
___letf2
___lshrdi3
___lttf2
___moddi3
___muldc3
___muldi3
___mulsc3
___multc3
___multf3
___mulvdi3
___mulvsi3
___mulxc3
___negdi2
___negtf2
___negvdi2
___negvsi2
___netf2
___paritydi2
___paritysi2
___popcountdi2
___popcountsi2
___powidf2
___powisf2
___powitf2
___powixf2
___subtf3
___subvdi3
___subvsi3
___trunctfdf2
___trunctfsf2
___trunctfxf2
___ucmpdi2
___udivdi3
___udivmoddi4
___umoddi3
___unordtf2

So I think this change is hastily, should be rollback, or make
libgcc_s${LIBGCC_EH_EXTN}-1.dll
DO NOT export extra symbols which not owned their self.

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public