Thanks! Really useful info indeed. I'm currently having LTO level 1 enabled 
in Nebula3, and LTO level 3 in Oryol. I had problems with LTO in the past, 
but not yet with the fastcomp backend. 

I'm really impressed with the level of C++11 support, both atomic and 
chrono support means I can get rid of a lot of platform-specific code paths 
:)

Cheers,
-Floh.

Am Donnerstag, 10. April 2014 23:32:55 UTC+2 schrieb Bruce Mitchener:
>
> I've spent an inordinate amount of time fixing, upgrading and testing 
> C++11 things in emscripten in the past.
>
> The big gaps are:
>
>
>    - Threads (obviously)
>    - Atomics (fixed now and this used to work before the switch to LE32).
>    - Some aspects of futures as these require exception features which 
>    are not supported. The big missing exception feature in this area is 
>    std::exception_ptr.
>    - Some locale stuff since emscripten doesn't support any extra locales.
>    
>
> Pretty much everything else has worked at some point in time on 
> emscripten.  Bugs were found in libcxx, LLVM and emscripten in the process 
> of this testing and most have been fixed. Some bugs involving LTO were not 
> fixed though, as far as I can recall but they might've been fixed by other 
> changes as I haven't retested with the latest LLVM / Clang.
>
> Hope this is useful info!
>
> - Bruce
>
>
>
> On Thu, Apr 10, 2014 at 5:13 PM, Floh <[email protected] <javascript:>>wrote:
>
>> Thanks for implementing this Alon!
>>
>> I also just had a look at std::chrono, and it actually looks like it is 
>> working fine (I was confused earlier because chrono::system_clock which I 
>> was using for testing only has millisecond resolution on emscripten, but 
>> seems to have more resolution on native OSX, however the 
>> chrono::high_resolution_clock provides sub-millisecond accuracy in 
>> emscripten... I think the C++11 standard doesn't mention any real accuracy 
>> requirements, so I think emscripten's behaviour is perfectly fine.
>>
>> Apart from std::thread (naturally) I think this should cover any 
>> platform-specifics for C++11 I think...?
>>
>> -Floh.
>>
>> Am Dienstag, 8. April 2014 01:23:15 UTC+2 schrieb Alon Zakai:
>>
>>> We need to implement those in CallHandlers.h in fastcomp, basically. Not 
>>> too much work, and it will be expanded out inline so no call overhead. Can 
>>> you please file a github issue with a testcase?
>>>
>>> - Alon
>>>
>>>
>>>
>>> On Mon, Apr 7, 2014 at 1:17 PM, Floh <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I was dabbling with C++11 a while ago and had code generation problems 
>>>> with atomic operations (see here: https://groups.google.
>>>> com/forum/#!searchin/emscripten-discuss/C$2B$2B11$
>>>> 20atomic/emscripten-discuss/UN1moUZilrM/m_Qm1KSVGrQJ)
>>>>
>>>> The good news is that this specific problem seems to be fixed with 
>>>> clang3.4 in the fastcomp backend, however, I'm now getting linker errors 
>>>> where LLVM wants to call CRT functions for atomic operations:
>>>>
>>>> warning: unresolved symbol: __atomic_store_1
>>>> warning: unresolved symbol: __atomic_load_4
>>>> warning: unresolved symbol: __atomic_load_1
>>>> warning: unresolved symbol: __atomic_fetch_sub_4
>>>> warning: unresolved symbol: __atomic_store_4
>>>> warning: unresolved symbol: __atomic_fetch_add_4
>>>> warning: unresolved symbol: __atomic_compare_exchange_4
>>>>
>>>> I'm wondering now how to treat this type of problem onward. I'm 
>>>> currently having ifdefs for emscripten around this code, basically treat 
>>>> some subset of C++11 as platform-specific and have an emscripten-specific 
>>>> implementation (which would very likely be more efficient anyway, since 
>>>> it's just basic load/add/sub instead of calling into a function). 
>>>>
>>>> Is there a plan / time-line for missing C++11 stuff, and is there a 
>>>> list somewhere what C++11 areas don't work? I assume thread (obviously), 
>>>> atomic, and chronos?
>>>>
>>>> These are the only areas which I had trouble with so far btw, other 
>>>> C++11 stuff seems to work fine.
>>>>
>>>> Cheers,
>>>> -Floh.
>>>>
>>>>  -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "emscripten-discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to