I see, thanks for the info! I'm not planning to go all-in with C++11 for production code anytime soon, so this is not high-prio for me :)
-Floh. Am Mittwoch, 18. Dezember 2013 03:55:27 UTC+1 schrieb azakai: > > We certainly intend to support everything in the new triple, just a matter > of time. Currently I am moving to a fork of LLVM at > https://github.com/kripken/emscripten-fastcomp , mainly for the new llvm > backend stuff, but it will also make it easier for us to customize stuff in > llvm as needed, which I think this might require (but not sure). > > I don't want to encourage people to use the i386 triple. It has major > downsides (unoptimal alignment, for example), and supporting both triples > is complex. We do mostly support both right now, but the standard le32 one > is the way to go for the future. > > Thanks for the testcase, when that fork is a little more stable I'll see > how easy it is to fix things there. > > - Alon > > > > On Tue, Dec 17, 2013 at 5:47 AM, Floh <[email protected] <javascript:>>wrote: > >> Ok, attached is a testcase which should test all std::atomic<> and >> std::atomic_flag features (atomic<> only for specialization atomic<int>). >> On failure this does a standard assert(), not sure whether this is >> compatible with the emscripten test suite. On success "success!" is printed >> and the code exits with return value 0. >> >> To compile on native clang (tested with OSX native clang): >> >> clang -std=c++11 test_atomic.cpp -o test_atomic >> >> Compiling with emscripten only works with the i386-pc-linux-gnu triple, >> all tests work in this case :) >> >> EMCC_LLVM_TARGET=i386-pc-linux-gnu ~/emscripten/emcc -std=c++11 >> test_atomic.cpp -o test.html >> >> Is the plan to get this working with the standard-triple? If this is not >> feasible, maybe selecting the LLVM_TARGET through a "-s" command line >> setting instead of an environment variable might be a good solution in the >> meantime? >> >> Cheers, >> -Floh >> >> Am Dienstag, 17. Dezember 2013 13:01:33 UTC+1 schrieb Floh: >> >>> Using the i386-pc-linux-gnu target does indeed work out of the box! I'll >>> write a little test case. Getting at least the C++11 atomic stuff >>> transparently working would indeed be very cool. I'll write a little test >>> case next. >>> >>> Am Montag, 16. Dezember 2013 23:12:49 UTC+1 schrieb azakai: >>>> >>>> This might be a limitation of the le32 target, does x86 have it? try >>>> with EMCC_LLVM_TARGET=i386-pc-linux-gnu in the environment. If so >>>> though, that's not good workaround, but at least we'd know what needs >>>> fixing. >>>> >>>> Can you make a testcase of this? I can test it on latest upstream le32 >>>> as well. >>>> >>>> - Alon >>>> >>>> >>>> >>>> On Mon, Dec 16, 2013 at 9:00 AM, Floh <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm currently playing around with C++11 as a side project, and I'm >>>>> having trouble in emscripten with std::atomic (somewhat expected, but I >>>>> was >>>>> naively hoping that this compiles to some sort of dummy implementation). >>>>> >>>>> I'm having these problems: >>>>> >>>>> std::atomic<int> increment and decrement produces these errors: >>>>> >>>>> ''' >>>>> In file included from /Users/floh/emscripten/system/ >>>>> include/libcxx/memory:610: >>>>> /Users/floh/emscripten/system/include/libcxx/atomic:667:17: error: >>>>> cannot compile this atomic library call yet >>>>> {return __c11_atomic_fetch_sub(&this->__a_, __op, __m);} >>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> /Users/floh/emscripten/system/include/libcxx/atomic:661:17: error: >>>>> cannot compile this atomic library call yet >>>>> {return __c11_atomic_fetch_add(&this->__a_, __op, __m);} >>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> ''' >>>>> >>>>> This looks like this is already happening in clang, but going from 3.2 >>>>> to 3.3 didn't help. >>>>> >>>>> The other problem is a simple linker error that __atomic_load can't be >>>>> resolved. >>>>> >>>>> Other than this threading/atomic stuff I didn't encounter other C++11 >>>>> problems in emscripten so far (but I've only scratched the surface yet: >>>>> in-class member-initialisation, move-stuff, make_shared and the new for >>>>> (x >>>>> : y) loop stuff). >>>>> >>>>> 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/groups/opt_out. >>>>> >>>> >>>> -- >> 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/groups/opt_out. >> > > -- 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/groups/opt_out.
