Re: [Mingw-w64-public] End of rubenvb builds
2013/6/24 Ozkan Sezer > On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem > wrote: > > Hi everyone, > > > > I have come to the conclusion that my MinGW-w64 builds bring too little > to > > the table for me to continue maintaining them. > > > > I strongly encourage you to use the plethora of toolchains in a > multitude of > > configurations available at mingw-builds. Comparing download numbers they > > have a much higher visibility, and e.g. their adoption by the Qt Project > > speaks of their quality. They have succeeded in doing what I missed when > I > > decided to start building GCC, so my effort spent in doing that is now > > wasted. > > That's sad. I was using your builds from time to time, too. > > Perhaps you can document your build process in the project > resources, e.g. place your scripts in the svn somewhere or > something? > I'll see to get a simple readme in the repository. Source downloads never got included in the build process (although they were a starting point in my now discontinued rewrite effort https://github.com/rubenvb/cross). If you want to get started right away, just download the full source package and replace the sources you want. Note there is no way to determine exactly what version of what package was used in the source tree, which is another shortcoming. "./buildall.sh" builds all the toolchains, you can disable those you don't need or call the build*.sh scripts directly. Ruben > > > > > I may dabble into getting Clang 3.3 to work on Windows, perhaps even with > > libc++, but I am not promising anything. > > > > I'll still linger around here though, don't worry. > > > > All the best, > > > > Ruben > > -- > O.S. > > > -- > 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 > -- 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] End of rubenvb builds
Hello Ruben, 2013/6/23 Ruben Van Boxem : > Hi everyone, > > I have come to the conclusion that my MinGW-w64 builds bring too little to > the table for me to continue maintaining them. > > I strongly encourage you to use the plethora of toolchains in a multitude of > configurations available at mingw-builds. Comparing download numbers they > have a much higher visibility, and e.g. their adoption by the Qt Project > speaks of their quality. They have succeeded in doing what I missed when I > decided to start building GCC, so my effort spent in doing that is now > wasted. > > I may dabble into getting Clang 3.3 to work on Windows, perhaps even with > libc++, but I am not promising anything. > > I'll still linger around here though, don't worry. > > All the best, > > Ruben First, I want to thank you for your hard work you've spent into providing your excellent toolchains over the last years. I am sad to hear that you discontinue it, but I am lucky to hear that you will be still reading this ML. Indeed it would be great, if you could put your build-experience into some documentation/build-scripts in our Wiki/repository. This information is for sure of much interest to our community. Any work on that is mostly appreachiated. That you think that mingw-builds is doing a better job as you did is at least for our community a least one good news ... nevertheless is mingw-builds a different venture, and I am not sure if we should drop that easy our own toolchains. I admit that as long as mingw-builds is well maintained, and build regular toolchains on sane-state of toolchain, it is ok, but as soon as this might not happen anymore we are getting in serious troubles. I don't think we should let third-party ventures manage our work exclusive and not providing some base-knowledge and environment by ourself. Thanks for your work and all the best, Kai -- 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] End of rubenvb builds
On Mon, Jun 24, 2013 at 10:51 AM, Kai Tietz wrote: > Hello Ruben, > > 2013/6/23 Ruben Van Boxem : >> Hi everyone, >> >> I have come to the conclusion that my MinGW-w64 builds bring too little to >> the table for me to continue maintaining them. >> >> I strongly encourage you to use the plethora of toolchains in a multitude of >> configurations available at mingw-builds. Comparing download numbers they >> have a much higher visibility, and e.g. their adoption by the Qt Project >> speaks of their quality. They have succeeded in doing what I missed when I >> decided to start building GCC, so my effort spent in doing that is now >> wasted. >> >> I may dabble into getting Clang 3.3 to work on Windows, perhaps even with >> libc++, but I am not promising anything. >> >> I'll still linger around here though, don't worry. >> >> All the best, >> >> Ruben > > First, I want to thank you for your hard work you've spent into > providing your excellent toolchains over the last years. I am sad to > hear that you discontinue it, but I am lucky to hear that you will be > still reading this ML. > > Indeed it would be great, if you could put your build-experience into > some documentation/build-scripts in our Wiki/repository. This > information is for sure of much interest to our community. Any work > on that is mostly appreachiated. > > That you think that mingw-builds is doing a better job as you did is > at least for our community a least one good news ... nevertheless is > mingw-builds a different venture, and I am not sure if we should drop > that easy our own toolchains. I admit that as long as mingw-builds is > well maintained, and build regular toolchains on sane-state of > toolchain, it is ok, but as soon as this might not happen anymore we > are getting in serious troubles. I don't think we should let > third-party ventures manage our work exclusive and not providing some > base-knowledge and environment by ourself. Very well said, and I second this. I hope Ruben reconsiders. > > Thanks for your work and all the best, > Kai -- O.S. -- 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] End of rubenvb builds
2013/6/24 Ozkan Sezer > On Mon, Jun 24, 2013 at 10:51 AM, Kai Tietz > wrote: > > Hello Ruben, > > > > 2013/6/23 Ruben Van Boxem : > >> Hi everyone, > >> > >> I have come to the conclusion that my MinGW-w64 builds bring too little > to > >> the table for me to continue maintaining them. > >> > >> I strongly encourage you to use the plethora of toolchains in a > multitude of > >> configurations available at mingw-builds. Comparing download numbers > they > >> have a much higher visibility, and e.g. their adoption by the Qt Project > >> speaks of their quality. They have succeeded in doing what I missed > when I > >> decided to start building GCC, so my effort spent in doing that is now > >> wasted. > >> > >> I may dabble into getting Clang 3.3 to work on Windows, perhaps even > with > >> libc++, but I am not promising anything. > >> > >> I'll still linger around here though, don't worry. > >> > >> All the best, > >> > >> Ruben > > > > First, I want to thank you for your hard work you've spent into > > providing your excellent toolchains over the last years. I am sad to > > hear that you discontinue it, but I am lucky to hear that you will be > > still reading this ML. > > > > Indeed it would be great, if you could put your build-experience into > > some documentation/build-scripts in our Wiki/repository. This > > information is for sure of much interest to our community. Any work > > on that is mostly appreachiated. > > > > That you think that mingw-builds is doing a better job as you did is > > at least for our community a least one good news ... nevertheless is > > mingw-builds a different venture, and I am not sure if we should drop > > that easy our own toolchains. I admit that as long as mingw-builds is > > well maintained, and build regular toolchains on sane-state of > > toolchain, it is ok, but as soon as this might not happen anymore we > > are getting in serious troubles. I don't think we should let > > third-party ventures manage our work exclusive and not providing some > > base-knowledge and environment by ourself. > I thought the Makefile under experimental was meant for that. > > Very well said, and I second this. I hope Ruben reconsiders. > Let's say it like this: "I'm whatever Gotham needs me to be [...] A hero. Not the hero we deserved but the hero we needed. Nothing less than a knight. Shining." A glued together quote to ease your minds. I'm just not committing to keep up to date. I'll probably be inexorably drawn into the cruel GNU build system world again. Cheers, Ruben > > > > > Thanks for your work and all the best, > > Kai > > -- > O.S. > > > -- > 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 > -- 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] End of rubenvb builds
I wanted to compile GNUStep(objc) on windows because I would like to debug something and thus I prefer compile everything on windows and not cross-compile from linux. A few years ago I have built an environment(called MaxGW :-) consisting in the msys+mingw and their package manager mingw-get but used with packages compiled with mingw-w64 compiler. So I wanted to use this compiler(4.4.5) but the version is a bit old because it doesn't support objc 2.0 and was compiled from sezero package. So I have downloaded your package i686-w64-mingw32-gcc-4.7.4-release-win32_rubenvb but now I am realizing that there is no support for objc. Ok no problem I am a bit annoyed but it won't stop me because I was used to get sezero package and compile it myself but I couldn't find a corresponding source package on sourceforge. Do you provide it ? -- 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] End of rubenvb builds
On Mon, Jun 24, 2013 at 1:37 AM, Ozkan Sezer wrote: > On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem > wrote: >> Hi everyone, >> >> I have come to the conclusion that my MinGW-w64 builds bring too little to >> the table for me to continue maintaining them. >> >> I strongly encourage you to use the plethora of toolchains in a multitude of >> configurations available at mingw-builds. Comparing download numbers they >> have a much higher visibility, and e.g. their adoption by the Qt Project >> speaks of their quality. They have succeeded in doing what I missed when I >> decided to start building GCC, so my effort spent in doing that is now >> wasted. > > That's sad. I was using your builds from time to time, too. You used to distribute your own builds, too :) > Perhaps you can document your build process in the project > resources, e.g. place your scripts in the svn somewhere or > something? svn/experimental/buildsystem is a perfect place to upload scripts. >> >> I may dabble into getting Clang 3.3 to work on Windows, perhaps even with >> libc++, but I am not promising anything. >> >> I'll still linger around here though, don't worry. >> >> All the best, >> >> Ruben > > -- > O.S. > > -- > 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 -- 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] gcc-4.8.1 build failure libstdc++ string
2013/6/22 Alon Bar-Lev
> Hello,
>
> gcc-4.8.1 failing for some reason, I guess std::vswprintf is incompatible
> for some reason, gcc-4.7.3 works correctly. Using mingw64-runtime-2.0.8.
>
> Example (libstdc++-v3/include/bits/basic_string.h):
> inline wstring
> to_wstring(int __val)
> { return __gnu_cxx::__to_xstring(&std::vswprintf, 4 *
> sizeof(int),
> L"%d", __val); }
>
> Root cause is:
> note: mismatched types ‘std::size_t {aka unsigned int}’ and ‘const
> wchar_t*’
> L"%d", __val); }
>
> Does this ring any bell?
>
Yes: you must use MinGW-w64 trunk for GCC >= 4.8. This requirement allowed
everyone to enjoy std::to_string. Thank your friendly libstdc++ maintainers.
Ruben
>
> Full log is available[1].
>
> Regards,
> Alon Bar-Lev
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=473916
>
> ---
>
> gcc-4.8.1/libstdc++-v3/src/c++11/compatibility-c++0x.cc -DDLL_EXPORT
> -DPIC -D_GLIBCXX_SHARED -o .libs/compatibility-c++0x.o
> In file included from
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/string:52:0,
> from
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/gcc-4.8.1/libstdc++-v3/src/c++11/compatibility-c++0x.cc:26:
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:
> In function ‘std::wstring std::to_wstring(int)’:
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2967:22:
> error: no matching function for call to ‘__to_xstring(int (*)(wchar_t*,
> const wchar_t*, char*), unsigned int, const wchar_t [3], int&)’
> L"%d", __val); }
> ^
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2967:22:
> note: candidate is:
> In file included from
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2815:0,
> from
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/string:52,
> from
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/gcc-4.8.1/libstdc++-v3/src/c++11/compatibility-c++0x.cc:26:
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/ext/string_conversions.h:83:5:
> note: template _String
> __gnu_cxx::__to_xstring(int (*)(_CharT*, std::size_t, const _CharT*,
> char*), std::size_t, const _CharT*, ...)
> __to_xstring(int (*__convf) (_CharT*, std::size_t, const _CharT*,
> ^
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/ext/string_conversions.h:83:5:
> note: template argument deduction/substitution failed:
> In file included from
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/string:52:0,
> from
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/gcc-4.8.1/libstdc++-v3/src/c++11/compatibility-c++0x.cc:26:
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2967:22:
> note: mismatched types ‘std::size_t {aka unsigned int}’ and ‘const
> wchar_t*’
> L"%d", __val); }
> ^
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:
> In function ‘std::wstring std::to_wstring(unsigned int)’:
> /var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2973:22:
> error: no matching function for call to ‘__to_xstring(int (*)(wchar_t*,
> const wchar_t*, char*), unsigned int, const wchar_t [3], unsigned int&)’
> L"%u", __val); }
> ^
>
>
>
> --
> 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
>
>
--
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] gcc-4.8.1 build failure libstdc++ string
On Tue, Jun 25, 2013 at 12:00 AM, Ruben Van Boxem
wrote:
>
> 2013/6/22 Alon Bar-Lev
>>
>> Hello,
>>
>> gcc-4.8.1 failing for some reason, I guess std::vswprintf is incompatible
>> for some reason, gcc-4.7.3 works correctly. Using mingw64-runtime-2.0.8.
>>
>> Example (libstdc++-v3/include/bits/basic_string.h):
>> inline wstring
>> to_wstring(int __val)
>> { return __gnu_cxx::__to_xstring(&std::vswprintf, 4 * sizeof(int),
>> L"%d", __val); }
>>
>> Root cause is:
>> note: mismatched types ‘std::size_t {aka unsigned int}’ and ‘const
>> wchar_t*’
>> L"%d", __val); }
>>
>> Does this ring any bell?
>
>
> Yes: you must use MinGW-w64 trunk for GCC >= 4.8. This requirement allowed
> everyone to enjoy std::to_string. Thank your friendly libstdc++ maintainers.
>
Thanks!
Will wait for release.
--
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] Fast sprintf and 15 times slower std::sprintf
2013/6/22 Albus X
> Hello. I experienced a strange efficiency problem in my code and after
> some debuging I find that std::sprintf is very slow. Indeed it's even
> different from the sprintf function in .
>
> When doing the following test:
>
> #include
> // #include
> // using std::sprintf;
>
> int main () {
> int i;
> for (i = 0; i < 50; i++){
> char x[100];
> sprintf(x, "x%dx%dx", i, i<<2);
> }
> }
>
> the std::sprintf in is 15 times slower. Here is the timing.
>
> $ time ./stdio
>
> real0m0.557s
> user0m0.046s
> sys 0m0.046s
>
> $ time ./cstdio
>
> real0m7.465s
> user0m0.031s
> sys 0m0.077s
>
> I also timed with different mingw-w64 build (rubenvb, drangon, and
> mingw-builds), and find that all 32bit version using timed
> 4.x seconds and 64bit versions 7.x~8.x seconds. And all versions using
> timed around 0.4~0.6 second.
>
> In gdb I find that the sprintf implementation calls msvcrt's sprintf
> after some jumps while std::sprintf calls some mingw function.
>
> Why is that two function different? If there is a reason then why is
> std::sprintf so slow?
>
This is most likely to accomodate libstdc++'s POSIX printf requirements.
This however does not explain why the MinGW-w64 implementation is so slow.
IMHO, this needs to be looked into and optimized. Could you test an old
build that uses the v2.x runtime to see if that changes anything.
Unfortunately, I wouldn't be able to point you to one of my builds that
uses this. I guess GCC 4.7.2 or 4.7.1 releases might use the stable
2.0[7,8] release.
Surely there must be some public domain printf we can rip off of the
internet ;-P
Ruben
>
> --
> 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
>
--
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] Fast sprintf and 15 times slower std::sprintf
On 2013-06-24 5:08 PM, Ruben Van Boxem wrote: > IMHO, this needs to be looked into and optimized. Could you test an old build > that uses the v2.x runtime to see if that changes anything. Unfortunately, I > wouldn't be able to point you to one of my builds that uses this. I guess GCC > 4.7.2 or 4.7.1 releases might use the stable 2.0[7,8] release. http://files.1f0.de/mingw/mingw-w64-gcc-4.7.2-stable-r4.7z ^ Uses GCC 4.7.2 and MinGW-w64 v2.0.7 ^ http://files.1f0.de/mingw/mingw-w64-gcc-4.7.3-stable-r6.7z ^ Uses GCC 4.7.3 and MinGW-w64 v2.0.8 ^ - Derek -- 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] What is the purpose of intrin.h?
So, I have finished the changes I had in mind for this. I have tried to
be clear about how I intend things to work (IOW, there's lots of
comments). Changing headers/includes without breaking something
elsewhere can be challenging, but I'm pretty sure I've got this right.
On the plus side, if something's wrong, it shows up as a compile/link
error, so it's easy to spot.
The patch is attached. Note that there is an updated makefile.am, so
you'll need to re-gen the related .in file. Here's what it includes:
---
- Move all the implementations for the intrinsics I have been working on
from winnt.h to (new file) psdk_inc/intrin-impl.h.
- Use __MINGW_INTRIN_INLINE instead of __CRT_INLINE for functions in
psdk_inc/intrin-impl.h.
- Add comments to intrin.h describing how the MSVC intrinsics work in gcc.
- Add include for intrin-impl.h to intrin.h, protected by #ifdef.
- Since winnt.h sometimes includes intrin.h, only declare the prototypes
for intrinsics (the ones that winnt.h has always declared) if intrin.h
isn't being included.
- Use the same cygwin logic in winnt.h for both x86 and x64.
- Make the corresponding changes to the files in mingw-w64-crt\intrincs
to use the new approach in intrin-impl.h.
It also includes the work from
https://sourceforge.net/mailarchive/message.php?msg_id=31051013:
1) The existing code for __faststorefence doesn't actually generate a
fence. It just generates a barrier. This patch maps __faststorefence
to _mm_sfence (instead of doing MS's trick with "lock or"). sfence
appears to be faster than MS's "fast" approach on modern processors.
2) MS's MemoryBarrier (which is supposed to be a full compiler barrier +
processor fence) maps to __faststorefence. This works for MS because
their __faststorefence trick ends up generating a full fence + full
barrier. Since our __faststorefence now uses sfence, this patch adjusts
MemoryBarrier to use _mm_mfence().
3) While there is a prototype for _ReadWriteBarrier in winnt.h, there is
no implementation. Since _ReadWriteBarrier is -only- a compiler
directive (rather like #pragma), there is no way to place it in a
library. As a result, this patch implements it with a #define in both
winnt.h & intrin.h.
4) Gcc doesn't actually support _ReadBarrier() and _WriteBarrier. This
patch defines them as being mapped to _ReadWriteBarrier() with a #define
in both winnt.h & intrin.h.
5) While there is a prototype for __int2c in winnt.h and intrin.h, there
is no implementation. Since MS docs say this is only available as an
intrinsic (what gcc calls builtin), this patch defines it with a macro
in both winnt.h and intrin.h. (Update: This is now done as an inline
routine + lib version)
6) The code for DbgRaiseAssertionFailure won't compile with
-masm=intel. Use __builtint from intrin-mac.h.
7) Add __buildint to intrin-mac.h for DbgRaiseAssertionFailure & __int2c.
8) On x86, if SSE2 is available, use _mm_pause for YieldProcessor and
_mm_mfence for MemoryBarrier. If SSE2 is not available, build the
appropriate asm ("rep nop" for pause and "xchg" for MemoryBarrier).
---
If I were to change one thing, it would probably be to remove the #ifdef
around the intrin-impl.h include in intrin.h. Why? When I tried to
write the comment about when you might want to use
__INTRINSIC_LIBRARY_ONLY, I couldn't come up with a single case. Adding
complexity with no corresponding benefit is something I try to avoid.
And while I'd *like* to change the definition for _ReadWriteBarrier from:
#define _ReadWriteBarrier() __asm__ __volatile__ ("" ::: "memory")
to
extern __inline__ __attribute__((__always_inline__,__gnu_inline__))
void _ReadWriteBarrier()
{
__asm__ __volatile__ ("" ::: "memory");
}
I can't completely convince myself they are -exactly- the same. Using an
empty asm block is a tricky thing. For example, since there is no
actual asm output, you cannot put this in a library and expect it to
work. What's more, simply by virtue of the fact that you are calling a
routine, you can implicitly get some of the effects of the memory
barrier. But just because sometimes it looks like it might be working
isn't the same as it being right.
dw
Index: mingw-w64-crt/intrincs/__faststorefence.c
===
--- mingw-w64-crt/intrincs/__faststorefence.c (revision 0)
+++ mingw-w64-crt/intrincs/__faststorefence.c (working copy)
@@ -0,0 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___faststorefence // Causes code generation in
intrin-impl.h
+
+#include
Index: mingw-w64-crt/intrincs/__int2c.c
===
--- mingw-w64-crt/intrincs/__int2c.c(revision 0)
+++ mingw-w64-crt/intrincs/__int2c.c(working copy)
@@ -0,0 +1,4 @@
+#define __INTRI
Re: [Mingw-w64-public] gcc-4.8.1 build failure libstdc++ string
2013/6/25 Alon Bar-Lev
> On Tue, Jun 25, 2013 at 12:00 AM, Ruben Van Boxem
> wrote:
> >
> > 2013/6/22 Alon Bar-Lev
> >>
> >> Hello,
> >>
> >> gcc-4.8.1 failing for some reason, I guess std::vswprintf is
> incompatible for some reason, gcc-4.7.3 works correctly. Using
> mingw64-runtime-2.0.8.
> >>
> >> Example (libstdc++-v3/include/bits/basic_string.h):
> >> inline wstring
> >> to_wstring(int __val)
> >> { return __gnu_cxx::__to_xstring(&std::vswprintf, 4 *
> sizeof(int),
> >> L"%d", __val); }
> >>
> >> Root cause is:
> >> note: mismatched types ‘std::size_t {aka unsigned int}’ and ‘const
> wchar_t*’
> >> L"%d", __val); }
> >>
> >> Does this ring any bell?
> >
> >
> > Yes: you must use MinGW-w64 trunk for GCC >= 4.8. This requirement
> allowed everyone to enjoy std::to_string. Thank your friendly libstdc++
> maintainers.
> >
>
> Thanks!
> Will wait for release.
>
> Wait for what?
Try it!
http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/
>
> --
> 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
>
--
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] Fast sprintf and 15 times slower std::sprintf
Thank you for your response, here is my test result:
/d/Downloads/mingw $ cat sprintf.cc
#include
#define MAX 50
int main () {
int i;
for (i = 0; i < MAX; i++){
charx[100];
sprintf(x, "x%dx%dx", i, i<<2);
}
}
/d/Downloads/mingw $ cat stdsprintf.cc
#include
using std::sprintf;
#define MAX 50
int main () {
int i;
for (i = 0; i < MAX; i++){
charx[100];
sprintf(x, "x%dx%dx", i, i<<2);
}
}
/d/Downloads/mingw $ for i in `ls -d --color=never */bin`;
> do echo $i; cd $i;
> ./i686-w64-mingw32-g++ --version;
> ./i686-w64-mingw32-g++ -o ../../sprintf.exe ../../sprintf.cc
> ./i686-w64-mingw32-g++ -o ../../stdsprintf.exe ../../stdsprintf.cc
> time ../../sprintf.exe;
> time ../../stdsprintf.exe;
> ./x86_64-w64-mingw32-g++ --version;
> ./x86_64-w64-mingw32-g++ -o ../../sprintf64.exe ../../sprintf.cc
> ./x86_64-w64-mingw32-g++ -o ../../stdsprintf64.exe ../../stdsprintf.cc
> time ../../sprintf64.exe;
> time ../../stdsprintf64.exe;
> cd ../..
> rm *.exe
> done
mingw-w64-gcc-4.7.2-stable-r4/bin
i686-w64-mingw32-g++.exe (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real0m0.632s
user0m0.046s
sys 0m0.062s
real0m4.867s
user0m0.062s
sys 0m0.046s
x86_64-w64-mingw32-g++.exe (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real0m0.620s
user0m0.047s
sys 0m0.031s
real0m8.482s
user0m0.046s
sys 0m0.046s
mingw-w64-gcc-4.7.3-stable-r6/bin
i686-w64-mingw32-g++.exe (GCC) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real0m0.634s
user0m0.078s
sys 0m0.031s
real0m4.901s
user0m0.031s
sys 0m0.077s
x86_64-w64-mingw32-g++.exe (GCC) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real0m0.555s
user0m0.062s
sys 0m0.031s
real0m8.601s
user0m0.047s
sys 0m0.062s
On Tue, Jun 25, 2013 at 5:29 AM, Derek Buitenhuis
wrote:
> On 2013-06-24 5:08 PM, Ruben Van Boxem wrote:
>> IMHO, this needs to be looked into and optimized. Could you test an old
>> build that uses the v2.x runtime to see if that changes anything.
>> Unfortunately, I wouldn't be able to point you to one of my builds that uses
>> this. I guess GCC 4.7.2 or 4.7.1 releases might use the stable 2.0[7,8]
>> release.
>
> http://files.1f0.de/mingw/mingw-w64-gcc-4.7.2-stable-r4.7z
>
> ^ Uses GCC 4.7.2 and MinGW-w64 v2.0.7 ^
>
> http://files.1f0.de/mingw/mingw-w64-gcc-4.7.3-stable-r6.7z
>
> ^ Uses GCC 4.7.3 and MinGW-w64 v2.0.8 ^
>
> - Derek
>
> --
> 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
--
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] gcc-4.8.1 build failure libstdc++ string
On Tue, Jun 25, 2013 at 5:29 AM, Alexey Pavlov wrote:
>
>
>
> 2013/6/25 Alon Bar-Lev
>>
>> On Tue, Jun 25, 2013 at 12:00 AM, Ruben Van Boxem
>> wrote:
>> >
>> > 2013/6/22 Alon Bar-Lev
>> >>
>> >> Hello,
>> >>
>> >> gcc-4.8.1 failing for some reason, I guess std::vswprintf is
>> >> incompatible for some reason, gcc-4.7.3 works correctly. Using
>> >> mingw64-runtime-2.0.8.
>> >>
>> >> Example (libstdc++-v3/include/bits/basic_string.h):
>> >> inline wstring
>> >> to_wstring(int __val)
>> >> { return __gnu_cxx::__to_xstring(&std::vswprintf, 4 *
>> >> sizeof(int),
>> >> L"%d", __val); }
>> >>
>> >> Root cause is:
>> >> note: mismatched types ‘std::size_t {aka unsigned int}’ and ‘const
>> >> wchar_t*’
>> >> L"%d", __val); }
>> >>
>> >> Does this ring any bell?
>> >
>> >
>> > Yes: you must use MinGW-w64 trunk for GCC >= 4.8. This requirement
>> > allowed everyone to enjoy std::to_string. Thank your friendly libstdc++
>> > maintainers.
>> >
>>
>> Thanks!
>> Will wait for release.
>>
> Wait for what?
> Try it!
> http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/
Thanks!
Gentoo provides a method for building from source.
We can take a snapshot of trunk but there is a reason why you guys
have not released, right?
--
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
