From: Cesar S. <ces...@gm...> - 2012-06-07 18:19:53
|
Dear MinGW community, I am pleased to announce the mingw.org release of GCC 4.7.0. This MinGW port generates 32-bit code for Windows, and should run on any 32- or 64-bit Windows operating system. No local patches were used. Binary incompatibility notice! ------------------------------ The C and C++ ABI have changed, which means in general you can't link together binaries compiled with this version of the compiler and any previous version. In particular: * The option -mms-bitfields is enabled by default, which means the bitfield layout follows the convention of the Microsoft compiler. * C++ class-member functions now follow the __thiscall calling convention. Known Issue: ------------ PATH must be set to the location of the gcc.exe binary. Specifying the full path on the command line doesn't work currently. To install: ----------- Run the latest graphical mingw-get-inst installer, checking the option to download the latest repository catalogs. The GCC core package includes only the C language. At any time, if you want to install another language, do: mingw-get install <language> where <language> is one of: ada,c++,fortran,objc. To upgrade: ----------- mingw-get update mingw-get upgrade gcc mingw-get upgrade ada (optional) mingw-get upgrade c++ (optional) mingw-get upgrade fortran (optional) mingw-get upgrade objc (optional) Or, simply type "mingw-get upgrade" to upgrade everything to their latest versions. See the complete file list and the full release notes at: http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.7.0-1/ See also: http://gcc.gnu.org/gcc-4.7/changes.html Regards, Cesar |
From: niXman <i.n...@gm...> - 2012-06-07 18:30:15
|
2012/6/7 Cesar Strauss: > I am pleased to announce the mingw.org release of GCC 4.7.0. Thanks, of course. But approximately the next week will be released version 4.7.1 =) -- Regards, niXman ___________________________________________________ Dual-target(i686/x86_64) MinGW compilers for i686/x86_64 hosts: http://sourceforge.net/projects/mingwbuilds/ |
From: Eli Z. <el...@gn...> - 2012-06-07 18:36:25
|
> From: Cesar Strauss <ces...@gm...> > Date: Thu, 07 Jun 2012 15:19:28 -0300 > > Dear MinGW community, > > I am pleased to announce the mingw.org release of GCC 4.7.0. Thanks. > Binary incompatibility notice! > ------------------------------ > > The C and C++ ABI have changed, which means in general you can't link > together binaries compiled with this version of the compiler and any > previous version. Does this mean that all the libraries, shared and static alike, in all the precompiled packages out there are unusable with this compiler, and must be rebuilt? > * The option -mms-bitfields is enabled by default, which means the > bitfield layout follows the convention of the Microsoft compiler. > > * C++ class-member functions now follow the __thiscall calling > convention. Are these the only causes of the ABI incompatibility? Also, are there any discussions one can read to understand the reasons for enabling -mms-bitfields by default? If not, perhaps you could explain those reasons? TIA. |
From: Earnie B. <ea...@us...> - 2012-06-07 19:24:17
|
On Thu, Jun 7, 2012 at 2:36 PM, Eli Zaretskii <el...@gn...> wrote: >> From: Cesar Strauss <ces...@gm...> >> Date: Thu, 07 Jun 2012 15:19:28 -0300 >> >> Dear MinGW community, >> >> I am pleased to announce the mingw.org release of GCC 4.7.0. > > Thanks. > >> Binary incompatibility notice! >> ------------------------------ >> >> The C and C++ ABI have changed, which means in general you can't link >> together binaries compiled with this version of the compiler and any >> previous version. > > Does this mean that all the libraries, shared and static alike, in all > the precompiled packages out there are unusable with this compiler, > and must be rebuilt? > Yes, exactly. >> * The option -mms-bitfields is enabled by default, which means the >> bitfield layout follows the convention of the Microsoft compiler. >> >> * C++ class-member functions now follow the __thiscall calling >> convention. > > Are these the only causes of the ABI incompatibility? > I don't know. The -mms-bitfields flag is enough to cause the incompatibility for both shared and static libraries. Therefore since GCC libraries that are added by default would have been built with -mms-bitfields the question I have are there suitable GCC libraries that exclude -mms-bitfields? However, my opinion is that this should never have been an option and just the way it works on Windows. Should we wait for new mingw runtime and w32api libraries before upgrading? > Also, are there any discussions one can read to understand the reasons > for enabling -mms-bitfields by default? If not, perhaps you could > explain those reasons? TIA. You can find plenty in google to answer that. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2012-06-08 07:35:06
|
> Date: Thu, 7 Jun 2012 15:24:11 -0400 > From: Earnie Boyd <ea...@us...> > > On Thu, Jun 7, 2012 at 2:36 PM, Eli Zaretskii <el...@gn...> wrote: > >> From: Cesar Strauss <ces...@gm...> > >> Date: Thu, 07 Jun 2012 15:19:28 -0300 > >> > >> Dear MinGW community, > >> > >> I am pleased to announce the mingw.org release of GCC 4.7.0. > > > > Thanks. > > > >> Binary incompatibility notice! > >> ------------------------------ > >> > >> The C and C++ ABI have changed, which means in general you can't link > >> together binaries compiled with this version of the compiler and any > >> previous version. > > > > Does this mean that all the libraries, shared and static alike, in all > > the precompiled packages out there are unusable with this compiler, > > and must be rebuilt? > > > > Yes, exactly. That's terrible. I really wonder what grave problems justified that. > >> * The option -mms-bitfields is enabled by default, which means the > >> bitfield layout follows the convention of the Microsoft compiler. > >> > >> * C++ class-member functions now follow the __thiscall calling > >> convention. > > > > Are these the only causes of the ABI incompatibility? > > > > I don't know. Well, I hope somebody does, and will speak up. Otherwise, this means that it will be impossible even in principle to distribute a library that can be used both with GCC >= 4.7.0 and GCC < 4.7.0. I cannot imagine what could possibly justify such a schism. > Should we wait for new mingw runtime and w32api libraries before upgrading? Is there any choice? You yourself just said that all the existing static libraries are ABI incompatible. That includes, e.g., libmingwex.a and other MinGW extension libraries distributed with the runtime. I hope the import libraries are safe, at least. > > Also, are there any discussions one can read to understand the reasons > > for enabling -mms-bitfields by default? If not, perhaps you could > > explain those reasons? TIA. > > You can find plenty in google to answer that. Please humor me with a pointer or two, if you can. I'm not asking about what "-mms-bitfields" does; I think I know that. I'm asking why it was decided to turn it on by default. I tried to google, but couldn't find anything recent, just old discussions about the effects of this option on the generated code (which btw always sound to me as purely theoretical, since the chances one bumps into the code that really triggers the differences are slim at best; maybe I'm missing something). TIA |
From: xunxun <xun...@gm...> - 2012-06-08 07:47:03
|
于 2012/6/8 15:34, Eli Zaretskii 写道: >> Date: Thu, 7 Jun 2012 15:24:11 -0400 >> From: Earnie Boyd <ea...@us...> >> >> On Thu, Jun 7, 2012 at 2:36 PM, Eli Zaretskii <el...@gn...> wrote: >>>> From: Cesar Strauss <ces...@gm...> >>>> Date: Thu, 07 Jun 2012 15:19:28 -0300 >>>> >>>> Dear MinGW community, >>>> >>>> I am pleased to announce the mingw.org release of GCC 4.7.0. >>> Thanks. >>> >>>> Binary incompatibility notice! >>>> ------------------------------ >>>> >>>> The C and C++ ABI have changed, which means in general you can't link >>>> together binaries compiled with this version of the compiler and any >>>> previous version. >>> Does this mean that all the libraries, shared and static alike, in all >>> the precompiled packages out there are unusable with this compiler, >>> and must be rebuilt? >>> >> Yes, exactly. > That's terrible. I really wonder what grave problems justified that. > >>>> * The option -mms-bitfields is enabled by default, which means the >>>> bitfield layout follows the convention of the Microsoft compiler. >>>> >>>> * C++ class-member functions now follow the __thiscall calling >>>> convention. >>> Are these the only causes of the ABI incompatibility? >>> >> I don't know. > Well, I hope somebody does, and will speak up. Otherwise, this means > that it will be impossible even in principle to distribute a library > that can be used both with GCC >= 4.7.0 and GCC < 4.7.0. I cannot > imagine what could possibly justify such a schism. > >> Should we wait for new mingw runtime and w32api libraries before upgrading? > Is there any choice? You yourself just said that all the existing > static libraries are ABI incompatible. That includes, e.g., > libmingwex.a and other MinGW extension libraries distributed with the > runtime. I hope the import libraries are safe, at least. > >>> Also, are there any discussions one can read to understand the reasons >>> for enabling -mms-bitfields by default? If not, perhaps you could >>> explain those reasons? TIA. >> You can find plenty in google to answer that. > Please humor me with a pointer or two, if you can. I'm not asking > about what "-mms-bitfields" does; I think I know that. I'm asking why > it was decided to turn it on by default. It's said that this is to bring into correspondence with VC, maybe Kai will know the details. Forward to Kai. > I tried to google, but > couldn't find anything recent, just old discussions about the effects > of this option on the generated code (which btw always sound to me as > purely theoretical, since the chances one bumps into the code that > really triggers the differences are slim at best; maybe I'm missing > something). > > TIA > > -- Best Regards, xunxun |
From: Fredric J. <fre...@gm...> - 2012-06-08 10:07:09
|
On Fri, Jun 8, 2012 at 9:34 AM, Eli Zaretskii <el...@gn...> wrote: >> Date: Thu, 7 Jun 2012 15:24:11 -0400 >> From: Earnie Boyd <ea...@us...> >> >> On Thu, Jun 7, 2012 at 2:36 PM, Eli Zaretskii <el...@gn...> wrote: >> >> From: Cesar Strauss <ces...@gm...> >> >> Date: Thu, 07 Jun 2012 15:19:28 -0300 >> >> >> >> Dear MinGW community, >> >> >> >> I am pleased to announce the mingw.org release of GCC 4.7.0. >> > >> > Thanks. >> > >> >> Binary incompatibility notice! >> >> ------------------------------ >> >> >> >> The C and C++ ABI have changed, which means in general you can't link >> >> together binaries compiled with this version of the compiler and any >> >> previous version. >> > >> > Does this mean that all the libraries, shared and static alike, in all >> > the precompiled packages out there are unusable with this compiler, >> > and must be rebuilt? >> > >> >> Yes, exactly. > > That's terrible. I really wonder what grave problems justified that. > >> >> * The option -mms-bitfields is enabled by default, which means the >> >> bitfield layout follows the convention of the Microsoft compiler. >> >> >> >> * C++ class-member functions now follow the __thiscall calling >> >> convention. >> > >> > Are these the only causes of the ABI incompatibility? >> > >> >> I don't know. > > Well, I hope somebody does, and will speak up. Otherwise, this means > that it will be impossible even in principle to distribute a library > that can be used both with GCC >= 4.7.0 and GCC < 4.7.0. I cannot > imagine what could possibly justify such a schism. > >> Should we wait for new mingw runtime and w32api libraries before upgrading? > > Is there any choice? You yourself just said that all the existing > static libraries are ABI incompatible. That includes, e.g., > libmingwex.a and other MinGW extension libraries distributed with the > runtime. I hope the import libraries are safe, at least. > >> > Also, are there any discussions one can read to understand the reasons >> > for enabling -mms-bitfields by default? If not, perhaps you could >> > explain those reasons? TIA. >> >> You can find plenty in google to answer that. > > Please humor me with a pointer or two, if you can. I'm not asking > about what "-mms-bitfields" does; I think I know that. I'm asking why > it was decided to turn it on by default. I tried to google, but > couldn't find anything recent, just old discussions about the effects > of this option on the generated code (which btw always sound to me as > purely theoretical, since the chances one bumps into the code that > really triggers the differences are slim at best; maybe I'm missing > something). > > TIA > A quick googling found this: http://old.nabble.com/-patch-i386-mingw-g%2B%2B.dg-gcc.dg-%3A-Set--mms-bitfields-as-default-for-native-windows-targets-td31378825.html It doesn't explain why it was changed but it says that there already was other changes to the ABI so this could as well go in at the same time. //Fredric |
From: Roumen P. <bug...@ro...> - 2012-06-08 21:06:16
|
Eli Zaretskii wrote: >> Date: Thu, 7 Jun 2012 15:24:11 -0400 >> From: Earnie Boyd<ea...@us...> >> >> On Thu, Jun 7, 2012 at 2:36 PM, Eli Zaretskii<el...@gn...> wrote: >>>> From: Cesar Strauss<ces...@gm...> >>>> Date: Thu, 07 Jun 2012 15:19:28 -0300 >>>> >>>> Dear MinGW community, >>>> >>>> I am pleased to announce the mingw.org release of GCC 4.7.0. [SNIP] >>> Also, are there any discussions one can read to understand the reasons >>> for enabling -mms-bitfields by default? If not, perhaps you could >>> explain those reasons? TIA. >> You can find plenty in google to answer that. > Please humor me with a pointer or two, if you can. I'm not asking > about what "-mms-bitfields" does; I think I know that. I'm asking why > it was decided to turn it on by default. I tried to google, but > couldn't find anything recent, just old discussions about the effects > of this option on the generated code (which btw always sound to me as > purely theoretical, since the chances one bumps into the code that > really triggers the differences are slim at best; maybe I'm missing > something). May be you miss that mingw.org build by default products with this flags set. [SNIP] Roumen |
From: Earnie B. <ea...@us...> - 2012-06-14 22:20:26
|
On Fri, Jun 8, 2012 at 3:34 AM, Eli Zaretskii wrote: >> >> * The option -mms-bitfields is enabled by default, which means the >> >> bitfield layout follows the convention of the Microsoft compiler. >> >> >> >> * C++ class-member functions now follow the __thiscall calling >> >> convention. >> > >> > Are these the only causes of the ABI incompatibility? >> > >> >> I don't know. > > Well, I hope somebody does, and will speak up. Otherwise, this means > that it will be impossible even in principle to distribute a library > that can be used both with GCC >= 4.7.0 and GCC < 4.7.0. I cannot > imagine what could possibly justify such a schism. > >> Should we wait for new mingw runtime and w32api libraries before upgrading? > > Is there any choice? You yourself just said that all the existing > static libraries are ABI incompatible. That includes, e.g., > libmingwex.a and other MinGW extension libraries distributed with the > runtime. I hope the import libraries are safe, at least. FYI, -mms-bitfields are used for all distributed libraries per a related thread on mingw-dvlpr. Search that list archives for the most recent posts. The change to make it a default should not be affective for libraries distributed by mingw.org. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2012-06-08 10:58:02
|
> Date: Fri, 8 Jun 2012 12:06:59 +0200 > From: Fredric Johansson <fre...@gm...> > > A quick googling found this: > http://old.nabble.com/-patch-i386-mingw-g%2B%2B.dg-gcc.dg-%3A-Set--mms-bitfields-as-default-for-native-windows-targets-td31378825.html > It doesn't explain why it was changed but it says that there already > was other changes to the ABI so this could as well go in at the same > time. Thanks. I found that, of course, but as you say, it doesn't explain at all why this was done. And for those "other ABI changes" I couldn't even find a description. |
From: Eli Z. <el...@gn...> - 2012-06-09 06:45:11
|
> Date: Sat, 09 Jun 2012 00:06:00 +0300 > From: Roumen Petrov <bug...@ro...> > > May be you miss that mingw.org build by default products with this flags > set. Thanks. No, I didn't miss that. The problem is, mingw.org is not the only source of precompiled packages. Besides, if this is so, why did Earnie ask whether we need a new runtime release to go with this GCC version? Perhaps not every product is built with this flag set? |
From: Eli Z. <el...@gn...> - 2012-06-15 07:41:31
|
> Date: Thu, 14 Jun 2012 18:20:19 -0400 > From: Earnie Boyd <ea...@us...> > > FYI, -mms-bitfields are used for all distributed libraries per a > related thread on mingw-dvlpr. Search that list archives for the most > recent posts. Thanks. For those who read this, the thread on mingw-dvlpr indicates that the MinGW libraries are compiled with -mms-bitfields switch "since at least 2009". So if you have a mingw-rt from 2009 or later, you should be set. |
From: nikola b. <ch...@ya...> - 2012-06-08 09:45:25
|
Hi, i am pleased to update to this version, but when i try to compile CGAL, i get this message: gcc: error: and\: No such file or directory gcc: error: Settings/nbozovic/Desktop/Dzo/Dragan\: No such file or directory gcc: error: Vidovic/voda\: No such file or directory gcc: error: FULL/voda/CGAL-4.0/include: No such file or directory gcc: error: and\: No such file or directory gcc: error: Settings/nbozovic/Desktop/Dzo/Dragan\: No such file or directory gcc: error: Vidovic/voda\: No such file or directory gcc: error: FULL/voda/boost_1_49_0: No such file or directory c:\MinGW\bin\windres.exe: preprocessing failed. make[2]: *** [src/CGAL/CMakeFiles/CGAL.dir/CGAL_verinfo.rc.obj] Error 1 make[1]: *** [src/CGAL/CMakeFiles/CGAL.dir/all] Error 2 make: *** [all] Error 2 /* Dear MinGW community, I am pleased to announce the mingw.orgrelease of GCC 4.7.0. This MinGW port generates 32-bit code for Windows, and should run on any 32- or 64-bit Windows operating system. */ |
From: Fredric J. <fre...@gm...> - 2012-06-08 10:13:08
|
On Fri, Jun 8, 2012 at 11:45 AM, nikola bozovic <ch...@ya...> wrote: > > Hi, i am pleased to update to this version, > but when i try to compile CGAL, i get this message: > > gcc: error: and\: No such file or directory > gcc: error: Settings/nbozovic/Desktop/Dzo/Dragan\: No such file or directory > gcc: error: Vidovic/voda\: No such file or directory > gcc: error: FULL/voda/CGAL-4.0/include: No such file or directory > gcc: error: and\: No such file or directory > gcc: error: Settings/nbozovic/Desktop/Dzo/Dragan\: No such file or directory > gcc: error: Vidovic/voda\: No such file or directory > gcc: error: FULL/voda/boost_1_49_0: No such file or directory > c:\MinGW\bin\windres.exe: preprocessing failed. > make[2]: *** [src/CGAL/CMakeFiles/CGAL.dir/CGAL_verinfo.rc.obj] Error 1 > make[1]: *** [src/CGAL/CMakeFiles/CGAL.dir/all] Error 2 > make: *** [all] Error 2 > This has nothing to do with the new gcc. You are building in a dir which has spaces in its path which is unsupported and won't work. Move to a dir without spaces and it should compile fine. //Fredric |
From: Cesar S. <ces...@gm...> - 2012-07-12 01:51:39
|
On 6/7/2012 3:19 PM, Cesar Strauss wrote: > Binary incompatibility notice! > ------------------------------ > > The C and C++ ABI have changed, which means in general you can't link > together binaries compiled with this version of the compiler and any > previous version. In particular: > > * The option -mms-bitfields is enabled by default, which means the > bitfield layout follows the convention of the Microsoft compiler. > > * C++ class-member functions now follow the __thiscall calling > convention. For the record, there was one more ABI change for C and C++ in GCC 4.7.0: * The compiler now assumes that the caller pops the stack for the implicit arguments pointing to an aggregate return value. This affects functions returning structs by value, or even the complex math type. Regards, Cesar |
From: Eli Z. <el...@gn...> - 2012-07-12 05:21:50
|
> From: Cesar Strauss <ces...@gm...> > Date: Wed, 11 Jul 2012 22:51:16 -0300 > > For the record, there was one more ABI change for C and C++ in GCC 4.7.0: > > * The compiler now assumes that the caller pops the stack for the > implicit arguments pointing to an aggregate return value. This affects > functions returning structs by value, or even the complex math type. Thanks. But wasn't this always so in C? the caller always pops the stack, doesn't it? |
From: Cesar S. <ces...@gm...> - 2012-07-13 01:32:14
|
On 07/12/2012 02:21 AM, Eli Zaretskii wrote: >> From: Cesar Strauss <ces...@gm...> >> Date: Wed, 11 Jul 2012 22:51:16 -0300 >> >> For the record, there was one more ABI change for C and C++ in GCC 4.7.0: >> >> * The compiler now assumes that the caller pops the stack for the >> implicit arguments pointing to an aggregate return value. This affects >> functions returning structs by value, or even the complex math type. > > Thanks. But wasn't this always so in C? the caller always pops the > stack, doesn't it? For normal arguments, yes. Not so for the hidden pointer argument used when returning large values in memory (as opposed as in registers). GCC on MinGW now follows the Microsoft convention. See also: http://www.angelcode.com/dev/callconv/callconv.html. Cesar |