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

Earnie Boyd
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

------------------------------------------------------------------------------
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: Tue, 12 Jun 2012 10:31:25 +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/12 Jared Maddox <[hidden email]>:
>>> Date: Mon, 11 Jun 2012 19:33:18 +0200
>>> From: Kai Tietz <[hidden email]>

>>> 2012/6/11 Ross Ridge <[hidden email]>:
>>>> Kai Tietz writes:

>>> 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.

That's good to hear.


> Especially of interest is here the exception-model.

The SEH/VEH thing? I haven't used MSVC++ since 6.0 (and without any
proper understanding!) so all I know is what I've researched for
random odd ideas.


> 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.
>

Java would be nice as well, but I suppose that would require something
further upstream? I don't use it myself, but I never really have
understood why the GNU Java/C++ exception problem exists in the first
place, I would think some sort of conversion/wrapping code would be
inserted into the relevant functions.


> 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.
>

I personally don't find this interesting (I consider the C format to
aid in understanding, and think it's where COM programmers should
therefor start), but I can certainly understand the appeal that it
could have to some.


> 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.
>

Could you point me at it? It won't come up for a while, but I have
some stuff I want to use GUIDs for, so this is relevant to my
interests.


>> 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.
>

It might be relevant for Mono/etc., and WinRT is supposedly using some
extra info inside it's executables that it got from the CLR.


>> 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.
>

I did a quick Google search but didn't find anything recent. What
should I search for?


>   So I wanted just to point out that this "all or nothing" approach
> requested by Ross leads nowhere.

I agree.


> Regards,
> Kai
>

Thanks for the clarifications.

------------------------------------------------------------------------------
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

Eli Zaretskii
In reply to this post by Earnie Boyd
> Date: Thu, 14 Jun 2012 18:20:19 -0400
> From: Earnie Boyd <[hidden email]>
>
> 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.

------------------------------------------------------------------------------
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

Fredric Johansson
In reply to this post by Earnie Boyd
On Thu, Jun 14, 2012 at 2:38 PM, Earnie Boyd
<[hidden email]> wrote:

> 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.
>
I did a rebuild of latest mingwrt and w32api with gcc-4.7 to test. I'm
not sure if they were built correctly or if there is a bug because now
a simple "hello world" in either c or c++  crash on load. Do anyone
else who have tested experienced that?

//Fredric

------------------------------------------------------------------------------
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

revelator
Den 15-06-2012 10:07, Fredric Johansson skrev:

> On Thu, Jun 14, 2012 at 2:38 PM, Earnie Boyd
> <[hidden email]>  wrote:
>> 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.
>>
> I did a rebuild of latest mingwrt and w32api with gcc-4.7 to test. I'm
> not sure if they were built correctly or if there is a bug because now
> a simple "hello world" in either c or c++  crash on load. Do anyone
> else who have tested experienced that?
>
> //Fredric
>
> ------------------------------------------------------------------------------
> 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
First time i tried building 4.7.0 everything that used libstdc++ (static
or dynamic) would crash, i had to rebuild api crt and binutils +
dependencies (gmp mpfr mpc iconv pthread etc) before it started working
so yes i can confirm that it happens. My current build seems to work
though but its a mingw64 build. older compiled libraries seem to work ok
with it also if the things above are rebuilt with 4.7.0.

Regards Ralph

------------------------------------------------------------------------------
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

CuteAlien
This post has NOT been accepted by the mailing list yet.
In reply to this post by Cesar Strauss
Hello,

usually I would be glad to see MinGW use same packing as Microsoft by default. But it seems I run into some trouble with the new setting. Unless I'm missing something this flags does not only affect packing of bitfields but packing of structs in general. And unfortunately the results are not identical to the Microsoft compiler but different to gcc 4.6 as well as to the compiler in VisualStudio.

Example:
// The struct "Header" is not using bitfields, but still when compiled with
// -m-ms-bitfields (which is now the new default) it will be larger than with
// -mno-ms-bitfields.
// I get _different_ results from compiling with Microsoft Compiler and packing when using -m-ms-bitfields
// I get _identical_ results when compiling with -mno-ms-bitfields.
 
#include <cstdio>
 
#if defined(_MSC_VER)
#pragma pack( push, packing )
#pragma pack( 1 )
#endif
 
struct Header
{
        unsigned char IdLength;
        unsigned char ColorMapType;
        unsigned char ImageType;
        unsigned char FirstEntryIndex[2];
        unsigned short ColorMapLength;
        unsigned char ColorMapEntrySize;
        unsigned char XOrigin[2];
        unsigned char YOrigin[2];
        unsigned short ImageWidth;
}
#if defined(__GNUC__)
__attribute__((packed))
#endif
;
 
#if defined(_MSC_VER)
#pragma pack( pop, packing )
#endif
 
int main ()
{
        printf("sizeof(Header): %d\n", sizeof(Header));
        return 0;
}
 

Results for the size are:
With VS 2010 (32 bit as well as 64-bit): 14
Compiled with -mno-ms-bitfields: 14
New default or with -mms-bitfields: 16

I'm currently not sure how to handle that in a library, if I should add -mno-ms-bitfields or better wait a little as this doesn't look really ok to me so far. Any help welcome.

Greetings,
Michael
Reply | Threaded
Open this post in threaded view
|

Re: MinGW GCC 4.7.0 released

Cesar Strauss
In reply to this post by Cesar Strauss
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


------------------------------------------------------------------------------
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

Eli Zaretskii
> From: Cesar Strauss <[hidden email]>
> 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?

------------------------------------------------------------------------------
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

Cesar Strauss
On 07/12/2012 02:21 AM, Eli Zaretskii wrote:

>> From: Cesar Strauss <[hidden email]>
>> 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


------------------------------------------------------------------------------
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

Valerio Messina
In reply to this post by Cesar Strauss
>----Messaggio originale----
>From: [hidden email]
>
>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

I feel remember once I read for C, the ISO standardized an ABI back in 89, so
different compilers should link without problem, please confirm this.
Different case for C++ where mangling is not standard (why?) and so, no
possibility to interwork. I'm right?

I read the links on call conventions, but apart C++ features, seems to me that
only small struct can behave differently (in mem with hidden ptr or via EAX:EDX
regs).
Someone did know what say ISO about returning structures?
Is VisualC (or gcc) do not following the ABI standard?

thank you for curiosity satisfaction,
Valerio


------------------------------------------------------------------------------
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

Greg Chicares
On 2012-07-13 08:06Z, [hidden email] wrote:
>
> I feel remember once I read for C, the ISO standardized an ABI back in 89, so
> different compilers should link without problem, please confirm this.

No. See:
  http://stackoverflow.com/questions/4489012/does-c-have-a-standard-abi

> Different case for C++ where mangling is not standard (why?) and so, no
> possibility to interwork.

(A) C++ name-mangling is not standard
(B) C++ objects built by different compilers are generally not compatible

(A) and (B) are both true, but (A) is not the reason for (B). Instead,
(B) is the motivation for (A). See the Stroustrup quote here:
  http://www.mingw.org/wiki/MixingCompilers

------------------------------------------------------------------------------
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

〇〇
This post has NOT been accepted by the mailing list yet.
This post was updated on .
In reply to this post by Cesar Strauss
Why to enable MinGW GCC 4.7.0  compatible with c++11 standard features,we must add -std=c++11?  isn't it a default option?
123