Menu
▾
▴
mingw-users
|
From: Edward D. <eld...@tr...> - 2014-12-24 07:41:03
|
I am seeing an out of memory message of: "cc1plus.exe: out of memory allocating 65536 bytes" when compiling code using mingw and gcc-4.8.1-4. Strangely this error does not occur when compiling the exact same code using versions from mingw of gcc-4.3.0 through gcc-4.7.2. Also relevant, although possibly not helpful to this mailing list, is that the same code fails with mingw-64 and its versions of gcc-4.8.1, gcc-4.8.2, gcc-4.8.3, gcc-4.9.0, and gcc-4.9.1. The code is heavily preprocessor code for my VMD library, which also depends on the Boost PP library. In other words the code is almost entirely involved with testing macro expansions in the library. As a piece of related information, which may not be very relevant, the latest clang and versions of vc++ from vc++8 through vc++12 do not exhibit any out of memory errors. It seems gcc has regressed in some way with version 4.8.1 in its handling of memory allocation. Is this a known problem with with this gcc release ? Is anyone involved with gcc trying to fix the problem if it is known ? Or might this just be a problem in Windows with the mingw implementation of gcc ? The code in question is highly complicated, as befits an advanced macro programming library like VMD, so it would be very difficult to reproduce it in some simpler form. But the fact that it occurs in the latest version of mingw gcc-4 but not in the earlier versions suggests something that has been done wrong and might already be known about. I am compiling under Windows 7 Ultimate with 8 GB of real memory, so I do not think this has anything to do with my hardware itself. |
|
From: Eli Z. <el...@gn...> - 2014-12-24 16:25:47
|
> From: Edward Diener <eld...@tr...> > Date: Wed, 24 Dec 2014 02:40:42 -0500 > > I am seeing an out of memory message of: > > "cc1plus.exe: out of memory allocating 65536 bytes" > > when compiling code using mingw and gcc-4.8.1-4. Can you look in the Task Manager or some other similar tool what is cc1plus's memory footprint at that point, or just before that? > Or might this just be a problem in Windows with the mingw > implementation of gcc ? Unlikely. There's no such thing as "the MinGW implementation" of GCC, it's just a Windows compile of the stock GCC code. > I am compiling under Windows 7 Ultimate with 8 GB of real memory, so I > do not think this has anything to do with my hardware itself. Note that a 32-bit compiler is still limited to 2GB, even on a 64-bit OS. |
|
From: マーズ ho h. k. <ma...@th...> - 2014-12-25 00:48:22
|
Hello all, Merry Christmas and Happy New Year. Memory issues are being addressed in the latest C++14 standard as in https://gcc.gnu.org/projects/cxx1y.html Eli Zaretskii wrote: >> From: Edward Diener <eld...@tr...> >> Date: Wed, 24 Dec 2014 02:40:42 -0500 >> >> I am seeing an out of memory message of: >> >> "cc1plus.exe: out of memory allocating 65536 bytes" >> >> when compiling code using mingw and gcc-4.8.1-4. > > Can you look in the Task Manager or some other similar tool what is > cc1plus's memory footprint at that point, or just before that? > >> Or might this just be a problem in Windows with the mingw >> implementation of gcc ? > > Unlikely. There's no such thing as "the MinGW implementation" of GCC, > it's just a Windows compile of the stock GCC code. > >> I am compiling under Windows 7 Ultimate with 8 GB of real memory, so I >> do not think this has anything to do with my hardware itself. > > Note that a 32-bit compiler is still limited to 2GB, even on a 64-bit > OS. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > MinGW-users mailing list > MinGW- us...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette > may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: > mailto:mingw-users- re...@li...?subject=unsubscribe |
|
From: Edward D. <eld...@tr...> - 2014-12-25 01:35:15
|
On 12/24/2014 7:48 PM, マーズ ho han keng wrote: > Hello all, > Merry Christmas and Happy New Year. > Memory issues are being addressed in the latest C++14 > standard as in https://gcc.gnu.org/projects/cxx1y.html Thanks but there is no C++14 features, or even C++11 features, being used in my test except for variadic macros and gcc has supported them for ages now. > > Eli Zaretskii wrote: > >>> From: Edward Diener > <eld...@tr...> >>> Date: Wed, 24 Dec 2014 02:40:42 -0500 >>> >>> I am seeing an out of memory message of: >>> >>> "cc1plus.exe: out of memory allocating 65536 bytes" >>> >>> when compiling code using mingw and gcc-4.8.1-4. >> >> Can you look in the Task Manager or some other similar tool > what is >> cc1plus's memory footprint at that point, or just before > that? >> >>> Or might this just be a problem in Windows with the mingw >>> implementation of gcc ? >> >> Unlikely. There's no such thing as "the MinGW > implementation" of GCC, >> it's just a Windows compile of the stock GCC code. >> >>> I am compiling under Windows 7 Ultimate with 8 GB of real > memory, so I >>> do not think this has anything to do with my hardware > itself. >> >> Note that a 32-bit compiler is still limited to 2GB, even > on a 64-bit >> OS. |
|
From: Edward D. <eld...@tr...> - 2014-12-25 01:31:34
|
On 12/24/2014 11:25 AM, Eli Zaretskii wrote: >> From: Edward Diener <eld...@tr...> >> Date: Wed, 24 Dec 2014 02:40:42 -0500 >> >> I am seeing an out of memory message of: >> >> "cc1plus.exe: out of memory allocating 65536 bytes" >> >> when compiling code using mingw and gcc-4.8.1-4. > > Can you look in the Task Manager or some other similar tool what is > cc1plus's memory footprint at that point, or just before that? Your astute guess is correct. Using gcc-4.8.1-4 the code being compiled shoots up at one point to use as much as 1.3 GB of memory before it gives the out of memory error. When I compile the same code with gcc-4.7.2 the maximum memory being used is approximartely 57 MB. That is quite a difference and definitely suggests a huge memory leak of some kind or some other compiler/preprocessor snafu. In both cases the code being compiled is just preprocessor macros and no C++11 features, other than variadic macros, are even being remotely used. In fact the entire program giving the out of memory error is just a dozen object-like macros and 4 BOOST_TEST lightweight test macros enclosing some macros in my VMD library. While the macro expansion of my macros are pretty heavy duty it should never take anywhere near 1.3 GB to expand them, as gcc-4.7.2 shows. > >> Or might this just be a problem in Windows with the mingw >> implementation of gcc ? > > Unlikely. There's no such thing as "the MinGW implementation" of GCC, > it's just a Windows compile of the stock GCC code. Got it. > >> I am compiling under Windows 7 Ultimate with 8 GB of real memory, so I >> do not think this has anything to do with my hardware itself. > > Note that a 32-bit compiler is still limited to 2GB, even on a 64-bit > OS. Of course but one would hardly expect any compilation to use 1.3 GB of memory. I could report this on the gcc bugzilla tracker but reproducing it using my VMD library, although it is public on Github, will be fairly complicated task ( the latest modular Boost must also be downloaded and setup from Github ) for whomever handles the bug. I was hoping this sort of problem, based on what seems to me to be a large-scale memory leak, would be known for these later versions of gcc and I could find a workaround. |
|
From: Edward D. <eld...@tr...> - 2014-12-25 03:27:59
|
On 12/24/2014 9:13 PM, asmwarrior wrote: > On 2014-12-25 9:31, Edward Diener wrote: >> I could report this on the gcc bugzilla tracker but reproducing it using >> my VMD library, although it is public on Github, will be fairly >> complicated task ( the latest modular Boost must also be downloaded and >> setup from Github ) for whomever handles the bug. I was hoping this sort >> of problem, based on what seems to me to be a large-scale memory leak, >> would be known for these later versions of gcc and I could find a >> workaround. > > I think this bug is already reported, see here: > Bug 56926 – Crash (without ICE) while compiling Boost.Math - > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 Thanks. My issue is not a PCH problem as reported by the above bug. But the report did suggest what might be causing the problem in gcc-4.8.1 and above. In my library I do have headers that include each other, because of macro recursion techniques, and this may be causing gcc-4.8.1 to erroneously allocating memory continuously for some reason. I will put some pre-guards of the form of: #if !defined(SOME_FILE_HEADER_MACRO) #include <some_file.hpp> #endif and see if that fixes gcc-4.8.1 and above. Of course I have header guards on all header files but evidently that is not enough to unconfuse gcc. It is definitely some problem in the compiler. If I report it I will have to describe how to duplicate it, and that will take some time for me to write up. I know gcc is free, thankfully, and I appreciate all those who work on it, but having a regression like this is dismaying. > > This is the reason I still use 4.7.x version of GCC under Windows. I write Boost code and it is necessary to support the latest/greatest as many people use the latest gcc for it C++11/C++14 features. |
|
From: K. F. <kfr...@gm...> - 2014-12-25 04:42:11
|
Hello All! This may not be relevant, but I may have seen a similar memory issue with mingw-w64 (a project distinct from mingw). On Wed, Dec 24, 2014 at 10:27 PM, Edward Diener <eld...@tr...> wrote: > On 12/24/2014 9:13 PM, asmwarrior wrote: >> On 2014-12-25 9:31, Edward Diener wrote: >>> I could report this on the gcc bugzilla tracker but reproducing it using >>> my VMD library, although it is public on Github, will be fairly >>> complicated task ( the latest modular Boost must also be downloaded and >>> setup from Github ) for whomever handles the bug. I was hoping this sort >>> of problem, based on what seems to me to be a large-scale memory leak, >>> would be known for these later versions of gcc and I could find a >>> workaround. >> ... I had what appeared to be an out-of-memory issue with a 64-bit mingw-w64 build of gcc 4.9.2 when building Wt. The Wt build failed when compiling Wt's CssParser.C. This was on a 4 GB machine. I killed off some unnecessary processes and restarted the build. It succeeded, but it looks like compiling CssParser.C took about 2 GB. I wrote this off as "normal," even though it seems very large, because CssParser.C uses the boost spirit template-metaprogramming parser generator, and I presumed that the template-metaprogramming was the source of the memory consumption. But maybe this reflects a problem in gcc, and not the memory needs of compiling Wt / boost. Note, I only tried this with gcc 4.9.2. I have know idea whether I would have seen similarly large memory usage with an earlier gcc such as 4.7. Best. K. Frank |
|
From: Ralph E. <ral...@gm...> - 2014-12-25 01:03:04
|
If you use a 32 bit compiler it does not matter, they are by design unable to access memory above 2GB unless you use Wl,--large--address-aware but it would still be limited to about 4GB regardless. but try the large address aware flag in LDFLAGS it sometimes helps. And merry christmas. Den 25-12-2014 kl. 01:48 skrev マーズ ho han keng: > Hello all, > Merry Christmas and Happy New Year. > Memory issues are being addressed in the latest C++14 > standard as in https://gcc.gnu.org/projects/cxx1y.html > > Eli Zaretskii wrote: > >>> From: Edward Diener > <eld...@tr...> >>> Date: Wed, 24 Dec 2014 02:40:42 -0500 >>> >>> I am seeing an out of memory message of: >>> >>> "cc1plus.exe: out of memory allocating 65536 bytes" >>> >>> when compiling code using mingw and gcc-4.8.1-4. >> Can you look in the Task Manager or some other similar tool > what is >> cc1plus's memory footprint at that point, or just before > that? >>> Or might this just be a problem in Windows with the mingw >>> implementation of gcc ? >> Unlikely. There's no such thing as "the MinGW > implementation" of GCC, >> it's just a Windows compile of the stock GCC code. >> >>> I am compiling under Windows 7 Ultimate with 8 GB of real > memory, so I >>> do not think this has anything to do with my hardware > itself. >> Note that a 32-bit compiler is still limited to 2GB, even > on a 64-bit >> OS. >> >> > ------------------------------------------------------------------------------ >> Dive into the World of Parallel Programming! The Go > Parallel Website, >> sponsored by Intel and developed in partnership with > Slashdot Media, is your >> hub for all things parallel software development, from > weekly thought >> leadership blogs to news, videos, case studies, tutorials > and more. Take a >> look and join the conversation now. > http://goparallel.sourceforge.net >> _______________________________________________ >> MinGW-users mailing list >> MinGW- > us...@li... >> This list observes the Etiquette found at >> http://www.mingw.org/Mailing_Lists. >> We ask that you be polite and do the same. Disregard for > the list etiquette >> may cause your account to be moderated. >> >> _______________________________________________ >> You may change your MinGW Account Options or unsubscribe > at: >> https://lists.sourceforge.net/lists/listinfo/mingw-users >> Also: >> mailto:mingw-users- > re...@li...?subject=unsubscribe > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
|
From: Edward D. <eld...@tr...> - 2014-12-25 01:40:12
|
On 12/24/2014 8:03 PM, Ralph Engels wrote: > If you use a 32 bit compiler it does not matter, they are by design > unable to access memory above 2GB unless you use > Wl,--large--address-aware but it would still be limited to about 4GB > regardless. but try the large address aware flag in LDFLAGS it > sometimes helps. Can I specify this on my command line and, if so, how ? |
|
From: asmwarrior <asm...@gm...> - 2014-12-25 02:09:02
|
On 2014-12-25 9:31, Edward Diener wrote: > I could report this on the gcc bugzilla tracker but reproducing it using > my VMD library, although it is public on Github, will be fairly > complicated task ( the latest modular Boost must also be downloaded and > setup from Github ) for whomever handles the bug. I was hoping this sort > of problem, based on what seems to me to be a large-scale memory leak, > would be known for these later versions of gcc and I could find a > workaround. I think this bug is already reported, see here: Bug 56926 – Crash (without ICE) while compiling Boost.Math - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 This is the reason I still use 4.7.x version of GCC under Windows. Yuanhui Zhang |
|
From: Edward D. <eld...@tr...> - 2014-12-25 05:51:32
|
On 12/24/2014 2:40 AM, Edward Diener wrote: > I am seeing an out of memory message of: > > "cc1plus.exe: out of memory allocating 65536 bytes" > > when compiling code using mingw and gcc-4.8.1-4. > > Strangely this error does not occur when compiling the exact same code > using versions from mingw of gcc-4.3.0 through gcc-4.7.2. > > Also relevant, although possibly not helpful to this mailing list, is > that the same code fails with mingw-64 and its versions of gcc-4.8.1, > gcc-4.8.2, gcc-4.8.3, gcc-4.9.0, and gcc-4.9.1. > > The code is heavily preprocessor code for my VMD library, which also > depends on the Boost PP library. In other words the code is almost > entirely involved with testing macro expansions in the library. As a > piece of related information, which may not be very relevant, the latest > clang and versions of vc++ from vc++8 through vc++12 do not exhibit any > out of memory errors. > > It seems gcc has regressed in some way with version 4.8.1 in > its handling of memory allocation. Is this a known problem with with > this gcc release ? Is anyone involved with gcc trying to fix > the problem if it is known ? Or might this just be a problem in Windows > with the mingw implementation of gcc ? > > The code in question is highly complicated, as befits an advanced macro > programming library like VMD, so it would be very difficult to reproduce > it in some simpler form. But the fact that it occurs in the latest > version of mingw gcc-4 but not in the earlier versions suggests > something that has been done wrong and might already be known about. > > I am compiling under Windows 7 Ultimate with 8 GB of real memory, so I > do not think this has anything to do with my hardware itself. To let anyone interested know, my problem was solved by using the -ftrack-macro-expansion=0 compiler switch. The issue is mentioned at this bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746. |
