Re: [Mingw-w64-public] [PATCH 1/2] Make dnsapi.def up to date.
On Thu, Feb 4, 2016 at 6:18 PM, Kai Tietzwrote: > 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
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
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_mousewrote: > 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
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
On Tue, Mar 1, 2016 at 8:42 PM, Ismail Donmezwrote: > 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
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
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?
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]
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]
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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'
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'
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
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
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
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
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
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
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.
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
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_*.
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...
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
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
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...
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...
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
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.
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.
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.
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
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
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
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
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
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
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
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.
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.
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.
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
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
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
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
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.
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...
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
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
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...
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
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...
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...
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...
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
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
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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 ?
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
~/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
$ 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
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
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
于 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
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
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
*) 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
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 ?
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 ?
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 ?
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 ?
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
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
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
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
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
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
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
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
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