This seems to be GCC limitation. I experimented a bit and it can't
inline function if it's also declared as dllimport. That fact, in
combination with always_inline, causes an error. We may work around that
by not using always_inlines for those functions and being careful to not
use dllimport in our headers. See this patch:

http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/fba0f1553846c179a096062d60830ed408104c2e

According to my quick tests with GCC 4.8.1, those calls are inlined for
every optimization level except -O0 as long as dllimport is not declared
by like in case like boost. The good thing about this patch is that in
case of boost, it will use (slow) kernel32 calls, but things will work.
Better solution would require GCC fixes.

BTW, boost may be also interested in avoiding their declaration to get
better performance (for this stuff this is likely to matter) if we
decide to commit it.

Cheers,
Jacek

On 07/16/13 07:21, dw wrote:
> Arrg!  That's not going to work either.
>
> You can't inline something (which is what we are doing) AND have it be
> DLLIMPORT (which is what boost is doing):
>
> /error: inlining failed in call to always_inline 'LONG
> InterlockedExchange(volatile LONG*, LONG)': function not inlinable/
>
> This would work if boost didn't have their own copy of the function
> prototype.
>
> Sorry Jacek, I liked your idea of changing this to inlining.
>
> Before we surrender, is it worth talking to the boost people?  Or
> should I just change this back to use the DLL?
>
> dw
>
> On 7/15/2013 6:26 PM, Kai Tietz wrote:
>>
>> yeah, Jacek's patch is ok.
>>
>> Kai
>>
>> Am 15.07.2013 16:06 schrieb "dw" <limegreenso...@yahoo.com
>> <mailto:limegreenso...@yahoo.com>>:
>>
>>
>>     >
>>     >> Inline functions are better way for forwarding calls, esp. in
>>     this case.
>>     >
>>     > Ok by me, but shouldn't you do all 6?
>>
>>     Turns out your prediction of trouble came true faster than expected.
>>
>>     Looking at the mass build report, there are a number of errors
>>     that all
>>     map to these stdcall functions.  As near as I can make out, what
>>     happened was this:
>>
>>     Boost duplicated the lines declaring the prototypes for these
>>     functions
>>     (see
>>     http://svn.boost.org/svn/boost/trunk/boost/detail/interlocked.hpp).
>>     They declared these functions as DLLIMPORT.
>>
>>     Normally not a problem, but when I did "#define InterlockedExchange
>>     _InterlockedExchange" in winbase, suddenly their code started looking
>>     for an import named "_imp___InterlockedExchange@8" (note the triple
>>     underscore) instead of _imp__InterlockedExchange@8 (double
>>     underscore).
>>
>>     Jacek's proposed patch (if he does all 6 stdcall functions) should
>>     resolve this problem.
>>
>>     dw
>>
>>     
>> ------------------------------------------------------------------------------
>>     See everything from the browser to the database with AppDynamics
>>     Get end-to-end visibility with application monitoring from
>>     AppDynamics
>>     Isolate bottlenecks and diagnose root cause in seconds.
>>     Start your free trial of AppDynamics Pro today!
>>     
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>     _______________________________________________
>>     Mingw-w64-public mailing list
>>     Mingw-w64-public@lists.sourceforge.net
>>     <mailto:Mingw-w64-public@lists.sourceforge.net>
>>     https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to