From: Aaron W. L. <aar...@aa...> - 2008-04-04 02:52:03
|
I've uploaded a binary release of GCC 4.3.0 to the FRS. You can get it in the usual place in the FRS as either gcc-4.3.0-mingw-alpha-20080403.7z or gcc-4.3.0-mingw-alpha-20080403.tar.gz. I've included a version in 7-Zip because its smaller by a huge factor. Note there is only a single tarball, because I'd really like people to look at the whole compiler. The next alpha release will be split in the usual way. This release is intended for testing GCC, and not for general development use. Warning: This is an alpha release. That means the build contains serious problems that are likely to cause serious problems, including silent incorrect code compilation. Instructions: Extract it somewhere. Add the bin/ folder to your PATH variable. If you extract this over your existing MinGW installation, it will replace your current GCC version's driver executables and documentation. This release uses about 500 megabytes of disk space when decompressed. This is a GCC 4.3.0 tree, with the following changes shared libgcc enabled vtable symbol fix main symbol fix static object build system fix These are mainly derived from Danny's 4.2 patchset. All languages (Ada, C, C++, Fortran, Java, Objective-C, Objective-C++) appear to be basically working. The testsuite results are fairly bad, so they may not be working very well. Two major components are disabled : OpenMP support and mudflap pointer checking. This release is probably ABI incompatible with all other GCC versions for all languages other than C. C should be OK for portable code that isn't compiled with exception support. This release is compiled to support Dwarf2 exception handling only. Dwarf2 is mutually incompatible with all other exception handling schemes, and foreign frames. If you want to throw exceptions between modules, you need to compile with -shared-gcclib. |
From: Aaron G. <an...@be...> - 2008-04-04 14:39:17
|
Hi Aaron, A few dumb question here. > I've uploaded a binary release of GCC 4.3.0 to the FRS. Whats the FRS ? > You can get it in the usual place in the FRS as either > gcc-4.3.0-mingw-alpha-20080403.7z or > gcc-4.3.0-mingw-alpha-20080403.tar.gz. > > This release is intended for testing GCC, and not for general > development use. > > Warning: This is an alpha release. That means the build contains > serious problems that are likely to cause serious problems, including > silent incorrect code compilation. Okay, will test. > Instructions: > > Extract it somewhere. Add the bin/ folder to your PATH variable. > If you extract this over your existing MinGW installation, it will > replace your current GCC version's driver executables and documentation. > > This release uses about 500 megabytes of disk space when decompressed. > > > This is a GCC 4.3.0 tree, with the following changes > > shared libgcc enabled > vtable symbol fix > main symbol fix > static object build system fix > > These are mainly derived from Danny's 4.2 patchset. Are these patches availiable some where, or are they from 4.2 diff's ? > All languages (Ada, C, C++, Fortran, Java, Objective-C, Objective-C++) > appear to be basically working. The testsuite results are fairly bad, > so they may not be working very well. > > Two major components are disabled : OpenMP support and mudflap pointer > checking. > > This release is probably ABI incompatible with all other GCC versions > for all languages other than C. C should be OK for portable code that > isn't compiled with exception support. > > This release is compiled to support Dwarf2 exception handling only. > Dwarf2 is mutually incompatible with all other exception handling > schemes, and foreign frames. > > If you want to throw exceptions between modules, you need to compile > with -shared-gcclib. Is this compiled on Cygwin or with MinGW ? Aaron |
From: Greg C. <gch...@sb...> - 2008-04-04 15:05:23
|
On 2008-04-04 14:39Z, Aaron Gray wrote: > >> I've uploaded a binary release of GCC 4.3.0 to the FRS. > > Whats the FRS ? "File Release System", i.e.: http://sourceforge.net/project/showfiles.php?group_id=2435 |
From: Aaron W. L. <aar...@aa...> - 2008-04-04 22:08:58
|
Aaron Gray wrote: > Are these patches availiable some where, or are they from 4.2 diff's ? They are not available presently. The entire patched source is available for download, however, so you could generate the diffs yourself if you wanted them. In the future, this will be packaged separately. > Is this compiled on Cygwin or with MinGW ? It is a MinGW build, but I used tools from the Cygwin environment to meet GCC's prerequisites. I did not use MSYS; recent versions of MSYS apparently have no trouble compiling GCC, though, and it should give similar results. |
From: Aaron G. <an...@be...> - 2008-04-05 15:07:37
|
> Aaron Gray wrote: > >> Are these patches availiable some where, or are they from 4.2 diff's ? > > They are not available presently. The entire patched source is > available for download, however, so you could generate the diffs > yourself if you wanted them. In the future, this will be packaged > separately. Okay, thanks I have already done diff's but I was wondering if there was any documentation at all :) >> Is this compiled on Cygwin or with MinGW ? > > It is a MinGW build, but I used tools from the Cygwin environment to > meet GCC's prerequisites. I did not use MSYS; recent versions of MSYS > apparently have no trouble compiling GCC, though, and it should give > similar results. Okay this is good. Thanks for the reply, Aaron |
From: John E. / T. <td...@td...> - 2008-04-04 18:27:43
|
Here's your first bug report: Remember the packaging bug in the first binutils 2.18.50 tech preview that was pinned down in the "Necessary environment path settings" thread? This release gets at that same issue from the other direction. Since it was configured without a specific --build, --host or --target, it defaulted to the autodetected "i386-pc-mingw32" platform string. However this means that it looks for binutils in "<mingw>/i386-pc-mingw32/bin" rather than "<mingw>/mingw32/bin". Suggested fix: add "--build=mingw32" to the configure invocation. (As gleaned from http://www.nabble.com/Re%3A-Standards-for-Building-MinGW-Release-Packages--(was%3A--Mingw-users--Necessary-environment-path-settings-)-p16360778.html.) -John E. |
From: Aaron W. L. <aar...@aa...> - 2008-04-04 22:38:14
|
Thanks for the report, but see below. John E. / TDM wrote: > Remember the packaging bug in the first binutils 2.18.50 tech preview that > was pinned down in the "Necessary environment path settings" thread? This > release gets at that same issue from the other direction. Since it was > configured without a specific --build, --host or --target, it defaulted to > the autodetected "i386-pc-mingw32" platform string. OK, I'll admit I didn't pay close enough addition to that discussion, but I don't really understand this bug. > However this means that > it looks for binutils in "<mingw>/i386-pc-mingw32/bin" rather than > "<mingw>/mingw32/bin". I don't believe that it does this. GCC finds 'as' and 'ld' on the PATH, which is the same way it finds it on any other native GCC target, which is also the same way GCJ finds 'ecj1', for example. I wasn't aware it was even possible to do something different for a native build without giving GCC special options. You can verify this by passing -Wl,-debug on the link line, which will cause collect2 to tell you where its finding the linker, or -v on the compile line, which will tell you how GCC is finding the assembler. What is the actual manifestation of this problem? What sort of problem did it cause with the build? |
From: John E. / T. <td...@td...> - 2008-04-05 03:57:34
|
I had deluded myself into thinking I could get away with using Outlook Express with impunity. My apologies for inflicting the consequences of that on anyone who read the message duplicated herein. Aaron W. LaFramboise wrote: > OK, I'll admit I didn't pay close enough addition to that discussion, > but I don't really understand this bug. > Sorry, I had assumed you followed it. Basically, this bug only manifests itself when the MinGW/GCC bin directory is *not* present in PATH -- e.g. GCC is run with a fully-qualified command line, like "C:\path\to\mingw\bin\gcc.exe -o myprogram mysources". It is in fact highly useful to be able to run GCC on Windows without any additions to PATH, particularly when working with multiple versions of it or when running it from and IDE. The GCC drivers (gcc.exe and friends, as well as collect2) actually search for their subprograms ("cc1", "as", and "ld" via collect2 in a typical C compilation) in a predefined set of locations which you cna view by running "gcc.exe -print-search-dirs". Only if the subprogram is not found in any of those locations does it fall back on an unqualified invocation. You will see this when you compare the verbose output of a previous GCC release with your new one: in 3.4.5, the invocation of "as" is fully qualified; in the alpha 4.3.0, it is unqualified (and therefore fails if the directory containing it isn't in PATH). Below is an abridged transcription of a Windows shell session which demonstrates this: D:\JDevel\test>D:\JDevel\MinGW\mingw-gcc-3.4.5\bin\gcc.exe -v -o test.exe main.c Reading specs from D:/JDevel/MinGW/mingw-gcc-3.4.5/bin/../lib/gcc/mingw32/3.4.5/ specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as - -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync hronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw-vista special r2) <*** cc1 invocation snipped***> D:/JDevel/MinGW/mingw-gcc-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw3 2/bin/as.exe -o D:\DOCUME~1\John\LOCALS~1\Temp/ccqP4ilE.o D:\DOCUME~1\John\LOCAL S~1\Temp/ccxWAvll.s <*** collect2 invocation snipped***> D:\JDevel\test>D:\JDevel\MinGW\mingw-gcc-4.3.0\bin\gcc.exe -v -o test.exe main.c Using built-in specs. Target: i386-pc-mingw32 Configured with: ../gcc-4.3.0/configure --prefix=/mingw --disable-nls --enable-l anguages=c,c++,fortran,objc,obj-c++,ada,java --disable-win32-registry --disable- sjlj-exceptions --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/mingw/src/gcc/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --enable-libgcj --enable-concept-checks --enable-shared Thread model: win32 gcc version 4.3.0 (GCC) <*** cc1 invocation snipped***> COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=i386' as -o D:\DOCUME~1\John\LOCALS~1\Temp/cc2779xd.o D:\DOCUME~1\John\LOCALS~1\Temp/ ccqhufMa.s gcc.exe: CreateProcess: No such file or directory Finally, straight from the horse's mouth: <http://www.nabble.com/Re%3A-Necessary-environment-path-settings--p16243810.html>. Cheers, John E. |
From: John E. / T. <td...@td...> - 2008-04-05 03:35:09
|
Aaron W. LaFramboise wrote: > OK, I'll admit I didn't pay close enough addition to that discussion, > but I don't really understand this bug. Sorry, I had assumed you followed it. Basically, this bug only manifests itself when the MinGW/GCC bin directory is *not* present in PATH -- e.g. GCC is run with a fully-qualified command line, like "C:\path\to\mingw\bin\gcc.exe -o myprogram mysources". It is in fact highly useful to be able to run GCC on Windows without any additions to PATH, particularly when working with multiple versions of it or when running it from an IDE. The GCC drivers (gcc.exe and friends, as well as collect2) actually search for their subprograms ("cc1", "as" and "ld" via collect2 in a typical C compilation) in a predefined set of locations which you can view by running "gcc.exe -print-search-dirs". Only if the subprogram is not found in any of those locations does it fall back on an unqualified invocation. You will see this when you compare the verbose output of a previous GCC release with your new one: in 3.4.5, the invocation of "as" is fully qualified; in the alpha 4.3.0, it is unqualified (and therefore fails if the directory containing it isn't in PATH). Below is an abridged transcription of a Windows shell session which demonstrates this: D:\JDevel\test> D:\JDevel\MinGW\mingw-gcc-3.4.5\bin\gcc.exe -v -o test.exe main.c Reading specs from D:/JDevel/MinGW/mingw-gcc-3.4.5/bin/../lib/gcc/mingw32/3.4.5/ specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as - -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync hronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw-vista special r2) <***cc1 invocation snipped***> D:/JDevel/MinGW/mingw-gcc-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/as.exe -o D:\DOCUME~1\John\LOCALS~1\Temp/ccqP4ilE.oD:\DOCUME~1\John\LOCALS~1\Temp/ccxWAvll.s<***collect2 invocation snipped***>D:\JDevel\test> D:\JDevel\MinGW\mingw-gcc-4.3.0\bin\gcc.exe -v -o test.exemain.cUsing built-in specs.Target: i386-pc-mingw32Configured with:../gcc-4.3.0/configure --prefix=/mingw --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++,ada,java --disable-win32-registry --disable-sjlj-exceptions --enable-libstdcxx-debug --enable-version-specific-runtime-libs--with-gmp=/mingw/src/gcc/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --enable-libgcj --enable-concept-checks --enable-sharedThread model: win32gcc version 4.3.0 (GCC)<*** cc1 invocation snipped***>COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=i386' as -o D:\DOCUME~1\John\LOCALS~1\Temp/cc2779xd.oD:\DOCUME~1\John\LOCALS~1\Temp/ccqhufMa.sgcc.exe: CreateProcess: No such file or directoryFinally, straight from the horse's mouth:http://www.nabble.com/Re%3A-Necessary-environment-path-settings--p16243810.html.Cheers,John E. |
From: Earnie B. <ea...@us...> - 2008-04-05 11:10:16
|
Quoting "Aaron W. LaFramboise" <aar...@aa...>: > John E. / TDM wrote: > >> Basically, this bug only manifests >> itself when the MinGW/GCC bin directory is *not* present in PATH -- e.g. >> GCC is run with a fully-qualified command line, like >> "C:\path\to\mingw\bin\gcc.exe -o myprogram mysources". It is in fact >> highly useful to be able to run GCC on Windows without any additions to >> PATH, particularly when working with multiple versions of it or when >> running it from and IDE. > > OK this makes a lot more sense to me now. Thanks for the explanation. > Obviously I was never aware of this feature. > > I will make this change in the next build. > > So we're stuck with --build=mingw32 for backwards compatibility reasons. > This is a little unfortunate, and in a way, almost a GCC bug, as > mingw32 is canonicalized to i386-pc-mingw anyway. I would have > preferred using the latter because then autodetection works correctly, > and I feel the fewer unnecessary command line options we have, the better. > As has already been stated in this list configure switches for GCC and binutils and others that produce a target directory must include --host=mingw32 --target=mingw32. That is the reason --build=mingw32. The canonicalization should be i386-pc-mingw32 instead of i386-pc-mingw. For x86_64 it should be --host=mingw64, etc. > If I recall correctly, GCC and binutils treat all of 386, 486, 586, and > 686 identically. In that case, this is a bug that would be fixed in the > long run (not short run) by causing GCC to search all identical CPU > types. The benefit is that people doing native builds on their own are > likely to get something compatible with distributed binaries as far as > this feature is concern, 'compatibility by default.' > Correct, which is why the triplet is just plain stupid for mingw32; it makes no logical sense. We end up with i686-pc-mingw32 when it should really be i386-pc-mingw32 just because the build is on i686 but the target is really i386. I remember being so confused when I first came to Cygwin. > If there are no objections, I'll put submitting a patch to FSF GCC for > that on my 'when I seriously have nothing better to do' list. We would > avoid compatibility problems in the short-term by a local patch to check > mingw32 also. > Keith and I have been in contact with Ben Elliston and one of us will provide patches for MinGW to config.guess and config.sub. Earnie |
From: Aaron W. L. <aar...@aa...> - 2008-04-05 20:50:35
|
Earnie Boyd wrote: > Correct, which is why the triplet is just plain stupid for mingw32; it > makes no logical sense. We end up with i686-pc-mingw32 when it should > really be i386-pc-mingw32 just because the build is on i686 but the > target is really i386. I remember being so confused when I first came > to Cygwin. GCC regards i386 as the same as i686; this is not true of all programs. See below. > Keith and I have been in contact with Ben Elliston and one of us will > provide patches for MinGW to config.guess and config.sub. Are these patches to canonicalize i?86 to i386? If so, I am opposed to this. We must be consistent with other targets! If you are going to do this, it should be for all i?86 targets, not just us. The more inconsistencies the -mingw targets pick up versus more popular GCC targets, the more difficult things will be for us down the road. If other targets do not want this sort of canonicalization, then I think it will be a bad idea for us in the long run. Remember that all of GNU autoconfigury use config.sub, and if we make this change here, all sorts of packages that use autoconf may somehow become dependent, creating problems for us later if other targets decide that i686 means something different from i386. As a specific example, GMP uses the target triple to decide on the capabilities of the host machine. I'm not sure that this is a good idea, but what I'm saying is that making this change here has far-reaching consequences beyond the toolchain itself. |
From: Aaron W. L. <aar...@aa...> - 2008-04-05 06:30:56
|
John E. / TDM wrote: > Basically, this bug only manifests > itself when the MinGW/GCC bin directory is *not* present in PATH -- e.g. > GCC is run with a fully-qualified command line, like > "C:\path\to\mingw\bin\gcc.exe -o myprogram mysources". It is in fact > highly useful to be able to run GCC on Windows without any additions to > PATH, particularly when working with multiple versions of it or when > running it from and IDE. OK this makes a lot more sense to me now. Thanks for the explanation. Obviously I was never aware of this feature. I will make this change in the next build. So we're stuck with --build=mingw32 for backwards compatibility reasons. This is a little unfortunate, and in a way, almost a GCC bug, as mingw32 is canonicalized to i386-pc-mingw anyway. I would have preferred using the latter because then autodetection works correctly, and I feel the fewer unnecessary command line options we have, the better. If I recall correctly, GCC and binutils treat all of 386, 486, 586, and 686 identically. In that case, this is a bug that would be fixed in the long run (not short run) by causing GCC to search all identical CPU types. The benefit is that people doing native builds on their own are likely to get something compatible with distributed binaries as far as this feature is concern, 'compatibility by default.' If there are no objections, I'll put submitting a patch to FSF GCC for that on my 'when I seriously have nothing better to do' list. We would avoid compatibility problems in the short-term by a local patch to check mingw32 also. |
From: John E. / T. <td...@td...> - 2008-04-12 03:34:19
Attachments:
inlineclassfunc.cpp
|
Here's another bug report on the GCC 4.3.0 alpha. *Summary:* Inline constructor or destructor definitions outside the class definition of a dllimport class are not recognized. *Testcase:* Attached. Compiles successfully on MinGW/GCC 3.4.5 and 4.2 releases; fails on the 4.3.0 alpha (as well as my own various 4.3.0 builds). *Description:* In the ISO C++ Standard, section 9.3 - Member functions [class.mfct], point 3 says "An inline member function (whether static or nonstatic) may also be defined outside of its class definition provided either its declaration in the class definition or its definition outside of the class definition declares the function as inline." This appears to be broken in GCC 4.3.0 for the specific case of constructors and destructors of a class defined with __declspec(dllimport), where the definition outside the class is declared as inline but the declaration inside the class is not. It appears that a standard import reference is generated when the declaration is seen inside the class, but the inline definition outside the class afterward doesn't override that reference as it should. This leads to undefined references to import functions at link time. Unless someone says otherwise, I will also soon file this in GCC bugzilla. In case anyone is interested, I discovered the bug while attempting a build of the Code::Blocks IDE from sources. I judge its severity to be mild, as it is easily avoided by adding "inline" to the declaration inside the class. -John E. |
From: Aaron W. L. <aar...@aa...> - 2008-04-12 05:12:20
|
John E. / TDM wrote: > *Testcase:* > Attached. Compiles successfully on MinGW/GCC 3.4.5 and 4.2 releases; > fails on the 4.3.0 alpha (as well as my own various 4.3.0 builds). This is definitely a change from previous versions, but... This construct (and your testcase) is rejected by MSVC 8.0: john.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall foo::~foo(void)" (__imp_??1foo@@QAE@XZ) referenced in function _main john.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall foo::foo(void)" (__imp_??0foo@@QAE@XZ) referenced in function _main So I am not sure if this is a bug, or if the compiler is correct in rejecting this. In general, when it comes to declspec, GCC's behavior should match MSVC. > but the inline > definition outside the class afterward doesn't override that reference > as it should. I am not sure if what you describe is the intended behavior. I can't find anything in the MSVC documentation that addresses the intersection of 'inline' and 'dllimport,' but its my best guess that 'dllimport' should cause 'inline' to be ignored. This seems reasonable, occurring in the case where we're importing something that is defined as 'inline,' which could happen if we're using the API_EXPORT-style macros: class API_EXPORT my_class {myclass() {}}; I can't find any documented or implemented exception to the rule that dllimport will always cause an import from an external DLL. There's some anecdotal evidence of this on the web, such as the 'Answer' post in <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3039271&SiteID=1>. Based on this, I think the previous GCC versions were incorrect in allowing this, and GCC 4.3.0 is correct in rejecting this, and this is not a bug. One other issue. If we change the constructor to be implicitly inline, the testcase still fails on MSVC, but succeeds on 4.3.0, as well as earlier versions of GCC. I think this is a bug; it shouldn't matter if we're using implicit or explicit inline, it should be rejected in either case. What do you think? |
From: John E. / T. <td...@td...> - 2008-04-12 16:39:27
|
Aaron W. LaFramboise wrote: > John E. / TDM wrote: > >> *Testcase:* >> Attached. Compiles successfully on MinGW/GCC 3.4.5 and 4.2 releases; >> fails on the 4.3.0 alpha (as well as my own various 4.3.0 builds). >> > This is definitely a change from previous versions, but... > > This construct (and your testcase) is rejected by MSVC 8.0: > > john.obj : error LNK2019: unresolved external symbol > "__declspec(dllimport) public: __thiscall foo::~foo(void)" > (__imp_??1foo@@QAE@XZ) referenced in function _main > john.obj : error LNK2019: unresolved external symbol > "__declspec(dllimport) public: __thiscall foo::foo(void)" > (__imp_??0foo@@QAE@XZ) referenced in function _main > > So I am not sure if this is a bug, or if the compiler is correct in > rejecting this. In general, when it comes to declspec, GCC's behavior > should match MSVC. > What do you think? > I think it's an unfortunate loss of functionality. Why shouldn't one be able to inline some functions in a class and have the rest be imported from a DLL? It seems hardly different than inlining some functions in a class and having the rest be imported from another object file. Matching MSVC's behavior is probably a good idea for cases like this where there is no non-Windows GNU precedent. Nevertheless I fear for MinGW-based software already out there (such as Code::Blocks) which currently relies on 3.4.5's behavior. So if this were a democracy, I would vote to keep the old behavior, i.e. patch 4.3 and trunk so that inline constructors and destructors override import references. (Unless someone comes up with a good reason why doing so leads to broken behavior.) -John E. |
From: John E. / T. <td...@td...> - 2008-04-12 18:05:01
|
John E. / TDM wrote: > Aaron W. LaFramboise wrote: > >> John E. / TDM wrote: >> >> >>> *Testcase:* >>> Attached. Compiles successfully on MinGW/GCC 3.4.5 and 4.2 releases; >>> fails on the 4.3.0 alpha (as well as my own various 4.3.0 builds). >>> >>> >> This is definitely a change from previous versions, but... >> >> This construct (and your testcase) is rejected by MSVC 8.0: >> >> john.obj : error LNK2019: unresolved external symbol >> "__declspec(dllimport) public: __thiscall foo::~foo(void)" >> (__imp_??1foo@@QAE@XZ) referenced in function _main >> john.obj : error LNK2019: unresolved external symbol >> "__declspec(dllimport) public: __thiscall foo::foo(void)" >> (__imp_??0foo@@QAE@XZ) referenced in function _main >> >> So I am not sure if this is a bug, or if the compiler is correct in >> rejecting this. In general, when it comes to declspec, GCC's behavior >> should match MSVC. >> What do you think? >> > I think it's an unfortunate loss of functionality. Why shouldn't one be > able to inline some functions in a class and have the rest be imported > from a DLL? It seems hardly different than inlining some functions in a > class and having the rest be imported from another object file. > > Matching MSVC's behavior is probably a good idea for cases like this > where there is no non-Windows GNU precedent. Nevertheless I fear for > MinGW-based software already out there (such as Code::Blocks) which > currently relies on 3.4.5's behavior. So if this were a democracy, I > would vote to keep the old behavior, i.e. patch 4.3 and trunk so that > inline constructors and destructors override import references. (Unless > someone comes up with a good reason why doing so leads to broken behavior.) > In doing more research into this issue, I ran across a GCC mailing list post by Danny Smith (<http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02419.html>) which seems to indicate that we do indeed want to allow inline redefinitions of dllimport member functions -- in particular, see gcc/testsuite/g++.dg/ext/dllimport9.C. The testcase doesn't test inline con/de-structors, but it does still fail in MSVC 8 (with __attribute__ ((dllimport)) changed to __declspec(dllimport), of course). -John E. |
From: Aaron W. L. <aar...@aa...> - 2008-04-12 19:45:38
|
John E. / TDM wrote: > I think it's an unfortunate loss of functionality. Why shouldn't one be > able to inline some functions in a class and have the rest be imported > from a DLL? It seems hardly different than inlining some functions in a > class and having the rest be imported from another object file. This is a reasonable feature to have, but I don't think dllimport inline should be the way to accomplish it. As best I understand, this is what MSVC's compiler does, and consequently most Windows programmers expect: dllimport: Always import from DLL inline: Maybe inline, if possible, if heuristic improvement (C++) Note according to the manual for all GCC versions, including 3.4, "Currently, the attribute [dllimport] is ignored for inlined functions." So even according to GCC's manual, this was not correct behavior. Ignoring 'inline' is only a performance problem. Ignoring 'dllimport' is a correctness problem, because it changes the ABI; we're not importing something from a DLL that we should, and the program might rely on this behavior, for eg, different DLLs may provide a different implementation. This is similar to the situation on some ELF models, where global symbols are preemptable by other shared libraries, and so optimizations (such as inlining) are inhibited to allow shared libraries to properly override global functions. In conclusion: -'inline dllimport' is a valid construct on MSVC -this construct actually comes up quite a lot in Windows code -the old GCC behavior changes the meaning of this valid construct, which is probably bad > Matching MSVC's behavior is probably a good idea for cases like this > where there is no non-Windows GNU precedent. Nevertheless I fear for > MinGW-based software already out there (such as Code::Blocks) which > currently relies on 3.4.5's behavior. I don't understand this though. Inlining can always fail. If the Code::Blocks link fails without this inlining, then something is wrong anyway. It's only luck that this worked in the first place. > So if this were a democracy, I > would vote to keep the old behavior, i.e. patch 4.3 and trunk so that > inline constructors and destructors override import references. Democracy is a failure to reach consensus. Let's find a solution that will make everybody happy. What exactly troubles you about this change? The fact Code::Blocks no longer compiles? It's my feeling that either way, Code::Blocks has a bug as inline failure shouldn't stop the link, so a change will be needed either way. If it's the missed optimization, what if we added a GNU-specific way to do this, such as always_inline or something? We could also do something like add a flag that changes the compiler to be MS-compatible in this regard, but I think this is a very dangerous path to go down, and if there's any way we can avoid getting ourselves into this sort of situation, we should seek it. |
From: John E. / T. <td...@td...> - 2008-04-12 20:49:07
|
Aaron W. LaFramboise wrote: > Note according to the manual for all GCC versions, including 3.4, > "Currently, the attribute [dllimport] is ignored for inlined functions." > So even according to GCC's manual, this was not correct behavior. > I don't think one can imply a view of incorrectness from that statement in the manual. See gcc/testsuite/g++.dg/ext/dllimport9.C, gcc/config/i386/winnt-cxx.c:113-121 and gcc/tree.c:3990-3991 for further proof that the old behavior is intended. >> Matching MSVC's behavior is probably a good idea for cases like this >> where there is no non-Windows GNU precedent. Nevertheless I fear for >> MinGW-based software already out there (such as Code::Blocks) which >> currently relies on 3.4.5's behavior. >> > > I don't understand this though. Inlining can always fail. If the > Code::Blocks link fails without this inlining, then something is wrong > anyway. It's only luck that this worked in the first place. > No, Code::Blocks is just doing the exact same thing as the testcase I provided. In the testcase, definitions for the constructor and destructor are obviously provided, but GCC fails to recognize them as such and therefore fails to delete the dllimport references. The exact same thing happens when you remove the inline keyword from the definition -- but in this case, GCC warns you that it will ignore the previous dllimport and then proceeds to use it rather than ignore it! >> So if this were a democracy, I >> would vote to keep the old behavior, i.e. patch 4.3 and trunk so that >> inline constructors and destructors override import references. >> > > Democracy is a failure to reach consensus. Let's find a solution that > will make everybody happy. > > What exactly troubles you about this change? The fact Code::Blocks no > longer compiles? It's my feeling that either way, Code::Blocks has a > bug as inline failure shouldn't stop the link, so a change will be > needed either way. > Code::Blocks doesn't care whether the functions are inlined or not; it just wants certain member functions (in this case, the constructor) to be directly defined in the compilation unit rather than imported from the DLL. (I imagine it's for optimization purposes.) The thing that troubles me about this change is A) that the old behavior was intended, and B) the behavior has only changed for con/de-structors. (In other words, the old behavior holds true for other member functions.) -John E. |