> 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
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
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 defa
> 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
>
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
im
2013/7/18 Václav Zeman
> 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.
> >
> >
> http://repo.or.cz/w/mingw-w64/jace
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.
>
> http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/7de73e013cbeec88464d19b07bc
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 us
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
t
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" :
> Kai, can you offer some compiler insight here?
>
> Something is getting tangled here, but I'm not quite s
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 sa
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:
>
>
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 `_imp__Interlock
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
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" :
> This seems to be GCC limitation. I experimented a bit and it can't
> inline function if
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
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
> d
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
yeah, Jacek's patch is ok.
Kai
Am 15.07.2013 16:06 schrieb "dw" :
>
> >
> >> 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 buil
>
>> 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. A
> 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 in
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 forwardin
23 matches
Mail list logo
