Hello,
On 27/06/2018 07:52, Martin Storsjö wrote:
I did a test build with this patch, and it failed at building
winpthreads, with the following error:
Yeah, I can reproduce problems. Sorry for not catching it earlier,
initial testing looked promising.
And just to make it clear - this is code that builds fine with
clang+lld as things stand right now (without -fms-extensions anywhere).
What was the exact issue you're trying to fix by tweaking the
__forceinline define?
It's the extern part that I tried to get rid of. With the current
definition, you can't use it like:
static int __forceinline func() { ... }
because static would conflict with extern. If __forceinline could avoid
extern and use only attributes (inline, gnu_inline, always_inline - it
doesn't matter in this aspect), it would be fine. This is a problem I
had to work around for quite a few times in the past. I recall looking
at fixing it for GCC years ago and the conclusion was that there is no
good solution. When I saw it with clang, I hoped that maybe we could do
better now. After all, in clang-cl mode, it supports __forceinline
properly, so there should be a way for us to use that. I plan to have
another look at this later, but I worked around this on Firefox side for
now.
And for the firefox case, did you fix it by adding -fms-extensions?
No, I don't use -fms-extensions for those builds yet. I plan to revisit
that later, but for the initial work, I skipped it.
My toolchain, however, does not contain winpthreads. libc++ doesn't need
it to support threads. It does native Windows calls for what it needs,
so I don't need winpthreads.
Thanks,
Jacek
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
