The limitation is fixed for trunk, and gcc 4.8.x
I committed there a fix for that. It might be interesting if rgat change
relaxes the other inline-issue too.
Kai
Am 16.07.2013 04:31 schrieb "Jacek Caban" <ja...@codeweavers.com>:
> 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>:
>
>>
>> >
>> >> 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
>> 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
> listMingw-w64-public@lists.sourceforge.nethttps://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
> listMingw-w64-public@lists.sourceforge.nethttps://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
