GCC 4.3.0 i386-pc-mingw32 ALPHA Release

[John E. / TDM]

Danny Smith wrote:
> I think you have a genuine GCC bug.  It will get fixed (or not) by GCC developers, not by
> discussions on this list. Please report to GCC bugzilla. This affects cygwin as well
> mingw.  It also affects pe-sh targets that use dllimpoprt.
> Assign to me if you like, I am currently testing a patch that will restore old behaviour.
>  

Filed in GCC Bugzilla as Bug 35921
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921>.

-John E.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

Danny Smith wrote:

> As I understand, "inline dllimport" under MSVC means:
> "inline, if possible, else resolve as external defined in another module (specifically a
> dll)."

Are you sure?  Everything I've seen indicates the 'inline' should be
ignored, and I can't get MSVC to do anything other than that.

These new semantics seem opposite, ignore the 'dllimport' and use the
inline.

It's just I'm concerned this will not cause an export where it should,
which changes how the ABI works.  It seems to me that its very important
we emulate MSVC in these matters.

But if you think this is OK, then I won't object further.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Danny Smith]

> -----Original Message-----
> From: mingw-dvlpr-bounces@...
> [mailto:mingw-dvlpr-bounces@...] On Behalf
> Of Aaron W. LaFramboise
> Sent: Sunday, 13 April 2008 1:39 p.m.
> To: MinGW Devlopers Discussion List
> Subject: Re: [MinGW-dvlpr] GCC 4.3.0 i386-pc-mingw32 ALPHA Release
>
>
> Danny Smith wrote:
>
> > As I understand, "inline dllimport" under MSVC means:
> > "inline, if possible, else resolve as external defined in
> another module (specifically a
> > dll)."
>
> Are you sure?  Everything I've seen indicates the 'inline' should be
> ignored, and I can't get MSVC to do anything other than that.
>

>From MSDN
"You can also define as inline a function declared with the dllimport attribute. In this
case, the function can be expanded (subject to /Ob specifications), but never
instantiated. In particular, if the address of an inline imported function is taken, the
address of the function residing in the DLL is returned. This behavior is the same as
taking the address of a non-inline imported function."

With GNU, until GCC 4.0, having _any_  definition (inline or not) of a dllimport function
caused so much havoc with RTL generation that the safest option seemed to be to simply
ignore the dllimport if a function was declared inline.  
I tried to do the gnu_inline thing (use the external address if the function was not
inlineable) but that caused bad things to happen with inline dllimport virtual methods
(they need a constant address for vtable initialization).  It may be easier to handle now
at tree level, with the generation of the _imp__foo RTL code delayed until we really know
whats virtual, but at the time easy way out (and the easiest way to debug inline
functions) was to instantiate the function with linkonce semantics.  This is what GCC does
for non-dllimported classes (remove the dllimport from the testcase class and look at
assembly generated without optimization)


This is what GNU docs say:
"Currently, the [dllimport] attribute is ignored for inlined functions."
It should really say:
"Currently, the [dllimport] attribute is ignored for functions declared inline."

> These new semantics seem opposite, ignore the 'dllimport' and use the
> inline.
>
That is not new GCC semantics. It has been around since mingw's distro of gcc 2.95.2,
which backported 3.0 patches to make dllimport useable.

> It's just I'm concerned this will not cause an export where
> it should,
> which changes how the ABI works.  It seems to me that its
> very important
> we emulate MSVC in these matters.
>
Do you mean the rule that says: "If a dllimport is defined, assume that the user _really_
meant dllexport." ?
If you do, than we _should_ be instantiating the non-inlineable "inline dllimport"
[cd]tors as GNU did until 4.3.0



Danny


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

Danny Smith wrote:

>>From MSDN
> "You can also define as inline a function declared with the dllimport attribute. In this
> case, the function can be expanded (subject to /Ob specifications), but never
> instantiated. In particular, if the address of an inline imported function is taken, the
> address of the function residing in the DLL is returned. This behavior is the same as
> taking the address of a non-inline imported function."

OK, thanks for finding this.

> With GNU, until GCC 4.0, having _any_  definition (inline or not) of a dllimport function
> caused so much havoc with RTL generation that the safest option seemed to be to simply
> ignore the dllimport if a function was declared inline.  
> I tried to do the gnu_inline thing (use the external address if the function was not
> inlineable) but that caused bad things to happen with inline dllimport virtual methods
> (they need a constant address for vtable initialization).  It may be easier to handle now
> at tree level, with the generation of the _imp__foo RTL code delayed until we really know
> whats virtual, but at the time easy way out (and the easiest way to debug inline
> functions) was to instantiate the function with linkonce semantics.  This is what GCC does
> for non-dllimported classes (remove the dllimport from the testcase class and look at
> assembly generated without optimization)

And thanks for this explanation.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr