Re: [Mingw-users] MinGW GCC 4.7.0 released

[Fredric J. <fre...@gm...>]

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