MinGW GCC 4.7.0 released

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Ross Ridge
Kai Tietz writes:
>It isn't a big mistake to fix things in the proper way vendor defines
>its ABI.  It was always a flaw to have it different implemented in
>gcc.

At best all you can say is that the flaw remains, that you still have
differently implemented C++ ABI that still needs to be fixed in the
proper way the vendor, Microsoft, defines its C++ ABI.

The reality is though worse than that, all you have actually done
is create your own unique ABI that's only compatible with itself.
The next patch you apply to "fix" some other apsect of Microsoft's C++
ABI that you happen to find convienent will define yet another unique
ABI and require C++ users to recompile everything again.

Do you really think this plan is a good one?  Who do you think can
actually benefit from this half-assed incremental approach?

>I wouldn't be to sure that g++ remains completely incompatible to
>msc's variant.  In fact there is right now just an issue about
>vtable/vbtable, which makes it impossible to use C++ compiled by msc
>within g++ projects (and otherway round, too).  There is still a
>name-mangling issue, but this issue can be solved at least for DLL
>version via symbol-name-alias exporting feature.

It's much, much more complicated than that.  Look at the GCC C++ ABI:

        http://sourcery.mentor.com/public/cxx-abi/abi.html

*Everything* on that list needs to be changed to the way Microsoft
defines is ABI.  I'd post a link to Microsoft's C++ ABI documents for
you to compare it to, but they don't exist.  Not only do you need to
make all these changes you need to a fair bit of painstaking reverse
engineering just to figure out what the changes are.

Just changing exceptions so they work like Microsoft C++'s compiler is
a major undertaking.  Oh, but then you don't actually need to even try
to implement Microsoft's 32-bit SEH mechanism, you can just implement
their compeletly different system for 64-bit stack unwinding.

And no you can not ignore the name-mangling issue with some DLL symbol
alias hack.  You cannot keep using GCC's name mangling, having a different
and incompatible name mangling system is an import part of the design of
any C++ ABI.  It ensures that code between compiled with two incompatible
ABIs isn't accidentally linked togoether.

The fact is that if you want your non-trivial C++ code to be compiled in
way that makes it compatible with C++ code compiled with a Microsoft C++
compiler you can not use GCC 4.7.0.  Nor is it likely to ever work with
any future version of GCC.

                                        Ross Ridge


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Kai Tietz-2
In reply to this post by Eli Zaretskii
2012/6/11 Eli Zaretskii <[hidden email]>:

>> Date: Mon, 11 Jun 2012 18:44:57 +0200
>> From: Kai Tietz <[hidden email]>
>>
>>   In general we saw on mingw-w64's side that a lot of union/structure
>> definitions were affected by the wrong structure/union-layout.  Actual
>> I got pointed to this by the maintainer of open-suse's
>> mingw-repository.  The major difference between (ms_struct and
>> gcc_struct) is the kind of packing of consecutive same-sized types and
>> bitfield-elements with same type.
>
> Where can I find the description of the details of these differences?

I suggest to see gcc's testsuite for this (but well, it is more a
description), and for the ABI is google your friend.  AFAIR I found
some articles about it on codeguru and some other sources.
Nevertheless - as most of MS abi - not pretty well officially
described,

>> No, this aren't the only ABI changes.  Time by time the C++ ABI
>> changes in g++.  For 4.7 ABI changes were introduced in respect of
>> C++11 (some C11 features were added too, but as C doesn't have
>> name-mangling, there is no issue).
>
> What about C?  Is the -mms-bitfields issue the only ABI change for C
> programs?

Sure, C has only the the ms-bitfield change, which is essantial for some

> Thanks.

Regards,
Kai

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Kai Tietz-2
In reply to this post by Ross Ridge
2012/6/11 Ross Ridge <[hidden email]>:
> Kai Tietz writes:
>>It isn't a big mistake to fix things in the proper way vendor defines
>>its ABI.  It was always a flaw to have it different implemented in
>>gcc.
>
> At best all you can say is that the flaw remains, that you still have
> differently implemented C++ ABI that still needs to be fixed in the
> proper way the vendor, Microsoft, defines its C++ ABI.

Well, the mess gets more near to that what it should be.  It is still
not fully compatible to ms' ABI (especially for C++) in some aspects.
I mentioned here vtable-differences as example, as it is most like one
of the last none-backward-compatible change pending.
The vtable issue is mainly a sorting issue within vtable.  Of course
there is also the model of vbtables, which is somewhat near done for
IA64 AFAIU.  Another major change could be exception-mechanism by
using SEH.  Well, actual I have already a patch for supporting SEH
exception-handling for 64-bit and also one for 32-bit.  For the 32-bit
variant I get regular poked by the ReactOS people to provide it to
them, but as there is still the Borland-patent pending about it, there
won't be much chance to get the SEH-patch for 32-bit accepted upstream
before July 2014 (as then the patent will end AFAIK).

> The reality is though worse than that, all you have actually done
> is create your own unique ABI that's only compatible with itself.
> The next patch you apply to "fix" some other apsect of Microsoft's C++
> ABI that you happen to find convienent will define yet another unique
> ABI and require C++ users to recompile everything again.

We don't have any different situation as we had before.  Just the ABI
gets more near to that one it should be.  Nothing more, nothing less.

> Do you really think this plan is a good one?  Who do you think can
> actually benefit from this half-assed incremental approach?

IMHO the user can benefit by this.  The thiscall-convention for C++
has also some impact on runtime-speed of C++, as default-argument
"this" gets passed in register and not on stack.  I remember that I
found some time ago a paper discussing speed differences here, and
they were messurable.  Also it allows in some scenarios to import and
use msc compiled c++-code.

>>I wouldn't be to sure that g++ remains completely incompatible to
>>msc's variant.  In fact there is right now just an issue about
>>vtable/vbtable, which makes it impossible to use C++ compiled by msc
>>within g++ projects (and otherway round, too).  There is still a
>>name-mangling issue, but this issue can be solved at least for DLL
>>version via symbol-name-alias exporting feature.
>
> It's much, much more complicated than that.  Look at the GCC C++ ABI:
>
>        http://sourcery.mentor.com/public/cxx-abi/abi.html

I know this page too.  And I don't see what you want to tell me new here.

> Just changing exceptions so they work like Microsoft C++'s compiler is
> a major undertaking.  Oh, but then you don't actually need to even try
> to implement Microsoft's 32-bit SEH mechanism, you can just implement
> their compeletly different system for 64-bit stack unwinding.

See above.  Exception actual aren't the real blocker, beside of this
latent patent issue, which prevents that the exisiting patch for this
can get applied.

> And no you can not ignore the name-mangling issue with some DLL symbol
> alias hack.  You cannot keep using GCC's name mangling, having a different
> and incompatible name mangling system is an import part of the design of
> any C++ ABI.  It ensures that code between compiled with two incompatible
> ABIs isn't accidentally linked togoether.

Sure I can.  There are ways to resolve them, but as long as there are
such ABI clashes, the libmangle project won't improve on that.  We
actual know already pretty well how the name-mangling looks like and
it is just a matter of work to do translation between gcc's and the
ms' one.  No big point IMHO.

There is still a long road to achieve more compatiblity for c++ case,
but each step on that brings us near.  Ross, this attitude was in the
past exactly the reason why things got stuck and nothing moved
anymore.  No progress means death.

Regards,
Kai

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Ross Ridge
In reply to this post by Cesar Strauss
Kai Tietz writes:
>No, this aren't the only ABI changes.  Time by time the C++ ABI
>changes in g++.  For 4.7 ABI changes were introduced in respect of
>C++11 (some C11 features were added too, but as C doesn't have
>name-mangling, there is no issue).  It isn't uncommon that g++ version
>isn't backward-compatible.

There have been no ABI breaking changes made to the GCC C++ ABI since
GCC 3.4.0.  GCC 4.7.0 is backwards compatible with C++ code compiled
with GCC 3.4.0.  That is, except on MinGW targets where your changes
broke the ABI.

The additional features added in 4.7 that required making compatible
extensions to the C++ ABI did not justify your ABI breaking changes.

Kai Tietz, once again you're messing about with things you don't fully
understand.  If your idea of progress is all that's pushing the MinGW
ports of GCC forward than death is what it deserves.

                                        Ross Ridge


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

JonY-3
On 6/12/2012 01:53, Ross Ridge wrote:

> Kai Tietz writes:
>> No, this aren't the only ABI changes.  Time by time the C++ ABI
>> changes in g++.  For 4.7 ABI changes were introduced in respect of
>> C++11 (some C11 features were added too, but as C doesn't have
>> name-mangling, there is no issue).  It isn't uncommon that g++ version
>> isn't backward-compatible.
>
> There have been no ABI breaking changes made to the GCC C++ ABI since
> GCC 3.4.0.  GCC 4.7.0 is backwards compatible with C++ code compiled
> with GCC 3.4.0.  That is, except on MinGW targets where your changes
> broke the ABI.
>
Wow, I'd say you have been insanely lucky to have missed the GCC-3.x/4.x
ABI break. How did you miss that?

> The additional features added in 4.7 that required making compatible
> extensions to the C++ ABI did not justify your ABI breaking changes.
>
> Kai Tietz, once again you're messing about with things you don't fully
> understand.  If your idea of progress is all that's pushing the MinGW
> ports of GCC forward than death is what it deserves.
>

C++ ABI break all the time, there are no such things as a stable ABI
standards for C++. The best practice is to always use the same compiler
to build and run your C++ code.

Disagree all you like, but ABI breaking in C++ implementations is quite
common.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe

signature.asc (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

NightStrike
In reply to this post by Ross Ridge
On Mon, Jun 11, 2012 at 7:53 AM, Ross Ridge <[hidden email]> wrote:

> Kai Tietz writes:
>>No, this aren't the only ABI changes.  Time by time the C++ ABI
>>changes in g++.  For 4.7 ABI changes were introduced in respect of
>>C++11 (some C11 features were added too, but as C doesn't have
>>name-mangling, there is no issue).  It isn't uncommon that g++ version
>>isn't backward-compatible.
>
> There have been no ABI breaking changes made to the GCC C++ ABI since
> GCC 3.4.0.  GCC 4.7.0 is backwards compatible with C++ code compiled
> with GCC 3.4.0.  That is, except on MinGW targets where your changes
> broke the ABI.

Why do you think that?

> The additional features added in 4.7 that required making compatible
> extensions to the C++ ABI did not justify your ABI breaking changes.
>
> Kai Tietz, once again you're messing about with things you don't fully
> understand.  If your idea of progress is all that's pushing the MinGW
> ports of GCC forward than death is what it deserves.

If not for Kai, mingw.org would still be using a hacked 3.4.6.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Jared Maddox
In reply to this post by Cesar Strauss
> Date: Mon, 11 Jun 2012 19:33:18 +0200
> From: Kai Tietz <[hidden email]>
> Subject: Re: [Mingw-users] MinGW GCC 4.7.0 released
> To: MinGW Users List <[hidden email]>
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2012/6/11 Ross Ridge <[hidden email]>:
>> Kai Tietz writes:


>> The reality is though worse than that, all you have actually done
>> is create your own unique ABI that's only compatible with itself.
>> The next patch you apply to "fix" some other apsect of Microsoft's C++
>> ABI that you happen to find convienent will define yet another unique
>> ABI and require C++ users to recompile everything again.
>
> We don't have any different situation as we had before.  Just the ABI
> gets more near to that one it should be.  Nothing more, nothing less.
>

As both a C++ user, and someone slowly implementing a custom compiler,
I firmly disagree with this sentiment. C ABIs should be as near to
each other as is possible, the thiscall change is fine, as it's a
performance issue, but attempting to directly implement
cross-compatibility is something that I don't support. Historically
there was little to no cross-compatibility between the C++ compiler
families, because C is intended to be the C++ compatibility bridge. If
you're really so worried about interoperability then just implement
some glue logic to do conversions at run-time. It's already known that
MS C++ objects are based on MS COM, and that MS COM objects are
expressible in pure C (I've seen it demonstrated), so piping the data
through a properly enriched GNU IDL compiler would provide everything
needed (though GUIDs with a C-ish interface would certainly be nice as
a general-purpose addition, I mention this because I've never seen a
sign that GCC natively implements them).

Seriously, what are you going to do next, Managed C++? C++/CLI?
COMinterop (which belongs in Mono/Portable.Net, not in g++)? C++/CX?

Glue code (some compile-time, some run-time) is all that we
realistically need or want in C++ interoperability (especially since
the new standard has std::exception_ptr). I do not consider direct
interoperability on this issue to be important, OR desirable. C++ ABIs
should NOT be considered standard on most platforms (not even
Microsoft ones), C ABIs should be.


>> Do you really think this plan is a good one? ?Who do you think can
>> actually benefit from this half-assed incremental approach?
>
> IMHO the user can benefit by this.  The thiscall-convention for C++
> has also some impact on runtime-speed of C++, as default-argument
> "this" gets passed in register and not on stack.

Yes, that has a point & is fine.


> Also it allows in some scenarios to import and
> use msc compiled c++-code.
>

This isn't. Once again, a properly-enriched GNU IDL compiler + some
glue code is the superior option.


> There is still a long road to achieve more compatiblity for c++ case,
> but each step on that brings us near.  Ross, this attitude was in the
> past exactly the reason why things got stuck and nothing moved
> anymore.  No progress means death.
>

To put it bluntly, I don't think most of us are interested in most of
these changes in the first place. The C changes need to happen (C is
the compatibility language), the thiscall change makes sense, MSVC++
compatibility is raising everyone's hackles. Are you going to adopt
the byzantine size quirks of Microsoft's member-function pointers? We
don't want this.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Kai Tietz-2
2012/6/12 Jared Maddox <[hidden email]>:

>> Date: Mon, 11 Jun 2012 19:33:18 +0200
>> From: Kai Tietz <[hidden email]>
>> Subject: Re: [Mingw-users] MinGW GCC 4.7.0 released
>> To: MinGW Users List <[hidden email]>
>> Message-ID:
>>       <[hidden email]>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> 2012/6/11 Ross Ridge <[hidden email]>:
>>> Kai Tietz writes:
>
>
>>> The reality is though worse than that, all you have actually done
>>> is create your own unique ABI that's only compatible with itself.
>>> The next patch you apply to "fix" some other apsect of Microsoft's C++
>>> ABI that you happen to find convienent will define yet another unique
>>> ABI and require C++ users to recompile everything again.
>>
>> We don't have any different situation as we had before.  Just the ABI
>> gets more near to that one it should be.  Nothing more, nothing less.
>>
>
> As both a C++ user, and someone slowly implementing a custom compiler,
> I firmly disagree with this sentiment. C ABIs should be as near to
> each other as is possible, the thiscall change is fine, as it's a
> performance issue, but attempting to directly implement
> cross-compatibility is something that I don't support. Historically
> there was little to no cross-compatibility between the C++ compiler
> families, because C is intended to be the C++ compatibility bridge.

If I got misunderstood here, I want to correct this.  I didn't mean to
clone everything aspect of MS' C++ ABI into g++.  There is no big earn
by that, but some aspects are worth to be treated in an compatible
way.  Especially of interest is here the exception-model.  But of
course the underlying mechanism itself won't be 100% equivalent to
msc's variant.  Nevertheless it would be desirable to have a way to
catch in g++ code an exception thrown in msc's compiled code. Of
course the other way around would be desirable, too.

The vtable issue is of less interest IMHO, nevertheless the sorting
change would be interesting, as it would be possible then to do DCOM
with c++ classes instead of using C-wrapper layer.  It is more a
question of comfort.

> If
> you're really so worried about interoperability then just implement
> some glue logic to do conversions at run-time. It's already known that
> MS C++ objects are based on MS COM, and that MS COM objects are
> expressible in pure C (I've seen it demonstrated), so piping the data
> through a properly enriched GNU IDL compiler would provide everything
> needed (though GUIDs with a C-ish interface would certainly be nice as
> a general-purpose addition, I mention this because I've never seen a
> sign that GCC natively implements them).

We on mingw-w64's side have already a work-around for the GUID issue
of DCOM.  It might be possible to improve GUID support handling by
gcc-compiler directly (I posted for that once a patch), but well,
again it isn't really urgent IMHO, as there exists already a
work-a-round for it.

> Seriously, what are you going to do next, Managed C++? C++/CLI?
> COMinterop (which belongs in Mono/Portable.Net, not in g++)? C++/CX?

For sure not.  Nevertheless having the ability in binutils to link CLR
stuff would be for users an improvement, as they would have the chance
to link msc compiled object-code by ld.  But well, again this is for
sure nothing really important IMHO, but again a question of comfort.

> Glue code (some compile-time, some run-time) is all that we
> realistically need or want in C++ interoperability (especially since
> the new standard has std::exception_ptr). I do not consider direct
> interoperability on this issue to be important, OR desirable. C++ ABIs
> should NOT be considered standard on most platforms (not even
> Microsoft ones), C ABIs should be.

Agreed.  AFAIK even MS thinks about to change exception-mechanism for
C++.  So it might be just a question of time this ABI part changes
again.

  So I wanted just to point out that this "all or nothing" approach
requested by Ross leads nowhere.  First development needs time - as
there are not much people working for windows native targets on gcc -
and secondly not all ABI-compatibility is desired nor sensible.

>
>>> Do you really think this plan is a good one? ?Who do you think can
>>> actually benefit from this half-assed incremental approach?
>>
>> IMHO the user can benefit by this.  The thiscall-convention for C++
>> has also some impact on runtime-speed of C++, as default-argument
>> "this" gets passed in register and not on stack.
>
> Yes, that has a point & is fine.
>
>
>> Also it allows in some scenarios to import and
>> use msc compiled c++-code.
>>
>
> This isn't. Once again, a properly-enriched GNU IDL compiler + some
> glue code is the superior option.

We on mingw-w64 are using Wine's IDL compiler to generate idl-based
headers.  So you don't tell us something new here.  Nevertheless the
users might be interested to use DCOM as C++ class definitions over
the C-API (which works in general great).  Only thing required to
achieve this goal is to have the proper virtual-table sorting.  This
doesn't make the C++ ABI model fully compatible, but at least it would
allow users to use C++ interfaces.

>
>> There is still a long road to achieve more compatiblity for c++ case,
>> but each step on that brings us near.  Ross, this attitude was in the
>> past exactly the reason why things got stuck and nothing moved
>> anymore.  No progress means death.
>>
>
> To put it bluntly, I don't think most of us are interested in most of
> these changes in the first place. The C changes need to happen (C is
> the compatibility language), the thiscall change makes sense, MSVC++
> compatibility is raising everyone's hackles. Are you going to adopt
> the byzantine size quirks of Microsoft's member-function pointers? We
> don't want this.
Hmm, no.  I don't want to implement the selector-pointers in
vbtable/vtable.  I don't think anybody really needs that.

Regards,
Kai

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Ross Ridge
In reply to this post by Cesar Strauss
Ross Ridge writes:
> There have been no ABI breaking changes made to the GCC C++ ABI since
> GCC 3.4.0.  GCC 4.7.0 is backwards compatible with C++ code compiled
> with GCC 3.4.0.  That is, except on MinGW targets where your changes
> broke the ABI.

NightStrike writes:
> Why do you think that?

Because the major version of the ABI hasn't changed:

        -fabi-version=n

        Use version n of the C++ ABI. Version 2 is the version of the C++
        ABI that first appeared in G++ 3.4. Version 1 is the version
        of the C++ ABI that first appeared in G++ 3.2. [...]

        The default is version 2.

ABIs are not supposed to break on every compiler release.  You might as
well not have one if that's the case.  The whole point in writing the C++
ABI document and all the work done to changing the compiler to conform
to it was so that GCC could have a stable C++ ABI.  GCC could've just
continued to use their old ever-changing poorly-defined "ABI" if they
thought breaking the ABI on every release was inevitiable.

There have been new things addd to the ABI reflecting new features in
the C++ language, but these have been added in a way that doesn't break
the ABI.  Since old compiled code doesn't use these new features, code
compiled with older compilers is still compatible with the updated ABI.

Anyways, if I actually wanted a compiler that was ABI compatible with
Microsoft I know where to find one.  In fact I've already started porting
my code over to it.  Not because of the ABI, but because I don't think
I can deal with any more of this willful ignorance.

You guys can go fuck up the MinGW port of GCC as much you want, I don't
care anymore.

                                        Ross Ridge


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

JonY-3
On 6/13/2012 00:18, Ross Ridge wrote:

> Ross Ridge writes:
>> There have been no ABI breaking changes made to the GCC C++ ABI since
>> GCC 3.4.0.  GCC 4.7.0 is backwards compatible with C++ code compiled
>> with GCC 3.4.0.  That is, except on MinGW targets where your changes
>> broke the ABI.
>
> NightStrike writes:
>> Why do you think that?
>
> Because the major version of the ABI hasn't changed:
>
> -fabi-version=n
>
> Use version n of the C++ ABI. Version 2 is the version of the C++
> ABI that first appeared in G++ 3.4. Version 1 is the version
> of the C++ ABI that first appeared in G++ 3.2. [...]
>
> The default is version 2.
>
Somehow you expect ABI to change over with a flick of a compiler switch
and still work? Really?

I suggest you get off your high horse and look into the practical side
of things rather than just the theory. C++ ABI break all the time, and
all too easy to break, if you are expecting more, it's your own delusion.

A good practice is to always use the same compiler configuration and
version for all your C++ code. Stray from that and there will be no
guarantees things will work.

> ABIs are not supposed to break on every compiler release.  You might as
> well not have one if that's the case.  The whole point in writing the C++
> ABI document and all the work done to changing the compiler to conform
> to it was so that GCC could have a stable C++ ABI.  GCC could've just
> continued to use their old ever-changing poorly-defined "ABI" if they
> thought breaking the ABI on every release was inevitiable.
>
> There have been new things addd to the ABI reflecting new features in
> the C++ language, but these have been added in a way that doesn't break
> the ABI.  Since old compiled code doesn't use these new features, code
> compiled with older compilers is still compatible with the updated ABI.
>
Updated ABI? Has it changed or has it not changed? Which is it? I don't
think you understand what you are talking about.

> Anyways, if I actually wanted a compiler that was ABI compatible with
> Microsoft I know where to find one.  In fact I've already started porting
> my code over to it.  Not because of the ABI, but because I don't think
> I can deal with any more of this willful ignorance.
>
> You guys can go fuck up the MinGW port of GCC as much you want, I don't
> care anymore.
>

You're welcome.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe

signature.asc (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Dieter Verfaillie
In reply to this post by Ross Ridge
On Tue, 12 Jun 2012 12:18:45 -0400, Ross Ridge wrote:

> Ross Ridge writes:
>> NightStrike writes:
>> Why do you think that?
>
> Because the major version of the ABI hasn't changed:
>
> -fabi-version=n
>
> Use version n of the C++ ABI. Version 2 is the version of the C++
> ABI that first appeared in G++ 3.4. Version 1 is the version
> of the C++ ABI that first appeared in G++ 3.2. [...]
>
> The default is version 2.

The above fragment is incomplete and might give the casual reader
the wrong impression. The text on
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
continues with:

        Version 3 corrects an error in mangling a constant address
        as a template argument.

        Version 4, which first appeared in G++ 4.5, implements a
        standard mangling for vector types.

        Version 5, which first appeared in G++ 4.6, corrects the
        mangling of attribute const/volatile on function pointer
        types, decltype of a plain decl, and use of a function
        parameter in the declaration of another parameter.

        Version 6, which first appeared in G++ 4.7, corrects the
        promotion behavior of C++11 scoped enums and the mangling
        of template argument packs, const/static_cast, prefix ++
        and –, and a class scope function used as a template argument.

        See also -Wabi.

Regards,
Dieter


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Earnie Boyd
In reply to this post by JonY-3
We now have two issues opened for 4.7.0.  I've questioned the
libraries being used in both.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

xunxun
于 2012/6/14 19:27, Earnie Boyd 写道:
> We now have two issues opened for 4.7.0.  I've questioned the
> libraries being used in both.
>
Which two issues?

btw, GCC 4.7.1 is released. (at lease in SVN)

--
Best Regards,
xunxun


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Chris Sutcliffe-2
In reply to this post by Earnie Boyd
On 14 June 2012 07:27, Earnie Boyd wrote:
> We now have two issues opened for 4.7.0.  I've questioned the
> libraries being used in both.

Do mingwrt and w32api need to be rebuilt with this GCC release (I read
there was an ABI breakage)?

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

NightStrike
In reply to this post by Earnie Boyd
On Thu, Jun 14, 2012 at 7:27 AM, Earnie Boyd
<[hidden email]> wrote:
> We now have two issues opened for 4.7.0.  I've questioned the
> libraries being used in both.

Link?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

xunxun
于 2012/6/14 19:44, NightStrike 写道:
> On Thu, Jun 14, 2012 at 7:27 AM, Earnie Boyd
> <[hidden email]> wrote:
>> We now have two issues opened for 4.7.0.  I've questioned the
>> libraries being used in both.
> Link?

Earnie sent it to me, but not mail list.

Earnie wrote :

A lazy lot.

https://sourceforge.net/tracker/?func=detail&aid=3535075&group_id=2435&atid=102435
https://sourceforge.net/tracker/?func=detail&aid=3534844&group_id=2435&atid=102435



--
Best Regards,
xunxun


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Earnie Boyd
In reply to this post by Chris Sutcliffe-2
On Thu, Jun 14, 2012 at 7:40 AM, Chris Sutcliffe wrote:
> On 14 June 2012 07:27, Earnie Boyd wrote:
>> We now have two issues opened for 4.7.0.  I've questioned the
>> libraries being used in both.
>
> Do mingwrt and w32api need to be rebuilt with this GCC release (I read
> there was an ABI breakage)?

I'm under the impression that we should if just for the safety reason.
 The GCC mingw-get meta data should be keyed to the versions of
mingwrt and w32api as well and other packages keyed to the mingwrt
version.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Earnie Boyd
In reply to this post by xunxun
On Thu, Jun 14, 2012 at 8:37 AM, xunxun wrote:
> 于 2012/6/14 19:44, NightStrike 写道:
>> On Thu, Jun 14, 2012 at 7:27 AM, Earnie Boyd
>> <[hidden email]> wrote:
>>> We now have two issues opened for 4.7.0.  I've questioned the
>>> libraries being used in both.
>> Link?
>
> Earnie sent it to me, but not mail list.

Because I expected the reply to go to the list but the mail client
chose the first recipient to reply to and I didn't notice.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Chris Sutcliffe-2
In reply to this post by Earnie Boyd
On 14 June 2012 08:38, Earnie Boyd wrote:
> On Thu, Jun 14, 2012 at 7:40 AM, Chris Sutcliffe wrote:
>> Do mingwrt and w32api need to be rebuilt with this GCC release (I read
>> there was an ABI breakage)?
>
> I'm under the impression that we should if just for the safety reason.
>  The GCC mingw-get meta data should be keyed to the versions of
> mingwrt and w32api as well and other packages keyed to the mingwrt
> version.

I can roll-out a new '-2' release of the existing versions fairly
quickly.  Doing another sweep of open issues on each existing version
and looking at addressing them will take me at least a couple of weeks
given my current workload.

Any preference?

Chris

--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Earnie Boyd
On Thu, Jun 14, 2012 at 9:16 AM, Chris Sutcliffe wrote:

> On 14 June 2012 08:38, Earnie Boyd wrote:
>> On Thu, Jun 14, 2012 at 7:40 AM, Chris Sutcliffe wrote:
>>> Do mingwrt and w32api need to be rebuilt with this GCC release (I read
>>> there was an ABI breakage)?
>>
>> I'm under the impression that we should if just for the safety reason.
>>  The GCC mingw-get meta data should be keyed to the versions of
>> mingwrt and w32api as well and other packages keyed to the mingwrt
>> version.
>
> I can roll-out a new '-2' release of the existing versions fairly
> quickly.  Doing another sweep of open issues on each existing version
> and looking at addressing them will take me at least a couple of weeks
> given my current workload.
>
> Any preference?
>

Do the quick release with a later release of fixes.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
123