From: Cesar S. <ces...@gm...> - 2010-04-19 16:37:52
|
Dear MinGW community, I am pleased to announce the MinGW.org release of GCC 4.5.0. GCC is the GNU Compiler Collection, a fairly portable optimizing compiler. This MinGW port generates code for 32-bit versions of Windows, and should run on any 32- or 64-bit Windows operating system. No local patches were used in this release. A big thanks to the GCC developers and maintainers for making this possible. This will likely result in faster and more frequent updates, due to reduced maintainer work. New features: ------------- * New TLS support: thread local variables work without the need for external DLLs. See also: http://gcc.gnu.org/gcc-4.5/changes.html General Notes: -------------- * Shared libgcc: If all modules are linked with -shared-libgcc, exceptions can be thrown across DLL boundaries. Note that this is the default for all languages other than C. To disable this, use -static-libgcc. * Shared libstdc++: By default, C++ modules are linked with a DLL version of libstdc++. To use the static version, use the -static-libstdc++ flag. * Translations into your language! See share\locale for a list of codes. Unpack the translation archive in c:\MinGW and set the LANG environment variable to the code of your preferred language. * Inline functions decorated with __declspec(dllexport) are now always generated and included in object files. This also applies to methods defined in classes decorated with __declspec(dllexport). This may cause a general increase in object size, since gcc generates copies of each dllexport'd inline function in all object files whose source includes the header defining the function. Known Issues: ------------- * The Java language is absent, pending resolution of build issues. * When linking C++ modules with shared libstdc++ (the default), the linker may warn about activating auto-import. The workaround is to add one of the following flags: a) -Wl,--enable-runtime-pseudo-reloc-v2 The warning is still printed, but is now harmless. b) -Wl,--enable-auto-import Actually does what the warning suggests. c) -static-libstdc++ Avoids creating the issue in the first place. d) none of the above. You may get a 0xc0000005 error at runtime. * The translation archive, when used, must be unpacked in c:\MinGW. * The path "\mingw\include" on the current drive is always searched for header files, regardless of where the compiler is installed. So, if you want to keep multiple installations separated, better not to use "\mingw" on any drive. Testsuite results: ------------------ The result of the testsuite run for this compiler was submitted to the GCC project. It is available at: http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01614.html Some notes: 1) The -Wl,-enable-auto-import flag was passed to the c++ tests to avoid spurious failures due to the auto-import linker warning. 2) The above creates spurious failures on the pre-compiled header tests. Installing ---------- I will soon update the package information file of the mingw-get installer to let it automatically download and install this release. Meanwhile, it can be installed manually by downloading and unpacking the following archives: (Hint: click on the "File/Folder Name" on the download page to get the categories in alphabetical order) Run-time requirements: GNU Binutils / binutils-2.20.1 binutils-2.20.1-2-mingw32-bin.tar.gz MinGW API for MS-Windows / w32api-3.14 w32api-3.14-mingw32-dev.tar.gz MinGW gmp / gmp-5.0.1-1 libgmp-5.0.1-1-mingw32-dll-10.tar.lzma MinGW mpc / mpc-0.8.1-1 libmpc-0.8.1-1-mingw32-dll-2.tar.lzma MinGW mpfr / mpfr-2.4.1 libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma MinGW pthreads-w32 / pthreads-w32-2.8.0-3 libpthread-2.8.0-3-mingw32-dll-2.tar.lzma (for OpenMP) MinGW Runtime / mingwrt-3.18 mingwrt-3.18-mingw32-dev.tar.gz GCC Version 4 / gcc-4.5.0-1 C Language (required) gcc-core-4.5.0-1-mingw32-bin.tar.lzma C++ Language gcc-c++-4.5.0-1-mingw32-bin.tar.lzma Ada Language gcc-ada-4.5.0-1-mingw32-bin.tar.lzma Fortran Language gcc-fortran-4.5.0-1-mingw32-bin.tar.lzma Objective C/C++ Language gcc-objc-4.5.0-1-mingw32-bin.tar.lzma Shared C Runtime libgcc-4.5.0-1-mingw32-dll-1.tar.lzma Shared C++ Runtime libstdc++-4.5.0-1-mingw32-dll-6.tar.lzma Shared Ada Runtime libgnat-4.5.0-1-mingw32-dll-4.5.tar.lzma Shared Fortran Runtime libgfortran-4.5.0-1-mingw32-dll-3.tar.lzma Shared Objective C/C++ Runtime libobjc-4.5.0-1-mingw32-dll-2.tar.lzma Shared library for OpenMP support libgomp-4.5.0-1-mingw32-dll-1.tar.lzma Shared library for stack protection support libssp-4.5.0-1-mingw32-dll-0.tar.lzma GCC Documentation gcc-4.5.0-1-mingw32-doc.tar.lzma Translations gcc-4.5.0-1-mingw32-lang.tar.lzma License Information gcc-4.5.0-1-mingw32-lic.tar.lzma Regards, Cesar |
From: K. F. <kfr...@gm...> - 2010-04-19 17:09:40
|
To MinGW and Qt Folks - On Mon, Apr 19, 2010 at 12:37 PM, Cesar Strauss <ces...@gm...> wrote: > Dear MinGW community, > > I am pleased to announce the MinGW.org release of GCC 4.5.0. Thanks! MinGW (and GCC) is good stuff. Would it make sense for me to upgrade from the tdm 4.4.1 build to the official MinGW 4.5.0 build? Right now I am doing some non-production, "experimental" programming, focused primarily on playing around with Qt, which is new to me. (I am also using Qwt and lp_solve in my test project, so if you happen to know about those packages, please comment on compatibility, but I haven't cross-posted to those lists, as two lists is probably more than enough...) Has anyone used the new MinGW release with Qt? Any gotcha's? Aside from rebuilding Qt (go out get a cup of coffee -- no, actually a pot of coffee -- oh heck, might as well go out and watch a movie marathon...), is there anything I would have to do to upgrade to the official 4.5.0 build? (I am using 32-bit MinGW on 64-bit windows 7.) Thanks. K. Frank > GCC is the GNU Compiler Collection, a fairly portable optimizing > compiler. > ... |
From: Bob R. <bo...@br...> - 2010-04-19 18:30:15
|
On Mon, Apr 19, 2010 at 01:37:26PM -0300, Cesar Strauss wrote: > Dear MinGW community, > > I am pleased to announce the MinGW.org release of GCC 4.5.0. > > General Notes: > -------------- > > * Shared libgcc: If all modules are linked with -shared-libgcc, > exceptions can be thrown across DLL boundaries. Note that this is > the default for all languages other than C. To disable this, use > -static-libgcc. > > Known Issues: > ------------- It is probably in your best interest to warn users either in General Notes or Known Issues that exceptions in C++ do not work in multithreaded programs, or, has this been resolved? Thanks, Bob Rossi |
From: John E. / T. <td...@td...> - 2010-04-19 18:45:15
|
On 4/19/2010 11:29 AM, Bob Rossi wrote: > On Mon, Apr 19, 2010 at 01:37:26PM -0300, Cesar Strauss wrote: > >> Dear MinGW community, >> >> I am pleased to announce the MinGW.org release of GCC 4.5.0. >> *snip* > It is probably in your best interest to warn users either in > General Notes or Known Issues that exceptions in C++ do not work > in multithreaded programs, or, has this been resolved? > Everything works fine in my multithreaded exceptions testcase (as long as, per the notes, -Wl,--enable-auto-import is used, but that's not related). -John E. |
From: Ehsan A. <aza...@gm...> - 2010-04-19 20:18:15
|
On Mon, Apr 19, 2010 at 12:45 PM, John E. / TDM <td...@td...> wrote: > On 4/19/2010 11:29 AM, Bob Rossi wrote: >> On Mon, Apr 19, 2010 at 01:37:26PM -0300, Cesar Strauss wrote: >> >>> Dear MinGW community, >>> >>> I am pleased to announce the MinGW.org release of GCC 4.5.0. >>> > *snip* >> It is probably in your best interest to warn users either in >> General Notes or Known Issues that exceptions in C++ do not work >> in multithreaded programs, or, has this been resolved? >> > > Everything works fine in my multithreaded exceptions testcase (as long > as, per the notes, -Wl,--enable-auto-import is used, but that's not > related). Does this mean that we do not need any SJLJ version anymore? And as a result for example TDM might change the default binaries to DW2 while maybe keeping the SJLJ version with a suffix (i.e. g++-SJLJ.exe)? I have seen this confuses people who want to link against a library build with a different unwinding. Thanks for the new release, BTW > > -John E. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > 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 > |
From: John E. / T. <td...@td...> - 2010-04-19 20:35:58
|
On 4/19/2010 2:18 PM, Ehsan Azarnasab wrote: > On Mon, Apr 19, 2010 at 12:45 PM, John E. / TDM<td...@td...> wrote: > >> Everything works fine in my multithreaded exceptions testcase (as long >> as, per the notes, -Wl,--enable-auto-import is used, but that's not >> related). >> > Does this mean that we do not need any SJLJ version anymore? And as a > result for example TDM might change the default binaries to DW2 while > maybe keeping the SJLJ version with a suffix (i.e. g++-SJLJ.exe)? I > have seen this confuses people who want to link against a library > build with a different unwinding. > The question of DWARF-2 versus SJLJ unwinding has little to do with multithreading, and additionally TDM-GCC isn't supported by this mailing list or by the MinGW project in general, but I'll answer your question anyway. The consensus among those responsible for the official MinGW GCC releases? No, SJLJ isn't needed anymore. That's why every official release since 4.4.0, including this one, has been DWARF-2 unwinding only. My opinion? Well, there is still code out there that relies on unwinding through frames in system DLLs, and that still breaks with DWARF-2. So in TDM-GCC I elect to stick with SJLJ unwinding as a reasonable default. Since you bring it up, however, I may add some additional language on the TDM-GCC site that explains why mixing object code from different GCC releases using different unwind mechanisms breaks exceptions. -John E. |
From: John E. / T. <td...@td...> - 2010-04-19 21:18:55
|
On 4/19/2010 10:37 AM, Cesar Strauss wrote: > Dear MinGW community, > > I am pleased to announce the MinGW.org release of GCC 4.5.0. > ...and here's your first bug report! I've submitted PR # 2989578 (<http://sourceforge.net/tracker/?func=detail&aid=2989578&group_id=2435&atid=102435>), in summation of which I'll merely state that libstdc++ fstreams can't seek past 2Gb. I also attached the patch I use for it in TDM-GCC to the PR. Cheers, John E. |
From: Takashi O. <t_...@hk...> - 2010-04-19 21:35:57
|
Hi all, In message "[Mingw-users] MinGW GCC 4.5.0 released", Cesar Strauss wrote... >* When linking C++ modules with shared libstdc++ (the default), the > linker may warn about activating auto-import. The workaround is to > add one of the following flags: > a) -Wl,--enable-runtime-pseudo-reloc-v2 > The warning is still printed, but is now harmless. > b) -Wl,--enable-auto-import > Actually does what the warning suggests. > c) -static-libstdc++ > Avoids creating the issue in the first place. > d) none of the above. > You may get a 0xc0000005 error at runtime. What about old -Wl,--enable-runtime-pseudo-reloc ?? b)? I experienced more frequent ICE with precompiled header enabled than 4.4.0 but I suspect it is a con in gcc 4.5.0 itself. I am going to check if COMDAT for language-defined typeinfo is working well with dynamic libstdc++, which is critical for OpenOffice.org build. Best Regrads, ---- Takashi Ono(HK Freak) mailto:t_...@hk... http://www.hkfreak.net http://hkfreak.cocolog-nifty.com/blog/ |
From: Cesar S. <ces...@gm...> - 2010-04-20 01:58:08
|
Takashi Ono wrote: > > What about old -Wl,--enable-runtime-pseudo-reloc ?? > By itself, it can't cope with some kinds of relocations. For example: $ cat app.cpp class foo { public: virtual void bar(); }; void foo::bar() { } int main() { foo f; f.bar(); } $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc Info: resolving vtable for __cxxabiv1::__class_type_info by linking to __imp___ZTVN10__cxxabiv117__class_type_infoE (auto-import) c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. $ ./app.exe (Message box with error 0xc0000005 appears) The following all work: $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc-v2 $ g++ -o app.exe app.cpp -Wl,--enable-auto-import $ g++ -o app.exe app.cpp -static-libstdc++ Regards, Cesar |
From: Earnie <ea...@us...> - 2010-04-20 11:33:08
|
Cesar Strauss wrote: > $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc > The following all work: > $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc-v2 So why do we have two versions? One that works and one that doesn't work? Should the original version just go away and become an alias to -v2? -- Earnie -- http://www.for-my-kids.com |
From: Cesar S. <ces...@gm...> - 2010-04-20 23:37:17
|
Earnie wrote: > Cesar Strauss wrote: > >> $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc > >> The following all work: >> $ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc-v2 > > So why do we have two versions? One that works and one that doesn't > work? Should the original version just go away and become an alias to -v2? > Indeed. In binutils CVS, the v2 version is already on by default. So, in the future, it will be safe to ignore the auto-import warning (and I am working on a patch to silence it altogether). Regards, Cesar |
From: Takashi O. <t_...@hk...> - 2010-04-21 10:02:38
|
Hi Cesar, I understand that old --enable-runtime-pseudo-reloc is buggy and will cause problem. I would like to confirm one thing. You wrote --enable-auto-import and -static-libstdc++ also work. With -static-libstdc++ the shared version of libstdc++ will never be used and the story is completely different. However, in case the binary is linkable by --enable-auto-import without unresolved reference, no gimmick of runtime-pseudo-reloc is neeeded, I think. Your example means --enable-runtime-pseudo-reloc will do some harm even in some case runtime-pseudo-reloc is actually not needed? In message "Re: [Mingw-users] MinGW GCC 4.5.0 released", Cesar Strauss wrote... >Takashi Ono wrote: >> >> What about old -Wl,--enable-runtime-pseudo-reloc ?? >> > >By itself, it can't cope with some kinds of relocations. >For example: > >$ cat app.cpp > >class foo >{ > public: > virtual void bar(); >}; > >void foo::bar() >{ >} > >int main() >{ > foo f; > f.bar(); >} > >$ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc >Info: resolving vtable for __cxxabiv1::__class_type_info by linking to >__imp___ZTVN10__cxxabiv117__class_type_infoE (auto-import) >c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: >warning: auto-importing has been activated without --enable-auto-import >specified on the command line. >This should work unless it involves constant data structures referencing >symbols from auto-imported DLLs. > >$ ./app.exe >(Message box with error 0xc0000005 appears) > >The following all work: >$ g++ -o app.exe app.cpp -Wl,--enable-runtime-pseudo-reloc-v2 >$ g++ -o app.exe app.cpp -Wl,--enable-auto-import >$ g++ -o app.exe app.cpp -static-libstdc++ > >Regards, >Cesar > > >------------------------------------------------------------------------------ >Download Intel® Parallel Studio Eval >Try the new software tools for yourself. Speed compiling, find bugs >proactively, and fine-tune applications for parallel performance. >See why Intel Parallel Studio got high marks during beta. >http://p.sf.net/sfu/intel-sw-dev >_______________________________________________ >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 ---- Takashi Ono(HK Freak) mailto:t_...@hk... http://www.hkfreak.net http://hkfreak.cocolog-nifty.com/blog/ |
From: Cesar S. <ces...@gm...> - 2010-04-21 20:24:06
|
Takashi Ono wrote: > However, in case the binary is linkable by --enable-auto-import without unresolved > reference, no gimmick of runtime-pseudo-reloc is neeeded, I think. Your example means > --enable-runtime-pseudo-reloc will do some harm even in some case runtime-pseudo-reloc > is actually not needed? No, sorry to have given this impression. In fact, --enable-runtime-pseudo-reloc is currently added by default. So, when you specify only -Wl,--enable-auto-import, you are actually using both (-Wl,--enable-auto-import,--enable-runtime-pseudo-reloc). Without runtime-pseudo-reloc, --enable-auto-import would not even work: $ g++ -o app.exe app.cpp \ -Wl,--enable-auto-import,--disable-runtime-pseudo-reloc app.cpp:(.rdata$_ZTI3foo[typeinfo for foo]+0x0): variable 'vtable for __cxxabiv1::__class_type_info' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. collect2: ld returned 1 exit status As I understand it, an effect of using --enable-auto-import is to move constant data from read-only sections in the file to writable sections, so runtime-pseudo-reloc can do its job of relocating without throwing an access violation (0xc0000005). One thing runtime-pseudo-reloc-v2 seems to do is to briefly make these sections writable in memory at run-time, so --enable-auto-import is no longer needed with it. Regards, Cesar |
From: Takashi O. <t_...@hk...> - 2010-04-25 00:48:42
|
Hi Cesar, In message "Re: [Mingw-users] MinGW GCC 4.5.0 released", Cesar Strauss wrote... >As I understand it, an effect of using --enable-auto-import is to move >constant data from read-only sections in the file to writable sections, >so runtime-pseudo-reloc can do its job of relocating without throwing an >access violation (0xc0000005). I have clearly understood. >One thing runtime-pseudo-reloc-v2 seems to do is to briefly make these >sections writable in memory at run-time, so --enable-auto-import is no >longer needed with it. Will runtime-pseudo-reloc-v2 do this even when pseudo relocation is not needed? Or we still have to enable auto-importing if pseudo relocation is not involved? Best Regards, ---- Takashi Ono(HK Freak) mailto:t_...@hk... http://www.hkfreak.net http://hkfreak.cocolog-nifty.com/blog/ |
From: Charles W. <cwi...@us...> - 2010-04-19 22:41:45
|
First, thanks for the new release. I look forward to using it! On 4/19/2010 12:37 PM, Cesar Strauss wrote: > * The path "\mingw\include" on the current drive is always searched for > header files, regardless of where the compiler is installed. So, if > you want to keep multiple installations separated, better not to use > "\mingw" on any drive. I think this should be considered a bug -- if %TMPDIR%/some-random-dir-Hwj201/include/ were always searched, that'd be an oddity, but not of too much concern. However, \mingw\include is the default installation location for our installer(s). So...if I have a "default" installation, and an "alternate" one -- which I do -- then this just broke my "alternate" installation. -- Chuck |
From: Cesar S. <ces...@gm...> - 2010-04-20 01:27:39
|
Charles Wilson wrote: > First, thanks for the new release. I look forward to using it! > > On 4/19/2010 12:37 PM, Cesar Strauss wrote: >> * The path "\mingw\include" on the current drive is always searched for >> header files, regardless of where the compiler is installed. So, if >> you want to keep multiple installations separated, better not to use >> "\mingw" on any drive. > > I think this should be considered a bug -- if > %TMPDIR%/some-random-dir-Hwj201/include/ > were always searched, that'd be an oddity, but not of too much concern. > However, \mingw\include is the default installation location for our > installer(s). > > So...if I have a "default" installation, and an "alternate" one -- which > I do -- then this just broke my "alternate" installation. I agree it is a bug. I'll see what I can do. The issue is not new, however. Try installing any old version, like 3.4.5, in an alternate path and type: echo '#include <stdio.h>' | gcc -E -o /dev/null - -v ... and you will see /mingw/include in the search path. I just thought it was worth mentioning it as a "known isssue". Cesar |
From: Charles W. <cwi...@us...> - 2010-04-20 03:57:42
|
On 4/19/2010 9:27 PM, Cesar Strauss wrote: > The issue is not new, however. Try installing any old version, like > 3.4.5, in an alternate path and type: > > echo '#include <stdio.h>' | gcc -E -o /dev/null - -v > > ... and you will see /mingw/include in the search path. Huh. I thought that previous versions did not exhibit this behavior; I guess it's a good thing I don't use my "alternate" installation very often -- in fact, I usually SWAP the two mingw directories physically... So, it's a bug -- but not a regression. That certainly makes it less of a pressing issue. Thanks for the clarification. -- Chuck |
From: Danny S. <dan...@cl...> - 2010-04-20 06:07:39
|
----- Original Message ----- From: "Charles Wilson" < > On 4/19/2010 9:27 PM, Cesar Strauss wrote: >> The issue is not new, however. Try installing any old version, like >> 3.4.5, in an alternate path and type: >> >> echo '#include <stdio.h>' | gcc -E -o /dev/null - -v >> >> ... and you will see /mingw/include in the search path. > Yes, but it should be the very last in the search path and would normally be overridden by something like: #include <...> search starts here: c:\path-to-alt-mingw\bin\../lib/gcc/mingw32/4.5.0-dw2/../../../../include that is, the relative-to-bin prefix. /mingw/bin is equivalent to /usr/include, as it says in gcc's mingw32.h /* Override the standard choice of /usr/include as the default prefix to try when searching for header files. */ #undef STANDARD_INCLUDE_DIR #define STANDARD_INCLUDE_DIR "/mingw/include" Danny |