在 2018/6/27 13:52, Martin Storsjö 写道:
> On Wed, 27 Jun 2018, Martin Storsjö wrote:
> 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? And for the firefox case, did you fix it by adding 
> -fms-extensions?
> 
> I do remember running into a few issues with inlines in our headers, 
> behaving differently than with gcc - mainly in cases with non-static 
> inline. GCC would either emit the function (as inline so it doesn't 
> conflict with other definitions) or inline it totally. While clang on 
> the other hand would conclude that since it's non-static inline, there 
> will be a function definition elsewhere and just try to reference that 
> (which fails).
> 
> Those particular cases that I've run into, I've worked around so far in 
> one way or another though (but there's probably more of them that I 
> haven't happened to use, while firefox does), but I'm pretty sure the 
> headers rely on some aspects that aren't really guaranteed to behave in 
> that way, and in those cases, we maybe should fix the headers and how 
> they use inline.
> 

I made a conclusion:
   https://gist.github.com/lhmouse/7edb7974b7e776d55592ab11260d2448

In C99 mode the `extern` keyword becomes significant on inline function 
declarations, where it isn't in GNU or C++ modes. In order to preserve 
the consistency I am at the moment against removal of the 
`__gnu_inline__` attribute. It is much more sane than the C99 one, 
despite being an extension.

-- 
Best regards,
LH_Mouse
------------------------------------------------------------------------------
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

Reply via email to