Re: [Mingw-w64-public] Various std::experimental::filesystem errata

[Riot]

Sure, but they're embarassingly trivial, as my email suggests.

// build with g++ test_temp_path.cpp -lstdc++fs
#include 
#include 

auto main()->int {
  std::cout << "Temp dir: \"" <<
std::experimental::filesystem::temp_directory_path() << "\"" << std::endl;
  return EXIT_SUCCESS;
}


Temp dir: "terminate called after throwing an instance of
'std::experimental::filesystem::v1::__cxx11::filesystem_error'
  what():  filesystem error: temp_directory_path: Unknown error


Similarly:

// build with g++ test_remove.cpp -lstdc++fs
#include 

auto main()->int {
  std::experimental::filesystem::remove("my_file.txt");
  return EXIT_SUCCESS;
}


terminate called after throwing an instance of
'std::experimental::filesystem::v
1::__cxx11::filesystem_error'
  what():  filesystem error: cannot remove: Unknown error [my_file.txt]



Regards,
Riot

On 3 July 2017 at 21:19, niXman <i.nix...@autistici.org> wrote:

> Riot 2017-07-03 20:04:
>
>> I came across two fairly major inconsistencies with
>> std::experimental::filesystem support today.
>>
>> One is that std::experimental::filesystem::temp_directory_path returns
>> empty every time, with "unknown error."
>>
>> The other is that std::experimental::filesystem::remove silently fails to
>> delete anything.
>>
>
> Hi,
>
> Can you provide testcases, please?
>
>
> --
> Regards, niXman
> ___
> Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
> https://sf.net/p/mingw-w64/
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Various std::experimental::filesystem errata

[Riot]

I came across two fairly major inconsistencies with
std::experimental::filesystem support today.

One is that std::experimental::filesystem::temp_directory_path returns
empty every time, with "unknown error."

The other is that std::experimental::filesystem::remove silently fails to
delete anything.


Regards,
Riot
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

[Riot]

*sorry, I meant unable to build for win xp sp2 using mingw-w64.

It's not a show stopper as that's a very small minority of our customers
who are affected, and they're already used to everyone else dropping
support for them - but it seems unnecessary to take away something that's
working fine, and removing which doesn't benefit anyone.

On 12 June 2017 at 19:01, Riot <rain.back...@gmail.com> wrote:

> Haha, no - although I do work for a game company, I'd rather not say which
> on-list.
>
> Am I mistaken in that the patch affects the CRT?  In which case, defining
> _WIN32_WINNT would only be useful at the point of building mingw-w64 itself
> - building and maintaining our own mingw-w64 is not an option for us with
> our current build pipeline, as we rely on mingw-builds currently.  Any
> change to the default would leave us in future with a toolchain unable to
> build for mingw-w64.
>
> Regards,
> Riot
>
> On 12 June 2017 at 18:46, David Grayson <davidegray...@gmail.com> wrote:
>
>> Riot, do you work for Riot Games?
>>
>> Anyway, in this patch, the line of code being changed is guarded by
>> #ifndef _WIN32_WINNT.  So if you define _WIN32_WINNT yourself, this
>> patch will have no effect on you.  (I'm assuming that the value of
>> _WIN32_WINNT does not affect how the MinGW libraries are compiled, and
>> it only affects what features are available in the header files.)
>>
>> --David
>>
>> On Mon, Jun 12, 2017 at 10:36 AM, Riot <rain.back...@gmail.com> wrote:
>> > I'd like to humbly request a hold on this.
>> >
>> > If it's not broken, why fix it?
>> >
>> > I've been happy to be able to tell our customers that our software
>> works on
>> > win XP (SP2) for a long while; and I don't see anything that's changed
>> that
>> > should require us to end that support.  When we surveyed last year,
>> several
>> > percent of our users still used XP, and we don't really want to leave
>> them
>> > out in the cold without good reason.  Building our own mingw just to
>> > configure it with a lower default support version is out of the question
>> > with our workflow, unfortunately.
>> >
>> > I don't see this as a constructive change, as it doesn't appear to
>> actually
>> > improve anything for anybody.  Can we reconsider?
>> >
>> >
>> > Regards,
>> > Riot
>> >
>> >
>> > On 12 June 2017 at 18:02, Liu Hao <lh_mo...@126.com> wrote:
>> >
>> >> On 2017/6/12 23:17, Martell Malone wrote:
>> >>
>> >>> In that case,
>> >>> I think the best course of immediate action is to bump to Windows 7
>> as Kai
>> >>> suggested.
>> >>> If someone has the time to implement a configure option for changing
>> this
>> >>> default like Ruben suggest that would be a great.
>> >>> Here is a patch for the former.
>> >>> Please Review
>> >>>
>> >>> diff --git a/mingw-w64-headers/crt/_mingw.h.in
>> b/mingw-w64-headers/crt/_
>> >>> mingw.h.in
>> >>> index 2742b115..03de2212 100644
>> >>> --- a/mingw-w64-headers/crt/_mingw.h.in
>> >>> +++ b/mingw-w64-headers/crt/_mingw.h.in
>> >>> @@ -222,7 +222,7 @@ limitations in handling dllimport attribute.  */
>> >>>   #ifndef _WIN32_WINNT
>> >>> -#define _WIN32_WINNT 0x502
>> >>> +#define _WIN32_WINNT 0x601
>> >>>   #endif
>> >>>   #ifndef _INT128_DEFINED
>> >>>
>> >>> Upvote for this. OK for master?
>> >>
>> >> --
>> >> Best regards,
>> >> LH_Mouse
>> >>
>> >>
>> >>
>> >> 
>> >> --
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> ___
>> >> Mingw-w64-public mailing list
>> >> Mingw-w64-public@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>> >>
>> > 
>> --
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > ___
>> > Mingw-w64-public mailing list
>> > Mingw-w64-public@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

[Riot]

Haha, no - although I do work for a game company, I'd rather not say which
on-list.

Am I mistaken in that the patch affects the CRT?  In which case, defining
_WIN32_WINNT would only be useful at the point of building mingw-w64 itself
- building and maintaining our own mingw-w64 is not an option for us with
our current build pipeline, as we rely on mingw-builds currently.  Any
change to the default would leave us in future with a toolchain unable to
build for mingw-w64.

Regards,
Riot

On 12 June 2017 at 18:46, David Grayson <davidegray...@gmail.com> wrote:

> Riot, do you work for Riot Games?
>
> Anyway, in this patch, the line of code being changed is guarded by
> #ifndef _WIN32_WINNT.  So if you define _WIN32_WINNT yourself, this
> patch will have no effect on you.  (I'm assuming that the value of
> _WIN32_WINNT does not affect how the MinGW libraries are compiled, and
> it only affects what features are available in the header files.)
>
> --David
>
> On Mon, Jun 12, 2017 at 10:36 AM, Riot <rain.back...@gmail.com> wrote:
> > I'd like to humbly request a hold on this.
> >
> > If it's not broken, why fix it?
> >
> > I've been happy to be able to tell our customers that our software works
> on
> > win XP (SP2) for a long while; and I don't see anything that's changed
> that
> > should require us to end that support.  When we surveyed last year,
> several
> > percent of our users still used XP, and we don't really want to leave
> them
> > out in the cold without good reason.  Building our own mingw just to
> > configure it with a lower default support version is out of the question
> > with our workflow, unfortunately.
> >
> > I don't see this as a constructive change, as it doesn't appear to
> actually
> > improve anything for anybody.  Can we reconsider?
> >
> >
> > Regards,
> > Riot
> >
> >
> > On 12 June 2017 at 18:02, Liu Hao <lh_mo...@126.com> wrote:
> >
> >> On 2017/6/12 23:17, Martell Malone wrote:
> >>
> >>> In that case,
> >>> I think the best course of immediate action is to bump to Windows 7 as
> Kai
> >>> suggested.
> >>> If someone has the time to implement a configure option for changing
> this
> >>> default like Ruben suggest that would be a great.
> >>> Here is a patch for the former.
> >>> Please Review
> >>>
> >>> diff --git a/mingw-w64-headers/crt/_mingw.h.in
> b/mingw-w64-headers/crt/_
> >>> mingw.h.in
> >>> index 2742b115..03de2212 100644
> >>> --- a/mingw-w64-headers/crt/_mingw.h.in
> >>> +++ b/mingw-w64-headers/crt/_mingw.h.in
> >>> @@ -222,7 +222,7 @@ limitations in handling dllimport attribute.  */
> >>>   #ifndef _WIN32_WINNT
> >>> -#define _WIN32_WINNT 0x502
> >>> +#define _WIN32_WINNT 0x601
> >>>   #endif
> >>>   #ifndef _INT128_DEFINED
> >>>
> >>> Upvote for this. OK for master?
> >>
> >> --
> >> Best regards,
> >> LH_Mouse
> >>
> >>
> >>
> >> 
> >> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> ___
> >> Mingw-w64-public mailing list
> >> Mingw-w64-public@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >>
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

[Riot]

I'd like to humbly request a hold on this.

If it's not broken, why fix it?

I've been happy to be able to tell our customers that our software works on
win XP (SP2) for a long while; and I don't see anything that's changed that
should require us to end that support.  When we surveyed last year, several
percent of our users still used XP, and we don't really want to leave them
out in the cold without good reason.  Building our own mingw just to
configure it with a lower default support version is out of the question
with our workflow, unfortunately.

I don't see this as a constructive change, as it doesn't appear to actually
improve anything for anybody.  Can we reconsider?


Regards,
Riot


On 12 June 2017 at 18:02, Liu Hao <lh_mo...@126.com> wrote:

> On 2017/6/12 23:17, Martell Malone wrote:
>
>> In that case,
>> I think the best course of immediate action is to bump to Windows 7 as Kai
>> suggested.
>> If someone has the time to implement a configure option for changing this
>> default like Ruben suggest that would be a great.
>> Here is a patch for the former.
>> Please Review
>>
>> diff --git a/mingw-w64-headers/crt/_mingw.h.in b/mingw-w64-headers/crt/_
>> mingw.h.in
>> index 2742b115..03de2212 100644
>> --- a/mingw-w64-headers/crt/_mingw.h.in
>> +++ b/mingw-w64-headers/crt/_mingw.h.in
>> @@ -222,7 +222,7 @@ limitations in handling dllimport attribute.  */
>>   #ifndef _WIN32_WINNT
>> -#define _WIN32_WINNT 0x502
>> +#define _WIN32_WINNT 0x601
>>   #endif
>>   #ifndef _INT128_DEFINED
>>
>> Upvote for this. OK for master?
>
> --
> Best regards,
> LH_Mouse
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

[Riot]

Thanks for the detailed response Ruben, I appreciate it.

We do use gold on Linux and perhaps that's the reason we don't encounter
these sorts of issues, although we're building with 64bit tools there in
any case, so perhaps we would only see them in a purely 32bit build
environment.

We've looked at TDM64-GCC before for building on Windows, but we've been
somewhat put off by its slower update rate than Mingw-w64 - their latest
gcc version is currently 5.1.0, whereas we're currently building with 6.3.0
on Windows and using newer features.  I'd like to stay with this project
since we've had such good results with Mingw-w64 for the past number of
years, and this is a very minor hiccup that we can work around;  I was
mostly concerned that it may have been a Mingw-w64-specific bug, as we
could only make it manifest on Windows.

As you say, I'm not entirely enthused by the prospect of digging into ld's
code, and if the issue is indeed upstream, I don't see much hope of having
it fixed in the case of an issue I can only manifest on Windows, and where
the minimal testcase appears to be a project with ~700MB of (closed)
source.  So I'll stick with our workaround for now, in exchange for a very
small performance penalty.  Thank you for clearing up the likely culprit,
and setting my mind at ease, in any case.

You mentioned a Mingw-w64 64bit to 32bit cross-compiler; it sounds like
that may avoid any such issues in future for us - do you happen to know if
anyone is building such a thing regularly and where?

Regards,
Riot

On 14 March 2017 at 22:56, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote:

> The default values can be found in
> https://github.com/gcc-mirror/gcc/blob/master/gcc/params.def
>
> For example, but I guess you already knew where to find those.
>
> Op 14 mrt. 2017 11:55 p.m. schreef "Ruben Van Boxem" <
> vanboxem.ru...@gmail.com>:
>
> > Additionally, if you look at the default values of the parameters you're
> > changing, it seems you're stretching the (compiler) implementation quite
> a
> > bit, so I'm not sure why you are surprised that the compiler can't handle
> > it. It seems like you're loading ten blocks of granite into a minivan and
> > surprised it won't budge.
> >
> > I'm not criticising you, just telling you you're using the tools outside
> > of their design specifications.
> >
> > Ruben
> >
> > Op 14 mrt. 2017 11:48 p.m. schreef "Ruben Van Boxem" <
> > vanboxem.ru...@gmail.com>:
> >
> >> Hello again,
> >>
> >> Op 14 mrt. 2017 9:26 p.m. schreef "Riot" <rain.back...@gmail.com>:
> >>
> >> On 14 March 2017 at 18:53, Ruben Van Boxem <vanboxem.ru...@gmail.com>
> >> wrote:
> >>
> >> > These options look quite... inefficient... and frankly suboptimal. I
> >> hope
> >> > you do regular benchmarking to see if these are actually any/much
> better
> >> > than default -O2 -march=native 'or whatever).
> >>
> >> Yes, we benchmark extensively, and we would not use those options if we
> >> didn't see speed increases.  However, that is not relevant to the topic
> >> here, which is that certain compiler options appear to cause an
> erroneous
> >> claim of memory exhaustion when memory is not, in fact, exhausted.
> >>
> >>
> >> Just making sure. Most people don't know what they're doing, and I'm
> glad
> >> you seem to know what you're doing.
> >>
> >>
> >> Inlining everything is not
> >> > the best optimization.
> >>
> >>
> >> I didn't claim it was.  Again, this is a bit off topic.
> >>
> >>
> >> > Sometimes, -Os (optimizing for speed) can generate
> >> > faster code than inlined and loop unrolled -O2, because of cache
> >> misses. In
> >> > any case, I hope you have hard numbers to back up these very weird
> >> options.
> >> >
> >>
> >> You mean "optimising for size"?  Yes, that can often be true, especially
> >> for small programs.  But I asked about a crash in Mingw-w64, not "how
> >> would
> >> you optimise my software?"
> >>
> >> I don't think it's entirely reasonable to provide "Doctor, my elbow
> hurts
> >> when I do this / Well, don't do that, then!" kind of responses - I'm
> using
> >> features of the compiler that should work, that do work on other
> platforms
> >> and other builds of the compiler, and worked fine until our codebase
> >> reached some unclear threshold beyond which they began to fail, with
> what
> >> appears to be a Ming

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

[Riot]

On 14 March 2017 at 18:53, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote:

> These options look quite... inefficient... and frankly suboptimal. I hope
> you do regular benchmarking to see if these are actually any/much better
> than default -O2 -march=native 'or whatever).

Yes, we benchmark extensively, and we would not use those options if we
didn't see speed increases.  However, that is not relevant to the topic
here, which is that certain compiler options appear to cause an erroneous
claim of memory exhaustion when memory is not, in fact, exhausted.

Inlining everything is not
> the best optimization.


I didn't claim it was.  Again, this is a bit off topic.


> Sometimes, -Os (optimizing for speed) can generate
> faster code than inlined and loop unrolled -O2, because of cache misses. In
> any case, I hope you have hard numbers to back up these very weird options.
>

You mean "optimising for size"?  Yes, that can often be true, especially
for small programs.  But I asked about a crash in Mingw-w64, not "how would
you optimise my software?"

I don't think it's entirely reasonable to provide "Doctor, my elbow hurts
when I do this / Well, don't do that, then!" kind of responses - I'm using
features of the compiler that should work, that do work on other platforms
and other builds of the compiler, and worked fine until our codebase
reached some unclear threshold beyond which they began to fail, with what
appears to be a Mingw-w64 bug.  Whether or not we're right to be using
these options in this specific project is not the question, the question is
whether the compiler is broken, or these features are actually not properly
supported, or whether something else is at fault.


> 2. The RAM usage for the entire system (a stripped down Windows 7 VM) does
> > not seem to exceed 3GB at any point during the linking process, based on
> > observing the windows task manager.  This is the reason that caused me to
> > suspect there was a bug somewhere, rather than the result of actual
> memory
> > pressure.
> >
>
> 3GB is the memory usqge limit of 32-bit processes on Windows 64-bit. You're
> running into architectural OS limitations.
>

With respect, this is simply not the case.  For a start, there is no 3GB
limit - 32bit programs linked with /LARGEADDRESSAWARE have access to 4GB on
Windows, otherwise they're limited to 2GB.  I said the entire system,
Windows included, and the IDE, and all services, are under 3GB at this
time.  Windows 7 alone weighs around 2.5GB in memory from startup on this
VM.  The entire compiler appears to use less than 200MB of memory through
the entire link step until it halts due to the issue - although I can't
confirm this precisely, because the Windows tools do not appear to allow
very precise monitoring.  In any case If the linker were spiking in memory
usage of two gigabytes, that would surely be visible on the task manager
trace, and nothing of the sort appears.  If you can suggest any windows
tools I can use to monitor the peak memory usage of a specific process and
its children, I can try to get a more accurate figure, but it seems to be
significantly lower than any point when memory *should* run out.


> Good to know you found the culprit.
>

> Ruben
>

I'm not really clear on the point you're making here.  It seems to me like
a clear case that a bug exists in Mingw-w64 here; I was hoping you could
either confirm that, or show how I'm doing something wrong that's causing
this behaviour.  I may have worked around the possible bug by disabling the
option, but that doesn't address the root cause.  Are you saying that this
is a user error and using `max-inline-insns-auto=1` is unsupported, and
the compiler is expected to sometimes crash with an erroneously reported
out of memory error when it's given?


Regards,
Riot
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

[Riot]

Thanks for the quick replies.

I have realised now I made a mistake in my original listing, and omitted
some commandline options that had been included by our build script, and
disabling one of these prevents the problem occurring.

The linker options I failed to include in my previous listing were: --param
max-gcse-memory=10 --param max-inline-insns-single=1 --param
max-inline-insns-auto=1 --param inline-min-speedup=20 --param
large-function-insns=1 --param large-function-growth=2000 --param
large-unit-insns=2 --param inline-unit-growth=200

Although we've used these for years without problem, I decided to try
various combinations of options, and narrowed it down to one - removing
just the `max-inline-insns-auto=1` param allows linking to succeed
normally.

The project involved has been steadily growing and I believe the size or
content of some unit may have just passed some threshold that causes this
behaviour to be exhibited; nothing has changed in the compiler options we
use or the version of mingw-w64 since it previously worked successfully.

To answer the questions in the last message:
1. I can't test a 64bit build of this particular project just now, because
we don't currently have 64bit builds of some of the libraries we need to
statically link with, so I can't report on whether this occurs with the
64bit build.  I don't see a 64-to-32bit cross-compiler on windows available
just now, but if there's a build of one available somewhere I'd be happy to
try it out.
2. The RAM usage for the entire system (a stripped down Windows 7 VM) does
not seem to exceed 3GB at any point during the linking process, based on
observing the windows task manager.  This is the reason that caused me to
suspect there was a bug somewhere, rather than the result of actual memory
pressure.
3.  I haven't tried stripping the objects prior to linking;  I was going to
do that until I discovered that I can work around the issue by disabling
the above-mentioned param.  If it would still be useful for me to try this
and test further, I can do - just let me know.

Regards,
Riot

On 13 March 2017 at 16:01, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote:

> Hi,
>
> Just some random helpful thoughts:
> - the linker typically uses a lot more memory than the sum of everything it
> is linking together.
> - LTO is still quite unstable, even on Linux, where I know of no Linux
> distro that actually enables the option to build its binaries.
> - The 32-bit process is limited to its 3 GB of memory, and it might be that
> some (large) allocations start failing due to memory fragmentation, which
> can be very prominent in Windows.
>
> Some questions as well:
> - Does this happen if you would use a 64-bit toolchains (perhaps even a
> 64-bit to 32-bit crosscompiler, if these are still built, probably not...)
> - what is the RAM usage at the point ld bails out?
> - Have you tried stripping the object files as much as possible before
> linking them together? Same for all static and dynamic libraries.
>
> Cheers,
>
> Ruben
>
>
> Op 13 mrt. 2017 1:19 p.m. schreef "Riot" <rain.back...@gmail.com>:
>
> Hi all,
>
> First a bit of background.  We've been building a large number of projects
> with Mingw-w64 on Windows for about five years now, using LTO for our
> release builds without any problems until now.  We are building large
> executables containing a lot of binary assets compiled as objects; input
> objects to the link step for the problematic project currently total 105MB,
> linking to produce a stripped binary of 68MB.  We are building on 64bit
> windows, but for a 32bit target.  The version we're using is g++.exe
> (i686-posix-dwarf-rev1, Built by MinGW-W64 project) 6.3.0.
>
> We have now started to receive the error on the one problematic project:
>
> lto1.exe: out of memory allocating 98173120 bytes
> lto-wrapper.exe: fatal error: g++.exe returned 1 exit status
>
> This is the case on several different machines; the VM from which I
> received this error has over 20GB RAM allocated, and is not coming close to
> exhausting this - memory usage system-wide during the build does not exceed
> 3GB and there is plenty to spare.
>
> I have tried replacing -flto with -whopr as suggested at
> https://sourceforge.net/p/mingw-w64/wiki2/LTO%20and%20GCC/, but this is
> now
> an unrecognised commandline option.
>
> I have tried using -fwpa but I then get "lto1.exe: error: -fwpa and
> -fltrans are mutually exclusive" even though -fltrans is not specified
> anywhere on the commandline.
>
> The full linker commandline is:
> g++.exe  -o  -s -no-pie -flto -static-libstdc++
> -static-libgcc -static -m32 -Wl,--stack,8388608 -fuse-linker-plugin -Ofast
> -mthreads -mmmx -msse -msse2 -m3dnow -maccumulate-outgoing-args -fgcs

[Mingw-w64-public] Erroneous "out of memory" using LTO

[Riot]

Hi all,

First a bit of background.  We've been building a large number of projects
with Mingw-w64 on Windows for about five years now, using LTO for our
release builds without any problems until now.  We are building large
executables containing a lot of binary assets compiled as objects; input
objects to the link step for the problematic project currently total 105MB,
linking to produce a stripped binary of 68MB.  We are building on 64bit
windows, but for a 32bit target.  The version we're using is g++.exe
(i686-posix-dwarf-rev1, Built by MinGW-W64 project) 6.3.0.

We have now started to receive the error on the one problematic project:

lto1.exe: out of memory allocating 98173120 bytes
lto-wrapper.exe: fatal error: g++.exe returned 1 exit status

This is the case on several different machines; the VM from which I
received this error has over 20GB RAM allocated, and is not coming close to
exhausting this - memory usage system-wide during the build does not exceed
3GB and there is plenty to spare.

I have tried replacing -flto with -whopr as suggested at
https://sourceforge.net/p/mingw-w64/wiki2/LTO%20and%20GCC/, but this is now
an unrecognised commandline option.

I have tried using -fwpa but I then get "lto1.exe: error: -fwpa and
-fltrans are mutually exclusive" even though -fltrans is not specified
anywhere on the commandline.

The full linker commandline is:
g++.exe  -o  -s -no-pie -flto -static-libstdc++
-static-libgcc -static -m32 -Wl,--stack,8388608 -fuse-linker-plugin -Ofast
-mthreads -mmmx -msse -msse2 -m3dnow -maccumulate-outgoing-args -fgcse-sm
-fgcse-las -fgcse-after-reload -fsched-spec-load
-fsched-spec-load-dangerous -fmerge-all-constants -fmodulo-sched
-fmodulo-sched-allow-regmoves -funsafe-loop-optimizations -fsched-pressure
-fsched-stalled-insns=0 -fsched-stalled-insns-dep=32
-fsched2-use-superblocks -fipa-pta -ftracer -fno-var-tracking-assignments
-fpeel-loops -funroll-loops -funswitch-loops -ftree-loop-if-convert
-ftree-loop-distribution -ftree-loop-im -ftree-loop-ivcanon -fivopts
-fvariable-expansion-in-unroller -freorder-blocks-and-partition
-fbranch-target-load-optimize -ffast-math -fno-math-errno
-funsafe-math-optimizations -fassociative-math -freciprocal-math
-fno-signed-zeros -fno-trapping-math   -mwindows

It seems like the memory exhaustion error is a bug, since there is plenty
of system memory available (even for a 32bit process) - is that the case,
and is this a known issue?  Is there anything we can do to work around this?

Disabling LTO would be highly undesirable as a workaround in this case, as
the project is a game where performance is very important, and LTO makes a
noticeable difference.

We haven't encountered this problem building the same project with the same
settings natively on GCC under Linux or on MacOS.

Any help would be much appreciated!



Regards,
Riot
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Help building cross-compiler on Linux

[Riot]

 at a complete loss as to how to continue - any help at all
would be appreciated.  If I've gone wrong somewhere earlier along the line,
and could have avoided all the 32bit/64bit makefile fiddling, I would also
love to hear how, as I doubt that the above is how it's supposed to proceed.


Regards,
Riot

...

On 7 December 2016 at 23:25, JonY <jo...@users.sourceforge.net> wrote:

> On 12/07/2016 07:45 PM, Riot wrote:
> > Hi all,
> >
> > I've been using MinGW-w64 for a long while now, but always on windows.
> I'm
> > currently trying to cross-compile windows projects on linux for the first
> > time.
> >
> > The issue I've run into is that std::experimental is not enabled in
> > Debian's packaged version of mingw-w64, which I need for
> > std::experimental::filesystem in several projects (and which is enabled
> in
> > the mingw-builds version on windows).  Since the repository packages
> aren't
> > built the way I need, and it seems there are no linux binary packages for
> > download anywhere on the site, I need to build my own.
> >
> > I've started by downloading and extracting mingw-w64-v5.0.0.tar.bz2 to
> > /usr/src/mingw-w64-v5.0.0 and configuring as follows:
> >
> > tar -xvvjf mingw-w64-v5.0.0.tar.bz2
> > mkdir mingw-w64-v5.0.0-build
> > cd mingw-w64-v5.0.0-build
> > ../mingw-w64-v5.0.0/configure --enable-experimental
> >
> > and I got:
> >
> > ...
> > checking for unistd.h... yes
> > checking _mingw_mac.h usability... no
> > checking _mingw_mac.h presence... no
> > checking for _mingw_mac.h... no
> > configure: error: Please check if the mingw-w64 header set and the
> > build/host option are set properly.
> > configure: error: ../../mingw-w64-v5.0.0/mingw-w64-crt/configure failed
> for
> > mingw-w64-crt
> >
>
> You need to bootstrap, build and install the headers first, and then the
> 1st stage gcc, then crt, lastly complete gcc.
>
>
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Help building cross-compiler on Linux

[Riot]

Hi all,

I've been using MinGW-w64 for a long while now, but always on windows.  I'm
currently trying to cross-compile windows projects on linux for the first
time.

The issue I've run into is that std::experimental is not enabled in
Debian's packaged version of mingw-w64, which I need for
std::experimental::filesystem in several projects (and which is enabled in
the mingw-builds version on windows).  Since the repository packages aren't
built the way I need, and it seems there are no linux binary packages for
download anywhere on the site, I need to build my own.

I've started by downloading and extracting mingw-w64-v5.0.0.tar.bz2 to
/usr/src/mingw-w64-v5.0.0 and configuring as follows:

tar -xvvjf mingw-w64-v5.0.0.tar.bz2
mkdir mingw-w64-v5.0.0-build
cd mingw-w64-v5.0.0-build
../mingw-w64-v5.0.0/configure --enable-experimental

and I got:

...
checking for unistd.h... yes
checking _mingw_mac.h usability... no
checking _mingw_mac.h presence... no
checking for _mingw_mac.h... no
configure: error: Please check if the mingw-w64 header set and the
build/host option are set properly.
configure: error: ../../mingw-w64-v5.0.0/mingw-w64-crt/configure failed for
mingw-w64-crt

The config.log is here: http://hastebin.com/uluvirenok.log

Adding --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=i686-w64-mingw32 doesn't change anything here. _mingw_mac.h does
exist in /usr/src/mingw-w64-v5.0.0/mingw-w64-headers/crt/ but no amount of
tweaking my PATH seems to help; is there some step I'm missing at this
stage?

I haven't been able to find any relevant information on the wiki on
sourceforge (as this step seems to just succeed in the windows
cross-compiling example), so I would really appreciate it if someone can
walk me through comprehensively all the steps required from download
through to successful configure, or point me to some up to date docs I may
have missed that outline these.


Thanks,
Riot
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] sinl/cosl/tanl accuracy problem

[Riot]

Some of us (game developers especially) greatly prefer a minor inaccuracy
to a potentially major slowdown; I would personally opposed this change, as
you're noticeably increasing the cost of something that's used heavily in
tightly looped code.  Perhaps an appropriately named #ifdef switch would be
a way to please everyone here?

Regards,
Riot

On 7 September 2016 at 16:21, lhmouse <lh_mo...@126.com> wrote:

> (I don't write AT assembly so I am unable to make a patch.
> Nevertheless I hope someone who writes AT assembly could fix it.)
>
> The x87 `sinl` instruction has been suffering from an accuracy problem
> since decades ago, which is described in this article:
> https://software.intel.com/blogs/2014/10/09/fsin-
> documentation-improvements-in-the-intel-64-and-ia-32-
> architectures-software
>
> Long story short: Before we can calculate `sin(x)`, we have to reduce `x`
> such that it falls in (-π/2,π/2]. This can be easily done via dividing `x`
> with π and getting the remainder. The problem is that, instead of
> a reasonably accurate value of π, `FSIN` uses a 66-bit approximate value
> as the divisor, which makes the result very inaccurate if `x` is proximate
> to
> some multiple of π, because the remainder would end up with most of
> its upper bits being zero and very few significant bits left.
>
> To compromise with Intel people, as the article suggests, it is essential
> to reduce `x` before executing the `fsin` instruction. This is done as
> follows:
>
> 1. Use `FLDPI` instruction to get an accurate value of π.
> 2. Run `FPREM1` instruction repeatly until the _C2_ bit in FPU status word
> is cleared. The result remainder will be in (-π/2,π/2], and
> the _C0_,_C3_,_C1_ bits are the least three significant bits of
> the quotient, from left to right.
> 3. Calculate the sine value using `FSIN` instruction. This never fails.
> 4. Acknowledging that `sin(x) = -sin(x+kπ)` when `k` is odd and
> `sin(x) = sin(x+kπ)` when `k` is even, because the parity bit of the
> quotient
> is the _C1_ bit in the FPU status word, if it is set, negate the
> result with
> `FCHS` instruction. We get the sine value now.
>
> The above process is the same for cosine.
> In the case of tangent, step 4 should be removed.
>
>
> The following code fragment compares `sinl` from mingw-w64 and
> my own implementation:
>
> volatile auto one = 1.0l;
> auto theta = atanl(one) * 4; // This function is from mingw-w64.
> std::printf("sinl   (theta) = %.16Le\n", sinl   (theta));
> std::printf("my_sinl(theta) = %.16Le\n", my_sinl(theta));
>
> It produces the following result:
>
> sinl   (theta) = 1.6263032587282567e-019
> my_sinl(theta) = -0.e+000
>
> My implementation could be found here:
> https://github.com/lhmouse/MCF/blob/master/MCFCRT/src/stdc/math/sin.c#L12
>
> static inline long double fpu_sin(long double x){
> unsigned fsw;
> const long double reduced = __MCFCRT_fremainder(, x,
> __MCFCRT_fldpi());
> long double ret = __MCFCRT_fsin_unsafe(reduced);
> if(fsw & 0x0200){
> ret = __MCFCRT_fneg(ret);
> }
> return ret;
> }
>
> --
> Best regards,
> lh_mouse
> 2016-09-07
>
>
> 
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Moving sources from SourceForge to something better

[Riot]

Seconded.

On Aug 5, 2016 1:02 AM, "Edward Diener" 
wrote:

> Please, please consider moving mingw-64 sources from SourceForge to some
> better hosting server. SourceForge has morphed into a real disaster
> where downloading files from it are met by numerous tactics of delay and
> failure to force users to view their ads. Programming end-users should
> not have to be up with this nonsense and there are numerous better
> hosting servers for programming sources which do not waste programmer's
> time and patience.
>
> The latest attempts to download distributions with the mingw-64 install
> program are met with delays and failures because SourceForge can no
> longer respond to download requests in any reasonable time. Please give
> uo on an increasingly crippled and crippling SourceForge for something
> better. Thank you !
>
>
> 
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How the program is runing in windowsxp?

[Riot]

Just to chip in, I build on Win XP (32bit) with no special defines set.
The binaries work perfectly fine on XP and all later windows versions.

We do link statically, and use --static-libgcc and --static-libstdc++ on
Windows, to minimise DLL hell issues.

What issue are you having exactly running on XP, what error occurs?  Are
there any particular libraries you're using that might be causing the
problem?

-Riot

On 11 April 2016 at 20:43, Pavel <pa...@pamsoft.cz> wrote:

> Hello,
>
> I think this is not sufficient. -D__USE_MINGW_ANSI_STDIO should help,
> however, my experience is that it somehow cripples swprintf with %s
> placeholder on post-XP systems. So you always need to create separate
> build for XP, if you want to support that system :-(
>
> Pavel
>
>
> On Mon, 2016-04-11 at 14:21 +0200, julien.darthe...@laposte.net wrote:
> > Hello,
> >
> > Can you try to build your program with the g++ flag
> "-D_WIN32_WINNT=0x0501" or maybe "-D_WIN32_WINNT=0x0502"?
> >
> > - Mail original -
> >
> > De: "kl222" <kl...@126.com>
> > À: "mingw android" <mingw.andr...@gmail.com>
> > Cc: mingw-w64-public@lists.sourceforge.net
> > Envoyé: Lundi 11 Avril 2016 03:42:18
> > Objet: [Mingw-w64-public] How the program is runing in windowsxp?
> >
> > Hi all:
> >
> > I use mingw g++ to build a programe. It is running in windows 7 and
> > laster. But it don't run in windowsxp.
> >
> > Use msvc 2013 tools chains build a programe with parameter
> > /SUBSYSTEM:WINDOWS",5.01" . It is running in windowsxp.
> >
> > How do use mingw g++?
> >
> >
> >
> > Thinks!
> >
> >
> --
> > 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! http://pubads.g.doubleclick.net/
> > gampad/clk?id=1444514301=/ca-pub-7940484522588532
> > ___
> > 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! http://pubads.g.doubleclick.net/
> > gampad/clk?id=1444514301=/ca-pub-7940484522588532
> > ___
> > 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
>
--
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

[Mingw-w64-public] Status of Cilk Plus support?

[Riot]

Hi,

Does anybody know the current status of Cilk Plus in MinGW-W64 on Windows?
Cilk is now in mainline GCC as of 5 and in the latest sourceforge builds
the compiler appears to support it, but the necessary runtime link library
libcilkrts is not available.  Are there any plans to include this, or is
there a MinGW compatible build of the library somewhere?  I've been unable
to find one myself.

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

Re: [Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version

[Riot]

Where are you defining your template, in the header or the source? You may
need to explicitly instantiate.
On 24 Jul 2015 13:31, Edward Diener eldlistmaili...@tropicsoft.com
wrote:

 Before attempting to reduce my code to a small enough example to post
 here in its entirety I will give a description of the problem to see if
 anyone has encountered it in general. The problem is purely a linker
 problem.

 I have an exported class in a shared library, called it XX in header
 file XX.hpp. From an executable's source file, called it YY.cpp I
 include the class's header file where the class will show as imported
 and in the code in the source file I throw an exception with an instance
 of the class, as in:

  throw XX(some_constructor_parameters);

 This compiles and links without error.

 If instead I use a template to throw an exception, such as:

  templateclass E void throw_exception(E const  e) { throw e; }

 and then invoke it from my executable as:

  throw_exception(XX(some_constructor_parameters));

 I receive a linker error of the form:

  YY.o: In function `SomeDecoratedName':
  XX.hpp:27: undefined reference to `vtable for XX'
  XX.hpp:27: undefined reference to `vtable for XX'

 I realize that this is not a complete example but before reducing my
 code to the least possible example which will reproduce this problem I
 thought I would ask if anyone has encountered anything like it, or has
 any idea why using a template causes a linker error whereas not using
 the template links would link without any problems.



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

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

Re: [Mingw-w64-public] [[deprecated]]

[Riot]

Use -std=gnu++1y
On 16 Jul 2015 00:09, Hotmail (ArbolOne) arbol...@hotmail.ca wrote:

   C++14 includes the [[deprecated(reason)]] attribute, but in my
 MinGW-64 with GCC-5.1 it creates a warning saying:
 warning: 'deprecated' attribute directive ignored [-Wattributes]|

 How can I find out which features of C++11 and C++14 are available in
 g++5.1?

 Thanks


 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] C++14

[Riot]

I can confirm that __attribute__((deprecated(reason))) definitely
works on mingw-w64 with -std=gnu++1y, and probably with some others.


On 8 July 2015 at 15:06, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:
 Here you can find GCC's C++11 implementation status:
 https://gcc.gnu.org/projects/cxx0x.html

 And the same for C++14:
 https://gcc.gnu.org/projects/cxx1y.html

 Here you can find libstdc++ implementation status:
 https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html

 Make sure you are invoking the compiler with the appropriate -std option
 (e.g. -std=c++14), see
 https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/C-Dialect-Options.html#C-Dialect-Options

 Cheers,

 Ruben

 2015-07-08 15:28 GMT+02:00 p...@arbolone.ca:

 C++14 includes the [[deprecated(reason)]] attribute, but in my MinGW-64
 with GCC-5.1 it creates a warning saying:
 warning: 'deprecated' attribute directive ignored [-Wattributes]|

 How can I find out which features of C++11 and C++14 are available in
 g++5.1?

 Thanks


 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] toUpper()

[Riot]

#include algorithm
#include string

std::string str = Hello World;
std::transform(str.begin(), str.end(), str.begin(), std::toupper);


See also: http://www.cplusplus.com/reference/locale/toupper/

This may also help in future: http://lmgtfy.com/?q=c%2B%2B+toupper

-Riot

On 30 June 2015 at 23:58,  p...@arbolone.ca wrote:
 I would like to write a function to capitalize letters, say...
 std::wstring toUpper(const std::wstring wstr){
 for ( auto it = wstr.begin(); it != wstr.end(); ++it){
 global_wapstr.append(std::towupper(it));

 }
 }

 This doesn’t work, but doesn’t the standard already have something like
 std::wstring::toUpper(...)?

 Thanks in advance


 ---
 This email has been checked for viruses by Avast antivirus software.
 http://www.avast.com


 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] finding the data file

[Riot]

In future can i recommend boost::filesystem to deal with your
os-independent paths
On 18 Jun 2015 22:45, Hotmail (ArbolOne) arbol...@hotmail.ca wrote:

 I found the solution, the answer to my problem is
 getenv(ARBOLONE)

 Thanks folks

 -Original Message-
 From: Max S.
 Sent: Thursday, June 18, 2015 5:12 PM
 To: Hotmail (ArbolOne)
 Cc: MinGW-64 Mailinglist ; gcc-help Mailing List
 Subject: Re: finding the data file

 I'm not a win user, but it looks to me like your problem is that on one
 machine the file is located at
 D:\\Program Files\\ArbolOne\\Sound\\KimPossible.wav
 and on the other at
 C:\\Program Files\\ArbolOne\\Sound\\KimPossible.wav

 You could solve this problem by using relative path. Your executable is
 located at D:\\Program Files\\ArbolOne\\Sounds.exe if launched
 appropriately it's working dir would be D:\\Program Files\\ArbolOne\\
 (or C:\\...) and could reach the file by opening Sound\\KimPossible.wav

 Now, it would probably be better to sense from the working directory
 only the drive letter, or possibly even check for existence of each of
 the files and choosing what to play accordingly.

 On Thu, 2015-06-18 at 16:15 -0400, Hotmail (ArbolOne) wrote:
  This question is exclusively for Win users.
  OK, having said that, I have a desktop and a laptop. In the desktop I use
  MinGW64 and the GCC compier as well as CodeBlock, but on the laptop I use
  VS2015 and VC++. In my desktop I wrote a program that plays a sound file,
  the structure of the file directory is like so:
  D:
  |
  Program Files {parent directory}
  ArbolOne ( folder )
  |__ Sound ( folder )
  |_Sounds.exe
 
  In my application the code looks like this:
 
  player-Play(LD:\\Program Files\\ArbolOne\\Sound\\KimPossible.wav);
 
  This works perfect on my desktop, but the directory tree in my laptop
  looks
  like this
  C:
  |
  Program File {parent directory}
  ArbolOne ( folder )
  |__ Sound ( folder )
  |_Sounds.exe
 
  You see the problem now, I need to some how create in my program a
  variable
  that points to ArbolOne, since in both machines have a Global System
  Variable called
  %ARBOLONE%
  which points to the location of the ArbolOne folder.
  Does any one here know how to unravel this problem.
 
  Thanks
 




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

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

Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1

[Riot]

I have to disagree. I use lto in large production builds with great
success. My use case is performance critical (games) and I build with
-Ofast as well as lto and other heavy optimisations without problems,
generating executable binaries of over a hundred megabytes in size when
stripped and consisting of hundreds of translation units.

Prior to 4.8 lto was incomplete and problematic but most bugs seem to have
been eradicated by gcc 5.0.

In my experience RTTI problems are more likely related to linking objects
that were built with a different version of gcc using lto. Try rebuilding
all your libraries and any linked objects with the same gcc version and
settings. It may also be worth it to try static linking.

Riot
On 29 May 2015 12:21, Etienne Sandré-Chardonnal etienne.san...@m4x.org
wrote:

 That's difficult to know, since the debugger seems to miss some
 information.
 The current function where the crash occurs is unknown :?? in the level 1
 stack view
 For levels 2,3 and 4 I have the function name, but I have no access to the
 location in the code.
 Only level 5 of the stack is fully working in the debugger (all symbols +
 location in code)

 Level 2 is an default assignment operator of my ImageBuffer class. The
 class only contains basic types and std:: containers, no user defined
 pointers, so it likely crashes when copying one of the containers.

 The -flto is clearly not fully usable yet. I was trying it to see if it
 increases performance in a speed-critical app, which has a complex code and
 a lot of function calls between non-virtual classes. This seemed to be a
 good candidate for LTO.

 What did your debugger say? Was the segfault caused by dereferencing a 
 pointer returned by a failed dynamic_cast?

 To my knowledge flto has never been working perfectly since g++ 4.8 on 
 Windows: multiple definitions, undefined references, pointer-to-function 
 referring garbage memory, valid pointers becoming null, random segment 
 faults, etc...
 I strongly suggest you not use flto in production builds.




 --

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


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

Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1

[Riot]

Oh I can absolutely see why you might not want to enable it by default, but
in special cases where performance is worth the extra manual fuss of
working around its very occasional bugs, it's quite useful.

So I did a release build of our current primary project without LTO, and
compared it to our build with LTO.

Before I present the results though, some peculiarities of our build
process to be aware of:

   - We compile all our libraries statically, including libc and libc++
   under windows.  In addition we make heavy use of templates and Boost, so
   our resulting generated object size is large.
   - We include large binary blobs in our release executable itself (game
   music, textures) which increase the final binary size considerably.  I
   subtract these (approximate) blob sizes from the final result for the code
   size difference comparison.
   - There are no debugging symbols included in our release build and the
   binary is stripped with strip -spv.
   - This version is 32bit only.  You may see very different results for
   64bit builds.

Project properties:

   - 27000LOC without includes
   - 200 compiled objects for the linker
  - 26 pre-compiled libraries, 9.27MB
  - 47 binary blobs, 140MB
  - 127 compiled objects (project code), remainder of the size
   - A lot of heavy optimisation options, including -Ofast and several
   unsafe maths optimisations, but also tweaked optimiser params giving the
   optimiser much higher memory limits and function size growth etc than would
   be allowed by default.  Here's a pastebin of all optimisation flags used:
   http://pastebin.com/R6dNCMhP
   - The only difference between the tests was disabling
   -fuse-linker-plugin and -flto for the without-lto build.  Both were built
   from scratch.


Comparison results:
Without LTO.With
LTODifference
Build time  20m 51s 28m
2s  +34%
Object size 152,243,279 bytes   169,512,168
bytes   +11%
Object size minus blobs 4,977,685 bytes 22,246,874
bytes+346%
File size   152,585,216 bytes   150,350,848
bytes   -2%
File size minus blobs   5,319,622 bytes 3,085,254
bytes -42%
Benchmark time  1m 53s  1m
47s  -6%

This is probably not a very good generalisation for the use of LTO since my
use-case is quite specific, but these numbers might be of interest
nevertheless.

In summary, you're basically paying 34% more compilation time (from scratch
- haven't compared partial compiles) and 300% more pre-linked objet size,
and in return getting 42% smaller compiled code size and 6% performance
improvement.  In games, absolutely any measurable performance improvement
is worth any amount of extra compile-time cost, but that may not be true
for other fields.

Regards,
Riot

On 29 May 2015 at 13:27, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:

 2015-05-29 13:36 GMT+02:00 Riot rain.back...@gmail.com:

 I have to disagree. I use lto in large production builds with great
 success. My use case is performance critical (games) and I build with
 -Ofast as well as lto and other heavy optimisations without problems,
 generating executable binaries of over a hundred megabytes in size when
 stripped and consisting of hundreds of translation units.

 Prior to 4.8 lto was incomplete and problematic but most bugs seem to
 have been eradicated by gcc 5.0.


 Interesting, because lto, even on Linux, causes quite some grievances up
 to te point distributions are refusing to enable it for their packages by
 default.

 Would you have any performance numbers (and I guess file sizes) comparing
 lto vs no-lto builds (all the other options remaining unchanged of course)?
 It'd be very interesting to see how lto actually changes things.

 Thanks!

 Ruben

 In my experience RTTI problems are more likely related to linking objects
 that were built with a different version of gcc using lto. Try rebuilding
 all your libraries and any linked objects with the same gcc version and
 settings. It may also be worth it to try static linking.

 Riot
 On 29 May 2015 12:21, Etienne Sandré-Chardonnal etienne.san...@m4x.org
 wrote:

 That's difficult to know, since the debugger seems to miss some
 information.
 The current function where the crash occurs is unknown :?? in the level
 1 stack view
 For levels 2,3 and 4 I have the function name, but I have no access to
 the location in the code.
 Only level 5 of the stack is fully working in the debugger (all symbols
 + location in code)

 Level 2 is an default assignment operator of my ImageBuffer class. The
 class only contains basic types and std:: containers, no user defined
 pointers, so it likely crashes when copying one of the containers.

 The -flto is clearly not fully usable yet. I was trying it to see if it
 increases performance in a speed

Re: [Mingw-w64-public] I am in a in-path

[Riot]

Do you mean I am at an impasse?
On 28 May 2015 00:29, Hotmail (ArbolOne) arbol...@hotmail.ca wrote:

 I am in a in-path. I wrote a class that handles exceptions,
 namespace abc{
 class Exception{...}; // This is my very large Exception class
 }

 The way I'd like to use this class is by creating a smart pointer to it in
 each newly created class, i.e.
 namespace abc{
 class m_class001{
 private:
 std::shared_ptrabc::Exception apex;
 public:
 m_class(){apex.reset(new abc::Exception());}
 m_method(){
 apex-setException(...);
 throw apex;
   }
 };
 }
 auto apex = std::make_sharedabc::Exception();
 int main() {
 try {
 auto obj = std::make_sharedabc::m_class001();
 obj-m_method();
 } catch(std::shared_ptrabc::Exception e) {
 e-DisplaySomething();
 }
 return 0;
 }
 But this can be very expensive, since this possibly-very-large class will
 be
 created in thousands of classes.
 On the other hand, I could create the object when or where the exception
 occurs, like this:
 namespace abc{
 class m_class001{
 private:
 ...
 public:
 m_class(){}
 m_method(){
 ... /* I don't even know if this is possible */
 auto obj = std::make_sharedabc::Exception();
 apex-setException(...);
 throw apex;
   }
 };
 }
 This creates another problem, what if the exception is std::mem_alloc, I
 would ran out of memory, thus I wouldn't be able to create another object.

 I know, I know, this is not a C++ question, but, as I said, I am in a
 in-path, I don't know what to do in this case.
 Any help would be most appreciated.



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

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

Re: [Mingw-w64-public] Ohloh: I Use It

[Riot]

In what way does ohloh affect us, and why do we need to care if the
mingw-w64 project is rated highly on it or not?


On 7 July 2014 21:27, André Hentschel n...@dawncrow.de wrote:

 Hi,
 On Ohloh.net we have only 14 official users ([1]), while mingw has
 nearly 300 and Wine more than 1000...
 I think we should do our best to improve our user count there, because
 Ohloh became somewhat important in the OSS world.
 If you try to add MinGW-w64 to it and you type mingw because you're
 lazy, you'll get a long list of projects. And while mingw-w64-dgn is
 available in that list, MinGW-w64 is not.
 Only if you add a hyphen (mingw-) you'll find MinGW-w64 in the list -
 at the end of the list.

 I first though it's a chicken-egg problem: Having only 14 people marking
 us as I use this makes Ohloh think we're not that popular.
 But mingw-w64-dgn only has one user and is more visible in the list

 Tasks:
 * I just changed the Ohloh project name from MinGW-w64 - for 32 and 64
 bit Windows to MinGW-w64, because the help on it says Please use as
 short a name as possible.
 * We should highlight a button on the website, e.g. I Use It - Simple
 from [2]
 * Collect other ideas to improve the situation


 [1] https://www.ohloh.net/p/mingw-w64
 [2] https://www.ohloh.net/p/mingw-w64/widgets


 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] LTO status?

[Riot]

I currently use LTO in production code.

I and my team have been using LTO since gcc 4.7, although as you say it's
more mature in 4.9.  We are a small games development house so performance
is critical and LTO makes a big difference to our release builds.  However,
I have also seen a few spurious bugs that I was not able to isolate with
4.9.0 that were not present with 4.8; especially one case where perfectly
valid and bug-free code was segfaulting when compiled with LTO; unless
remedied by std::cout-ing one of the variables involved before it was
used in the function call producing the segfault.

We were later able to avoid the bug by not returning a container as we were
doing before, but passing it by reference to the same function.  I would
have liked to be able to report it but i was never able to isolate a clean
test-case, as changing other code in other compile units made it disappear
or reappear arbitrarily (further confirming that it was specifically an
issue with LTO).

However, this was an isolated incident and we haven't had more of those
since; also 4.9.1 is now out which may fix a lot of these issues.  I should
also note that we also optimise our release builds with -Ofast which
enables unsafe math optimisations, which may have been a contributing
factor in that case.  It's hard to debug potential LTO issues because it
doesn't play well with debugging symbols; in fact I recall reading
somewhere that using both LTO and -g can produce undefined compiler
behaviour, although I cannot now find this quote, so you may want to take
that with a pinch of salt.

TL;DR: LTO is mature enough to use in production code, and the benefit is
large, but keep an eye out for any remaining bugs, and test your release
build properly rather than assuming it'll work because your debug build
works.


SlowRiot


On 25 June 2014 15:14, m...@morous.org wrote:


 Hello,

 when I tried LTO (link time optiomization) the last time (gcc 4.8 or 4.7,
 I do not remember precisely), it did not work much for me (frequent
 crashes during my project build with LTO enabled).

 I know gcc dev team spent a lot of time on improving LTO in 4.9.

 So, what is LTO status in mingw-w64 now? Do you consider it already a
 standard feature or is it still experimental thing and there may be lions
 hidden on the way? Anyone out there who already uses mingw-w64 with LTO in
 production?

 Thanks in advance for any feedback,
 Martin



 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Poll] Move to git

[Riot]

[X] Yes, move to git
[ ] No, continue with SVN


On 9 May 2014 14:52, JonY jo...@users.sourceforge.net wrote:

 Hi all,

 You may also use the other thread for further discussion, please keep
 this thread for votes only.

 For mingw-w64 developers, state your SF ID; for the registered voters,
 simply reply with the same email address you registered with.

 [ ] Yes, move to git
 [ ] No, continue with SVN




 --
 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


--
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] Register your vote (was Re: mingw-w64 may move to git in the future)

[Riot]

Hello, I'd like to register to vote.

I'm quite new to the mingw-w64 project, but have been a mingw user for many
years.  I migrated in order to stay up to date with the latest versions of
GCC and because the community is a great deal more accessable than that of
the original mingw project.

My angle is that of a game developer.  I'm interested especially in
optimisation and creating software that will run, and run well, across all
platforms and can be built with purely open-source tools - I'm the rare
breed of game developer who eschews all things microsoft, but of course I
still want my games to be accessable to windows users.

I haven't made any commits, but this is primarily because of my dislike of
the grossly outmoded SVN - However, in my first week of migration to
mingw-w64 I submitted a patch for intrin.h fixing a previously undiscovered
3dnow bug, so I'm not sure if that counts me as a developer or not ;)  I'm
a committed Git user (on windows as well as *nix), I manage 59 different
repositories on Bitbucket and a handful on Github, so no prizes for
guessing which way my vote will go.

If mingw-w64 moves to git, I will be far more willing and comfortable
fixing bugs I come across in future, and won't have to do the whole dance
of creating a diff and a gist and writing to the mailing list hoping
someone else will submit my patch for me.

Regards,
SlowRiot


On 2 May 2014 12:46, Ray Donnelly mingw.andr...@gmail.com wrote:

 I would like to register to vote. My usage of mingw-w64 comes from my
 interest in MSYS2, Qt, general cross-compilers (crosstool-ng) and some
 involvement with the Android NDK. I will have to update some scripts
 if mingw-w64 changes from using SVN to git.

 On Fri, May 2, 2014 at 12:02 PM, JonY jo...@users.sourceforge.net wrote:
  Calling all regular mingw-w64 users, for the benefit of all, let's run a
  poll on user opinions on the move.
 
  In order to qualify to vote, please state how you are using mingw-w64
  and how this change may affect you (what's your stake in it?). You may
  discuss compromises and workarounds. Registration will be open for 1
  week until 9th of May. Please speak up!
 
  As for the mingw-w64 developers, you need only show your SF user IDs
  when voting. As long as you have write access and have made at least 1
  commit with that ID, you get a vote.
 
  Voting will start once registration is closed and will last until the
 16th.
 
 
 
 
 --
  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
 


 --
 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

--
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

[Mingw-w64-public] intrin.h bug when using 3dnow, and patch

[Riot]

When compiling with -m3dnow, intrin.h generates several errors of the type:
c:\mingw32\i686-w64-mingw32\include\intrin.h|755|error: conflicting
declaration of 'void _m_prefetch(void*)' with 'C' linkage

A similar issue has previously been addressed on the mailing list although
i'm away from home so i can't find it right now, but it missed the 3dnow
components.

Patch: https://gist.github.com/slowriot/9903638

There may still be other parts of intrin.h that need #ifdef selected for
other modes, too, but someone more experienced with the project will have
to take care of that :)

Regards,
Riot
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public