I committed the patch with additional __MINGW_INTRIN_INLINE check so we
can move on (to another problem on x64).
I committed the additional updates I had sent privately to Erik.
As for the __MINGW_INTRIN_INLINE thing, I guess I still don't quite
understand the value. If it isn't defined, is
On 07/18/13 23:43, dw wrote:
I can confirm that with GCC 4.9. In cause of our headers, it always
chooses inline version, which is good.
That is the best possible outcome. For this particular situation. But
it's possible that's not always the case.
What with normal implementations, inline
On 18 July 2013 23:54, dw wrote:
you are changing Interlocked*() calls to system DLL
functions into inline functions
This is true. If you are using x86, non-underscore versions (ie
InterlockedExchange vs _InterlockedExchange) of these 6 functions.
I hope this is disabled by default /
On 07/18/13 23:43, dw wrote:
I can confirm that with GCC 4.9. In cause of our headers, it always
chooses inline version, which is good.
That is the best possible outcome. For this particular situation. But
it's possible that's not always the case.
What with normal implementations, inline
this issue seems t be related to a bug fixed for gcc' trunk and for
the 4.8 branch.
Could you test more recent version to see if issue remains?
Umm. Hmm. Ok, well, the compiler now does (silently) pick one of the
two defined implementations and uses it consistently. I'd be interested
On 07/18/13 08:49, dw wrote:
this issue seems t be related to a bug fixed for gcc' trunk and for
the 4.8 branch.
Could you test more recent version to see if issue remains?
Umm. Hmm. Ok, well, the compiler now does (silently) pick one of the
two defined implementations and uses it
On 07/15/2013 12:02 PM, Jacek Caban wrote:
Hi,
Please review following patches:
http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/45606ff91bcf7bf34e81acc13ce239bc524290cd
Let's get rid of empty files.
2013/7/18 Václav Zeman vhais...@gmail.com
On 07/15/2013 12:02 PM, Jacek Caban wrote:
Hi,
Please review following patches:
http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/45606ff91bcf7bf34e81acc13ce239bc524290cd
Let's get rid of empty files.
I can confirm that with GCC 4.9. In cause of our headers, it always
chooses inline version, which is good.
That is the best possible outcome. For this particular situation. But
it's possible that's not always the case.
What with normal implementations, inline implementations, dllimport
you are changing Interlocked*() calls to system DLL
functions into inline functions
This is true. If you are using x86, non-underscore versions (ie
InterlockedExchange vs _InterlockedExchange) of these 6 functions.
I hope this is disabled by default / __MINGW_INTRIN_INLINE is undefined
by
On 07/17/13 01:12, dw wrote:
Please review the new patch
Well, we got your good news and your bad news.
On the plus side, this patch fixes the problem I was seeing with -Os.
On the downside, my release build script also uses
-fwhole-program. This is giving me a link error:
/undefined
Kai, can you offer some compiler insight here?
Something is getting tangled here, but I'm not quite sure what.
I can't reproduce it here. It looks like a GCC bug, but I'm not
familiar with those constprop symbols. Maybe Kai will have some idea.
I've had someone else try, and they see the
Hi
this issue seems t be related to a bug fixed for gcc' trunk and for the 4.8
branch.
Could you test more recent version to see if issue remains?
Kai
Am 17.07.2013 14:14 schrieb dw limegreenso...@yahoo.com:
Kai, can you offer some compiler insight here?
Something is getting tangled here,
On 07/15/13 22:34, dw wrote:
Let's get rid of empty files.
Ok by me.
Since my automake isn't up to creating .in files, I was going to wait
until I was sure I wasn't going to have any more before asking someone
to help. I'm aware of at least one more file that needs to have this
done
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
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
That indeed helps, thanks! Please review the new patch:
http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/f7429586bb3289d54e4654f08849161e38ce67a8
Tested on GCC 4.8.1 and trunk.
Jacek
On 07/16/13 15:25, Kai Tietz wrote:
The limitation is fixed for trunk, and gcc 4.8.x
I committed there a
Please review the new patch
Well, we got your good news and your bad news.
On the plus side, this patch fixes the problem I was seeing with -Os.
On the downside, my release build script also uses -fwhole-program.
This is giving me a link error:
/undefined reference to
Hi,
Please review following patches:
http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/45606ff91bcf7bf34e81acc13ce239bc524290cd
Let's get rid of empty files.
http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/7de73e013cbeec88464d19b07bccfc46285c35a5
Inline functions are better way for
Let's get rid of empty files.
Ok by me.
Since my automake isn't up to creating .in files, I was going to wait
until I was sure I wasn't going to have any more before asking someone
to help. I'm aware of at least one more file that needs to have this
done (intrincs\membarrier.c is not an
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
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
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
23 matches
Mail list logo
