emscripten-core / emscripten-fastcomp Goto Github PK
View Code? Open in Web Editor NEWLLVM plus Emscripten's asm.js backend
License: Other
emscripten-fastcomp's People
Contributors
Stargazers
Watchers
Forkers
ehostunreach juj waywardmonkeys sunfishcode jechter famwihc amatus huningxin trevorlinton tritao coolwanglu uplinkcoder nwilson emacneille 8l ericrannaud shawnwalker ezhangle apiotrow fchiba leemorgan-mobile tkihira rossant mnieper loko087 jfbastien indypj abyadtherock ebraheemk cfinhas pkholland dannyk90 regular erlhermit damien2k9 anacondadreams merlin76 gogoprog mcanthony maher4ever hackcasual unity-technologies holland01 wrmsr sandejulio binfmt hobby8 anydream citisolo aleksf cryze h-plus-time rib alexxnica kryndex fwgs timnn kanaka inikolaev hfmanson jlmatchlock mumu1 wmaddox segfault87 saschanaz dylanmckay trzecieu dschuff eclecticdave hariexcel flowergrass dbankov tbfleming varkor aheejin emiscience tannerrogalsky jgravelle-google jiapei100 soundation mhallin tankerhq hujiajie trippleflux tombo-a2o fmfluke gideros bhanditz benjamintrapani laura-ft paulyc hhy5277 dand-oss nikic valeryantopol georgiaboy247 stupidtao sunnyqjm frankfanslc 8847141emscripten-fastcomp's Issues
Build warnings with SIMD.
Building fastcomp gives the following warning messages related to SIMD:
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1376:5: warning: variable 'Name' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
default: I->dump(); error("invalid vector icmp"); break;
^~~~~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1382:54: note: uninitialized use occurs here
Code << getAssignIfNeeded(I) << "SIMD_int32x4_" << Name << "("
^~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1364:19: note: initialize the variable 'Name' to silence this warning
const char *Name;
^
= NULL
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1423:10: warning: variable 'Name' is used uninitialized whenever switch case is taken [-Wsometimes-uninitialized]
case FCmpInst::FCMP_UNO:
^~~~~~~~~~~~~~~~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1445:56: note: uninitialized use occurs here
Code << getAssignIfNeeded(I) << "SIMD_float32x4_" << Name << "("
^~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1417:10: warning: variable 'Name' is used uninitialized whenever switch case is taken [-Wsometimes-uninitialized]
case FCmpInst::FCMP_ORD:
^~~~~~~~~~~~~~~~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1445:56: note: uninitialized use occurs here
Code << getAssignIfNeeded(I) << "SIMD_float32x4_" << Name << "("
^~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1408:10: warning: variable 'Name' is used uninitialized whenever switch case is taken [-Wsometimes-uninitialized]
case ICmpInst::FCMP_UEQ:
^~~~~~~~~~~~~~~~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1445:56: note: uninitialized use occurs here
Code << getAssignIfNeeded(I) << "SIMD_float32x4_" << Name << "("
^~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1439:5: warning: variable 'Name' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
default: I->dump(); error("invalid vector fcmp"); break;
^~~~~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1445:56: note: uninitialized use occurs here
Code << getAssignIfNeeded(I) << "SIMD_float32x4_" << Name << "("
^~~~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:1390:19: note: initialize the variable 'Name' to silence this warning
const char *Name;
^
= NULL
6 warnings generated.
addrspace/multiple HEAP support?
Hello,
currently, the memory space of code generated by emscripten seems to be limited to a single HEAP, which is a JS TypedArray.
As it has been discussed several times, this is a bit inconvenient for some interactions with JS API that provide TypedArray buffers allocated by them, in particular webAudio and I believe WebCanvas do this, and avoiding a copy may be difficult given that these buffers come from the OS stack.
Supporting multiple HEAPs could alleviate this issue (even if care has to be taken in order for the asm.js optimizations to remain in place).
Would it make sense for emscripten to support several heaps? A simple way to implement this feature could be to use LLVM's addrspace pointer attribute to mark the desired heap, as in this example:
; Example of address spaces for JS/EMSCRIPTEN
; Run with $ llvm-as addr-example.ll -o - -f | opt -mem2reg | llc
target triple = "asmjs-unknown-emscripten"
; Values residing in two different address spaces, the idea is that we
; can map an address space to a particular HEAP
@V0 = global i32 0
@V1 = addrspace(1) global i32 0
define i32 @test_add () {
%r0 = load i32, i32 addrspace(0)* @V0
%r1 = load i32, i32 addrspace(1)* @V1
%rr = add i32 %r0, %r1
ret i32 %rr
}which currently generates:
function _test_add() {
var $r0 = 0, $r1 = 0, $rr = 0, label = 0, sp = 0;
sp = STACKTOP;
$r0 = HEAP32[2]|0;
$r1 = HEAP32[4]|0;
$rr = (($r0) + ($r1))|0;
return ($rr|0);
}but after multiple heap support should output something like:
function _test_add() {
var $r0 = 0, $r1 = 0, $rr = 0, label = 0, sp = 0;
sp = STACKTOP;
$r0 = HEAP1_32[2]|0;
$r1 = HEAP32[2]|0;
$rr = (($r0) + ($r1))|0;
return ($rr|0);
}Do you think it would make sense then?
I'm far from knowledgeable in LLVM or EMSCRIPTEN, but after a brief look to the code it seems to me that a possible way to implement this feature would be to refactor getLoad and getStore in JSBackend.c to query the addrspace attribute of the pointer.
Maybe even moving code to a Heap class could work, I dunno.
Regards,
Emilio
Support UBSan and other sanitizers
Clang's -fsanitize family of options are very useful for debugging. For best results, they require a runtime library, however Emscripten does not yet provide that library. Compiling with a small testcase containing a shift produces the following message:
$ emcc -fsanitize=integer so.c
warning: unresolved symbol: __ubsan_handle_shift_out_of_bounds
Memory leaks in Relooper?
I hope it's the right place for this issue. I'm using Relooper in a standalone project on a simple scenario and getting memory leaks, exactly as anticipated in the code.
Is there a more elegant way to fix these leaks than simply tracking which branches have been deleted during the algorithm and cleaning up the remaining ones?
Problem scenario:
bb[0] = new Block("...", nullptr);
bb[1] = new Block("...", nullptr);
bb[2] = new Block("...", nullptr);
bb[1]->AddBranchTo(bb[2], nullptr, nullptr)
bb[1]->AddBranchTo(bb[0], "...", nullptr)
bb[2]->AddBranchTo(bb[0], nullptr, nullptr)
relooper.AddBlock(bb[0]);
relooper.AddBlock(bb[1]);
relooper.AddBlock(bb[2]);
relooper.Calculate(bb[1]);JSMESS still aborts at runtime
I've still not been able to produce a working JSMESS using fastcomp so far. With the latest incoming everything, the compile finishes and runs most of the way through the initialization but then abort()s with a number printed to stdout. Chrome gives a little more detail:
Invalid function pointer called with signature 'viii'. Perhaps this is an invalid value (e.g. caused by calling a virtual method on a NULL pointer)? Or calling a function with an different type, which will fail? messcoleco.js:127
Build with ASSERTIONS=2 for more info.
Built with ASSERTIONS=2 and got the following:
Invalid function pointer '1' called with signature 'viii'. Perhaps this is an invalid value (e.g. caused by calling a virtual method on a NULL pointer)? Or calling a function with an different type, which will fail?
This pointer might make sense in another type signature: iiiiiiii: __ZN17sdl_osd_interface15font_get_bitmapEPvjR13bitmap_argb32RiS3_S3_ viiiii: __ZN8device_t12device_timerER9emu_timerjiPv diddi: __ZN11render_font10char_widthEffj vd: _emscripten_glClearDepth vid: __ZN8device_t15set_clock_scaleEd vi: __ZN13driver_device19driver_init_wrapperIS_XadL_ZNS_6init_0EvEEEEvR15running_machine vii: __ZNK8device_t21device_validity_checkER16validity_checker iiiiiiiiiii: _XmlParseXmlDeclNS viiiiddi: __ZN10ui_manager13draw_text_boxEP16render_containerPKciff5rgb_t ii: __ZNK13driver_device17device_rom_regionEv viiidiii: __ZN13render_target20compute_visible_areaEiifiRiS0_ viddd: __ZN14speaker_device19static_set_positionER8device_tddd iiiiii: __ZN23device_memory_interface11memory_readE16address_spacenumjiRy vidi: __ZN21cassette_image_device4seekEdi viiiiiiiiii: __ZN21ui_menu_file_selectorC2ER15running_machineP16render_containerP22device_image_interfaceR7astringS7_bbbPi viiddii: __ZN11render_font28get_scaled_bitmap_and_boundsER13bitmap_argb32ffjR9rectangle viiddddi: __ZN10ui_manager17draw_outlined_boxEP16render_containerffff5rgb_t viiid: __ZN13render_target10set_boundsEiif vidd: _emscripten_glUniform2f iiii: __ZL31construct_machine_config_colecoR14machine_configP8device_tS2_ iiddii: __ZN11render_font27get_char_texture_and_boundsEffjR13render_bounds viddddiii: __ZN16render_container8add_charEffff5rgb_tR11render_fontt viiiiid: __ZNKSt3__17num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcd viiiiiiii: __ZNKSt3__18time_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8ios_baseEcPK2tmcc viddddii: __ZN16render_container8add_rectEffff5rgb_tj viiiiii: __ZN22address_space_specificIyL12endianness_t1ELb0EE11write_qwordEjyy vdi: _emscripten_glSampleCoverage viid: __ZN12sound_stream13set_user_gainEif di: __ZN14render_manager9ui_aspectEv iiiiiii: __ZN23device_memory_interface12memory_writeE16address_spacenumjiy viiidddiiiiiii: __ZN10ui_manager14draw_text_fullEP16render_containerPKcfffiii5rgb_tS4_PfS5_ vidddd: _emscripten_glUniform4f iid: _luaK_numberK diid: undefined viiiiiii: __ZNKSt3__17num_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_getES4_S4_RNS_8ios_baseERjRb viiiiiid: __ZNKSt3__19money_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_bRNS_8ios_baseEce viiiiiiiii: __ZNKSt3__18time_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_getES4_S4_RNS_8ios_baseERjP2tmcc viddddddii: __Z17extra_text_renderP16render_containerffffffPKcS2_ iii: __ZNK13driver_device19memory_space_configE16address_spacenum dii: __ZN10ui_manager16get_string_widthEPKc i: __Z12netdev_firstv viidddddd: __ZN7ui_menu13custom_renderEPvffffff vidddddii: __ZN16render_container8add_lineEfffff5rgb_tj iiiii: __ZN23device_memory_interface16memory_translateE16address_spacenumiRj vdddddd: _emscripten_glFrustum iiiddiiii: __Z22cassette_write_samplesP14cassette_imageiddjyi vdddd: _emscripten_glRotatef vdd: _emscripten_glDepthRange v: ___cxa_pure_virtual iiiiiiiii: __ZNKSt3__17codecvtIwc11__mbstate_tE6do_outERS1_PKwS5_RS5_PcS7_RS7_ viiii: __ZL15yuv_RGB_to_YV12PtP8sdl_infoPhi
http://fos.textfiles.com/dfjustin/coleco-fastcomp/
Any pointers on troubleshooting this would be welcome.
Code using 16-bit signed integers generates broken JS output
This problem has been encountered when using FreeType, in a function FT_GlyphLoader_Add, that contains a code like this:
FT_UInt n_curr_contours; // <-- this is 32bit unsigned int
...
n_curr_contours = current->outline.n_contours; // <-- this is 16bit signed int
This code gets transformed into:
$n_contours = $loader + 56 | 0;
$0 = HEAP32[$n_contours >> 2] | 0;
$conv = $0 << 16 >> 16;
which in case of large enough value produced broken result: 40680 << 16 >> 16 = -24856.
This broke the loop logic afterwards.
I can't see anything in asm.js spec about this kind of cast, so is this really the way to do it?
Relevant generator code seems to be here:
https://github.com/kripken/emscripten-fastcomp/blob/dfcb07a871addf339ffac17e606e16e97e8c5f71/lib/Target/JSBackend/JSBackend.cpp#L1014
Re-Implement --js-split in fastcomp
Hello there!
The old implementation1 of the --split feature was deprecated because "[...] (modern JavaScript debuggers should work even on large files)."2
This is however not the case in a single 4.618.211 line long, 162M javascript file, which Unreal Engine happens to produce.
Would there be any way to re-implement this feature with fastcomp/clang?
EXCEPTION_CATCHTING_WHITELIST handling
The list is cast to a string, and std::string::find is use to determine if a function is in the list, which is not correct when the name of a function is a substring of another.
128 bit integers not supported (needed for Rust)
Hi!
Rust recently has gained experimental 128 bit integer support. The intention is to, unlike C or C++ which only support it on X86_64, provide 128 bit integers cross platform, just like its done for 64 bit integers already.
The regression test for 128 bit integers in the rust codebase is currently ignored for emscripten. When unignoring it, one gets the error message:
LLVM ERROR: Function _ZN4test9black_box17h6220793b9183d295E has illegal integer argument
This error message originates in code from this repo. The file that contains the error message also states that 64 is the maximum supported number. It would be great if it could be raised to 128.
This is a fairly minimal reproducing example:
#![feature(i128_type, test)]
#[inline(never)]
fn b(i: i128) -> i128 { // same as the black_box function from the test crate
i
}
fn main() {
let x: i128 = b(-1);
let y: i128 = b(3);
assert_eq!(0, !x);
}cc @nagisa
cc @alexcrichton
LLVM_TARGETS_TO_BUILD JSBackend only?
Is it really needed to build LLVM/Fastcomp with X86 target (on x86 system) when it’s used only to generate JS code or WebAssembly? Will it work even when I build it with -DLLVM_TARGETS_TO_BUILD="JSBackend"?
emulate <immintrin.h>
<immintrin.h> is a convenience wrapper supporting all available *mmintrin.h files. Emscripten currently only supports <xmmintrin.h>, but it might as well support the <immintrin.h> wrapper providing it as well.
LLVM ERROR: isalnum(c) || c == '_' || c == '.'
Hello,
I'm testing the latest changes in master because I used to have multiple "undefined reference" errors, especially on exceptions. Those errors are gone but now I have:
LLVM ERROR: isalnum(c) || c == '_' || c == '.'
Traceback (most recent call last):
File "/opt/emscripten/emscripten.py", line 1359, in <module>
_main(environ=os.environ)
File "/opt/emscripten/emscripten.py", line 1347, in _main
temp_files.run_and_clean(lambda: main(
File "/opt/emscripten/tools/tempfiles.py", line 39, in run_and_clean
return func()
File "/opt/emscripten/emscripten.py", line 1355, in <lambda>
DEBUG_CACHE=DEBUG_CACHE,
File "/opt/emscripten/emscripten.py", line 1242, in main
jcache=jcache, temp_files=temp_files, DEBUG=DEBUG, DEBUG_CACHE=DEBUG_CACHE)
File "/opt/emscripten/emscripten.py", line 753, in emscript_fast
backend_output = open(temp_js).read()
IOError: [Errno 2] No such file or directory: '/tmp/tmplq1uA8.4.js'
Traceback (most recent call last):
File "/opt/emscripten/emcc", line 1864, in <module>
final = shared.Building.emscripten(final, append_ext=False, extra_args=extra_args)
File "/opt/emscripten/tools/shared.py", line 1276, in emscripten
assert os.path.exists(filename + '.o.js') and len(open(filename + '.o.js', 'r').read()) > 0, 'Emscripten failed to generate .js: ' + str(compiler_output)
AssertionError: Emscripten failed to generate .js:
Here is the command line I use:
/opt/emscripten/emcc bin/html5/release/minko-example-assimp.bc -o bin/html5/release/minko-example-assimp.html -O2 --closure 1 -s CLOSURE_ANNOTATIONS=1 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s TOTAL_MEMORY=268435456 --preload-file bin/html5/release/asset || source /home/promethe/Projects/minko/tools/lin/scripts/fail.sh bin/html5/release/minko-example-assimp.bc
Any advice?
Thanks,
Compilation fails due to 'CppBackend' target
I'm building this branch in connection with https://github.com/kripken/emscripten-fastcomp-clang according to the emscripten tutorial on enabling the fastcomp path.
During the compilation of llvm, I repeatedly get this message:
llvm-build: error: invalid target to enable: 'CppBackend' (not in project)
but the build process continues. At the end, make errors out due to
/usr/bin/cp: cannot stat ‘CppBackend/Makefile’: No such file or directory
My Release/bin folder contains "count FileUpdate llvm-lit llvm-tblgen FileCheck fpcmp llvm-PerfectShuffle not", but there is no clang++ binary to be found. Would you happen to know why this is going wrong for me? (I'm on a Fedora 19 64bit system)
Prebuilt Binaries
Building this project takes about hours on my machine (Linux). This is makes the ./emsdk install latest command very slow. This could be fixed by providing prebuilt assets. I tried setting up a travis-ci job automate prebuilt assets, but it timed out. I couldn't find any other free CI providers. Does anyone have any ideas for where/how we could automate builds?
Thanks for this awesome project btw!
llvm.fma
Clang eagerly turns fma and fmaf calls into llvm.fma.f32 and llvm.fma.f64 intrinsics, since these functions are defined to never set errno. Emscripten currently doesn't implement these intrinsics, so code using fma and fmaf gets undefined references to llvm.fma.f32 and llvm.fma.f64.
The most obvious fix, adding entries to lib/Target/JSBackend/CallHandlers.h to expand them to plain _fma and _fmaf calls, doesn't appear to work. The calls get rewritten, but the module still appears to declare dependencies on llvm_fma_f32 and llvm_fma_f64.
Flatten global errors on incoming
I am using visual studio 2013 to compile latest incoming git, but stuck at this following :
emscripten-fastcomp\lib\Transforms\NaCl\FlattenGlobals.cpp(178): error C2039: 'getRelocUse' : is not a member of '`global namespace''
emscripten-fastcomp\lib\Transforms\NaCl\FlattenGlobals.cpp(178): error C2660: '`anonymous-namespace'::FlattenedConstant::Reloc::getRelocUse' : function does not take 1 arguments
opt crashes with -std-link-opts
I run this on our codebase:
../emscripten-fastcomp/build/bin/opt -S -std-link-opts -mergefunc -o build/Emscripten.opt_lto.ll build/emscripten/emscripten/build/total.bc
And it crashes with this recursion:
frame #9000: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbf8fb0, V=0x000000010fd24c30, CurBB=0x000000010fd249b0, PredBB=0x000000010fd249b0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220
frame #9001: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbf8fb0, V=0x000000010fd24c30, CurBB=0x000000010fd249b0, PredBB=0x000000010fd249b0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220
frame #9002: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbf8fb0, V=0x000000010fd24c30, CurBB=0x000000010fd249b0, PredBB=0x000000010fd249b0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220
frame #9003: 0x0000000100513963 opt`llvm::PHITransAddr::PHITranslateSubExpr(this=0x00007fff5fbf8fb0, V=0x000000010fd24c30, CurBB=0x000000010fd249b0, PredBB=0x000000010fd249b0, DT=0x0000000000000000) + 1827 at PHITransAddr.cpp:220
frame #9004: 0x000000010051468e opt`llvm::PHITransAddr::PHITranslateValue(this=0x00007fff5fbf8fb0, CurBB=0x000000010fd249b0, PredBB=0x000000010fd249b0, DT=0x0000000000000000) + 158 at PHITransAddr.cpp:322
frame #9005: 0x00000001004fcce4 opt`llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(this=0x000000010ea409b0, Pointer=0x00007fff5fbfa7b0, Loc=0x00007fff5fbf9978, isLoad=true, StartBB=0x000000010fd249b0, Result=0x00007fff5fbfd0e0, Visited=0x00007fff5fbfc758, SkipFirstBlock=false) + 7620 at MemoryDependenceAnalysis.cpp:1240
frame #9006: 0x00000001004fd00f opt`llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(this=0x000000010ea409b0, Pointer=0x00007fff5fbfbfb0, Loc=0x00007fff5fbfb178, isLoad=true, StartBB=0x000000010e695b00, Result=0x00007fff5fbfd0e0, Visited=0x00007fff5fbfc758, SkipFirstBlock=false) + 8431 at MemoryDependenceAnalysis.cpp:1301
frame #9007: 0x00000001004fd00f opt`llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(this=0x000000010ea409b0, Pointer=0x00007fff5fbfc798, Loc=0x00007fff5fbfc870, isLoad=true, StartBB=0x000000010e695b50, Result=0x00007fff5fbfd0e0, Visited=0x00007fff5fbfc758, SkipFirstBlock=true) + 8431 at MemoryDependenceAnalysis.cpp:1301
frame #9008: 0x00000001004fae3f opt`llvm::MemoryDependenceAnalysis::getNonLocalPointerDependency(this=0x000000010ea409b0, Loc=0x00007fff5fbfc870, isLoad=true, FromBB=0x000000010e695b50, Result=0x00007fff5fbfd0e0) + 367 at MemoryDependenceAnalysis.cpp:876
frame #9009: 0x0000000100f77230 opt`(anonymous namespace)::GVN::processNonLocalLoad(this=0x000000010ea3ff90, LI=0x000000010e696f08) + 192 at GVN.cpp:1711
frame #9010: 0x0000000100f73cb8 opt`(anonymous namespace)::GVN::processLoad(this=0x000000010ea3ff90, L=0x000000010e696f08) + 1432 at GVN.cpp:1905
frame #9011: 0x0000000100f72f3f opt`(anonymous namespace)::GVN::processInstruction(this=0x000000010ea3ff90, I=0x000000010e696f08) + 367 at GVN.cpp:2227
frame #9012: 0x0000000100f72b8b opt`(anonymous namespace)::GVN::processBlock(this=0x000000010ea3ff90, BB=0x000000010e695b50) + 251 at GVN.cpp:2402
frame #9013: 0x0000000100f6cc51 opt`(anonymous namespace)::GVN::iterateOnFunction(this=0x000000010ea3ff90, F=0x0000000104ccc170) + 1361 at GVN.cpp:2657
frame #9014: 0x0000000100f6c5c2 opt`(anonymous namespace)::GVN::runOnFunction(this=0x000000010ea3ff90, F=0x0000000104ccc170) + 626 at GVN.cpp:2360
frame #9015: 0x0000000100b5429b opt`llvm::FPPassManager::runOnFunction(this=0x000000010ea3e070, F=0x0000000104ccc170) + 427 at LegacyPassManager.cpp:1541
frame #9016: 0x0000000100b545a8 opt`llvm::FPPassManager::runOnModule(this=0x000000010ea3e070, M=0x000000010330bb80) + 104 at LegacyPassManager.cpp:1561
frame #9017: 0x0000000100b54fb4 opt`(anonymous namespace)::MPPassManager::runOnModule(this=0x000000010ea32bb0, M=0x000000010330bb80) + 1412 at LegacyPassManager.cpp:1619
frame #9018: 0x0000000100b5485e opt`llvm::legacy::PassManagerImpl::run(this=0x000000010ea32840, M=0x000000010330bb80) + 302 at LegacyPassManager.cpp:1726
frame #9019: 0x0000000100b55731 opt`llvm::legacy::PassManager::run(this=0x00007fff5fbfec80, M=0x000000010330bb80) + 33 at LegacyPassManager.cpp:1763
frame #9020: 0x000000010003a9d6 opt`main(argc=7, argv=0x00007fff5fbff990) + 12630 at opt.cpp:716
frame #9021: 0x00007fff87ac35c9 libdyld.dylib`start + 1
The guilty party is -std-link-opts ... removing that lets opt run to completion.
Make exits with error
# cmake .. -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD="X86;JSBackend" -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF
# ../configure --enable-optimized --disable-assertions --enable-targets=host,js
# make -j2Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86DisassemblerTables.cpp.o
Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86ModRMFilters.cpp.o
Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86RecognizableInstr.cpp.o
Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CTagsEmitter.cpp.o
make[4]: Leaving directory `/opt/myfastcomp/emscripten-fastcomp/build'
Built target obj.llvm-tblgen
make[4]: Entering directory `/opt/myfastcomp/emscripten-fastcomp/build'
Scanning dependencies of target llvm-tblgen
make[4]: Leaving directory `/opt/myfastcomp/emscripten-fastcomp/build'
make[4]: Entering directory `/opt/myfastcomp/emscripten-fastcomp/build'
Linking CXX executable ../../bin/llvm-tblgen
make[4]: Leaving directory `/opt/myfastcomp/emscripten-fastcomp/build'
Built target llvm-tblgen
make[3]: Leaving directory `/opt/myfastcomp/emscripten-fastcomp/build'
make[2]: Leaving directory `/opt/myfastcomp/emscripten-fastcomp/build/utils/TableGen'
make[1]: Leaving directory `/opt/myfastcomp/emscripten-fastcomp/build/utils'
make: *** [all] Error 1# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS"em++ memcopies objects that are not trivially copyable
This issue was moved from emscripten-core/emscripten#5114
The following code breaks in the line tested = make_tested();. The generated code constructs a Tested object on the stack inside make_tested and then returns the constructed object's data (thereby changing the object's address) without calling a copy constructor. Using the same version of clang but compiling for the target x86_64-apple-darwin15.6.0, the code generated for make_tested instead constructs the object at an address provided by the caller.
The problem disappears when increasing the object's size.
This happens using emscripten-core/emscripten-fastcomp-clang@d4b1e07 and 09aaa02
test.cpp
#include <cassert>
class Tested;
std::vector<Tested*> objects_that_were_constructed;
class Tested
{
public:
Tested() {
objects_that_were_constructed.push_back(this);
}
Tested(const Tested& other) {
objects_that_were_constructed.push_back(this);
}
Tested& operator=(const Tested& other) {
auto constructor_of_other_was_called =
objects_that_were_constructed.end() != std::find(objects_that_were_constructed.begin(), objects_that_were_constructed.end(), &other);
assert(constructor_of_other_was_called);
// Leaving out the actual assignment code, as it's not relevant
return *this;
}
private:
int state0 = 0;
// Uncommenting the following line makes the test work
// int state1 = 0;
};
Tested make_tested()
{
return Tested();
}
int main() {
Tested tested;
tested = make_tested();
return 0;
}
fastcomp compiles llvm.powi to Math_pow
For this LLVM IR:
define double @distance(double* %a, double* %b, i32 %n) {
entry:
br label %loop
loop:
%i = phi i32 [ 0, %entry ], [ %i.next, %loop ]
%sum = phi double [ 0.0, %entry ], [ %sum.next, %loop ]
%m = getelementptr double, double* %a, i32 %i
%o = getelementptr double, double* %b, i32 %i
%x = load double, double* %m
%y = load double, double* %o
%sub = fsub double %x, %y
%pow = call double @llvm.powi.f64(double %sub, i32 2)
%sum.next = fadd double %sum, %pow
%i.next = add i32 %i, 1
%cond = icmp ult i32 %i.next, %n
br i1 %cond, label %loop, label %exit
exit:
%sqrt = call double @llvm.sqrt.f64(double %sum.next)
ret double %sqrt
}
declare double @llvm.sqrt.f64(double)
declare double @llvm.powi.f64(double, i32)
Fastcomp emits a call to Math_pow:
$pow = +(Math_pow(+$sub, +2));
which is suboptimal because an exponent of 2 could be implemented with just a multiply.
In LLVM, the CodeGen handles expanding llvm.powi for obvious small-integer cases, so fastcomp isn't getting this optimization.
Disable OCaml bindings if ctypes >=0.3 is not found
Switching from master to incoming, my emsdk fails to build fastcomp:
-- Found OCaml: /usr/bin/ocamlfind
-- OCaml bindings enabled.
CMake Error at cmake/modules/FindOCaml.cmake:76 (message):
ocamlfind: Package `ctypes' not found
Call Stack (most recent call first):
cmake/config-ix.cmake:533 (find_ocamlfind_package)
CMakeLists.txt:347 (include)
Please either disable OCaml manually or import llvm-mirror/llvm@0245b12 aka SVN r223195, first released in llvm release_36.
LLVM -gvn optimization pass (default-enabled at -O2 and higher) creates an optimization to SIMD that crashes in NaCl ExpandLargeIntegers.cpp.
Build the following file a.cpp
#include <stdio.h>
typedef char __v16qi __attribute__((__vector_size__(16)));
int __attribute__((noinline)) foo(const __v16qi *src)
{
union {
signed short x[8];
__v16qi m;
} S, D;
S.m = (__v16qi)__builtin_shufflevector((__v16qi){ 0LL, 0LL }, (__v16qi)*src, 0, 16+0, 1, 16+1, 2, 16+2, 3, 16+3, 4, 16+4, 5, 16+5, 6, 16+6, 7, 16+7);;
for(int i = 0; i < 8; ++i)
D.x[i] = (signed short)(((int)S.x[i] * (int)S.x[i]) >> 16);
return D.x[0];
}
int main()
{
char __attribute__((aligned(16))) data[16] = { 1, -2, 3, -4, 5, 6, -7, -8, 9, 10, 11, -12, -13, -14, -15, -16 };
int r = foo((const __v16qi *)data);
printf("r: %d\n", r);
}
with em++ a.cpp -o a.js -O2. LLVM will fail with
Unsupported: %1 = bitcast <16 x i8> %shuffle to i128
LLVM ERROR: Instruction not yet supported for integer types larger than 64 bits
that comes from https://github.com/kripken/emscripten-fastcomp/blob/incoming/lib/Transforms/NaCl/ExpandLargeIntegers.cpp#L575 . Building with -O1 or lower avoids the failure. Building with -O1 -gvn passed to opt surfaces the crash. It looks like NaCl should be somehow taught to not get confused with SIMD types in its expand 64-bit to 32-bit hacks?
With EXPORT_ALL=1, fastcomp treats unions as function definitions
Here's a test program that takes the address of a constant global union:
rfk@localhost:test$ cat testunion.c
#include <stdio.h>
struct one_const {
long a;
};
struct two_consts {
long a;
long b;
};
union some_consts {
struct one_const one;
struct two_consts two;
};
union some_consts my_consts = {{
1
}};
struct one_const addr_of_my_consts = {
(long)(&my_consts)
};
int main(void) {
printf("%li\n", addr_of_my_consts.a);
return 0;
}
It works fine under fastcomp with no extra command-line args, like so:
rfk@localhost:test$ emcc -o testunion.js testunion.c
rfk@localhost:test$ js testunion.js
8
But if I add EXPORT_ALL=1 then the address is taken to be zero:
rfk@localhost:test$ emcc -s EXPORT_ALL=1 -o testunion.js testunion.c
warning: unresolved symbol: my_consts
rfk@localhost:test$ js testunion.js
0
I tracked the problem down to this clause in getConstAsOffset:
This initializes the address to zero and emits a postset to fill it in later. Of course since there's no such function, we get an "unresolved symbol" warning and the value stays at zero. The generated testunion.js also gets a little stub like this:
function _my_consts() {
Module['printErr']('missing function: my_consts'); abort(-1);
}
So it looks like something is getting confused here. But I've reached the limits of what I can debug based on my limited knowledge of the new backend.
FWIW the old backend doesn't have this behaviour:
rfk@localhost:test$ EMCC_FAST_COMPILER=0 emcc -s EXPORT_ALL=1 -o testunion.jstunion.c
rfk@localhost:test$ js testunion.js
8
build emscripten-fastcomp from src failed
Stack dump:
0. Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name CGBlocks.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 241.9 -coverage-file /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen/Release/CGBlocks.o -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 -dependency-file /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen/Release/CGBlocks.d.tmp -MP -MT /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen/Release/CGBlocks.o -MT /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen/Release/CGBlocks.d -D NDEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/include -I /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen -I /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/include -I /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/tools/clang/lib/CodeGen -I /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/tools/clang/lib/CodeGen/../../include -I /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen/../../include -stdlib=libc++ -O3 -Wcast-qual -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcovered-switch-default -Wmissing-field-initializers -Wno-comment -pedantic -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen -ferror-limit 19 -fmessage-length 80 -fvisibility-inlines-hidden -stack-protector 1 -mstackrealign -fblocks -fno-rtti -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fno-common -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen/Release/CGBlocks.o -x c++ /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/tools/clang/lib/CodeGen/CGBlocks.cpp
- parser at end of file
- Code generation
- Running pass 'Function Pass Manager' on module '/Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/tools/clang/lib/CodeGen/CGBlocks.cpp'.
- Running pass 'X86 DAG->DAG Instruction Selection' on function '@_ZN5clang7CodeGen15CodeGenFunction12EmitCallArgsINS_17FunctionProtoTypeEEEvRNS0_11CallArgListEPKT_N4llvm14iterator_rangeINS_4Stmt17ConstExprIteratorEEEPKNS_12FunctionDeclEj'
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/j4/r69d7_d96n366ngn89lv53ww0000gn/T/CGBlocks-416eaf.cpp
clang: note: diagnostic msg: /var/folders/j4/r69d7_d96n366ngn89lv53ww0000gn/T/CGBlocks-416eaf.sh
clang: note: diagnostic msg:
rm: /Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen/Release/CGBlocks.d.tmp: No such file or directory
make[4]: *** [/Users/hezhiwu/Desktop/emscriptenSVN_incoming/myfastcomp/emscripten-fastcomp/build/tools/clang/lib/CodeGen/Release/CGBlocks.o] Error 1
make[3]: *** [CodeGen/.makeall] Error 2
make[3]: *** Waiting for unfinished jobs....
add_dependencies called with incorrect number of arguments
Commandline:
cmake .. -DCMAKE_BUILD_TYPE=MinSizeRel -DLLVM_TARGETS_TO_BUILD="X86;JSBackend" -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFFErrormessage:
CMake Error at lib/Target/JSBackend/MCTargetDesc/CMakeLists.txt:5 (add_dependencies):
add_dependencies called with incorrect number of argumentsVersions:
cmake --version # 2.8.12.2
cmake --version # 2.8.11.2 doesn't work with this version either (just tested)Building without 'JSBackend' returns no errors
Included other failed tests:
-- Performing Test CXX_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG
-- Performing Test CXX_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG - Failed
-- Performing Test C_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG
-- Performing Test C_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG - Failed
-- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG
-- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - FailedSystem:
Ubuntu 12.04 (elementaryOS) 32bit
VMWareMy steps:
https://gist.github.com/tomsiwik/9364480#file-webcl-translator-sh
Thanks in advance :)
OptParserEmitter compliler errors with g++ 4.8
I did a pull on master and started getting these compiler errors with g++ 4.8. I used make clean and tried again and still get them. Thank you for any help on this. PS I also tried updating from 4.8.1 to 4.8.2 (on Ubuntu)
some tests fail when building under WSL (Ubuntu on Windows)
WSL is Microsoft's new Ubuntu subsystem for Windows 10. That's what I'm building this under.
uname -a says:
Linux CRIMSON 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
All failures except one are in Transforms, all but four are in Transforms/NaCl
********************
Testing Time: 438.18s
********************
Failing Tests (82):
LLVM :: Transforms/BBVectorize/simple.ll
LLVM :: Transforms/InstCombine/vec_shuffle.ll
LLVM :: Transforms/LoopVectorize/interleaved-accesses.ll
LLVM :: Transforms/NaCl/add-pnacl-external-decls.ll
LLVM :: Transforms/NaCl/atomic/atomic-seq-cst-only.ll
LLVM :: Transforms/NaCl/atomic/atomic_others.ll
LLVM :: Transforms/NaCl/atomic/atomic_seq_cst.ll
LLVM :: Transforms/NaCl/atomic/fetch_and_.ll
LLVM :: Transforms/NaCl/atomic/lock_.ll
LLVM :: Transforms/NaCl/atomic/sync_synchronize.ll
LLVM :: Transforms/NaCl/atomic/val_compare_and_swap.ll
LLVM :: Transforms/NaCl/atomic/volatile.ll
LLVM :: Transforms/NaCl/canonicalize-mem-intrinsics.ll
LLVM :: Transforms/NaCl/cleanup-used-globals-metadata.ll
LLVM :: Transforms/NaCl/combine-shuffle-vector.ll
LLVM :: Transforms/NaCl/constant-insert-extract-element-index.ll
LLVM :: Transforms/NaCl/constant-vector-rematerialization.ll
LLVM :: Transforms/NaCl/expand-arith-with-overflow.ll
LLVM :: Transforms/NaCl/expand-byval.ll
LLVM :: Transforms/NaCl/expand-constantexpr.ll
LLVM :: Transforms/NaCl/expand-ctors-empty.ll
LLVM :: Transforms/NaCl/expand-ctors-emptylist.ll
LLVM :: Transforms/NaCl/expand-ctors-zeroinit.ll
LLVM :: Transforms/NaCl/expand-ctors.ll
LLVM :: Transforms/NaCl/expand-getelementptr.ll
LLVM :: Transforms/NaCl/expand-indirectbr.ll
LLVM :: Transforms/NaCl/expand-integers.ll
LLVM :: Transforms/NaCl/expand-shuffle-vector.ll
LLVM :: Transforms/NaCl/expand-small-arguments.ll
LLVM :: Transforms/NaCl/expand-struct-regs.ll
LLVM :: Transforms/NaCl/expand-tls-aligned.ll
LLVM :: Transforms/NaCl/expand-tls-bss.ll
LLVM :: Transforms/NaCl/expand-tls-constexpr-alias.ll
LLVM :: Transforms/NaCl/expand-tls-constexpr.ll
LLVM :: Transforms/NaCl/expand-tls-constexpr2.ll
LLVM :: Transforms/NaCl/expand-tls-phi.ll
LLVM :: Transforms/NaCl/expand-tls.ll
LLVM :: Transforms/NaCl/expand-varargs-attrs.ll
LLVM :: Transforms/NaCl/expand-varargs-emscripten.ll
LLVM :: Transforms/NaCl/expand-varargs-struct.ll
LLVM :: Transforms/NaCl/expand-varargs.ll
LLVM :: Transforms/NaCl/fix-vector-load-store-alignment.ll
LLVM :: Transforms/NaCl/flatten-globals.ll
LLVM :: Transforms/NaCl/globalcleanup.ll
LLVM :: Transforms/NaCl/globalize-constant-vectors.ll
LLVM :: Transforms/NaCl/internalize-used-globals.ll
LLVM :: Transforms/NaCl/life.ll
LLVM :: Transforms/NaCl/normalize-alignment.ll
LLVM :: Transforms/NaCl/pnacl-abi-internalize-symbols-pso.ll
LLVM :: Transforms/NaCl/pnacl-abi-internalize-symbols.ll
LLVM :: Transforms/NaCl/pnacl-abi-simplify-postopt.ll
LLVM :: Transforms/NaCl/pnacl-abi-simplify-preopt.ll
LLVM :: Transforms/NaCl/pnacl-abi-simplify.ll
LLVM :: Transforms/NaCl/pnacl-eh-exception-info.ll
LLVM :: Transforms/NaCl/pnacl-sjlj-eh-bug.ll
LLVM :: Transforms/NaCl/pnacl-sjlj-eh.ll
LLVM :: Transforms/NaCl/promote-i1-ops.ll
LLVM :: Transforms/NaCl/promote-integer-signatures.ll
LLVM :: Transforms/NaCl/promote-integers.ll
LLVM :: Transforms/NaCl/remove-asm-memory.ll
LLVM :: Transforms/NaCl/replace-ptrs-with-ints.ll
LLVM :: Transforms/NaCl/resolve-aliases.ll
LLVM :: Transforms/NaCl/resolve-pnacl-intrinsics-lock-free.ll
LLVM :: Transforms/NaCl/resolve-pnacl-intrinsics.ll
LLVM :: Transforms/NaCl/rewrite-assume.ll
LLVM :: Transforms/NaCl/rewrite-call-with-libfunc-argument.ll
LLVM :: Transforms/NaCl/rewrite-flt-rounds.ll
LLVM :: Transforms/NaCl/rewrite-libcalls-wrong-signature.ll
LLVM :: Transforms/NaCl/rewrite-longjmp-no-store.ll
LLVM :: Transforms/NaCl/rewrite-longjmp-noncall-uses.ll
LLVM :: Transforms/NaCl/rewrite-memfuncs-no-store.ll
LLVM :: Transforms/NaCl/rewrite-memfuncs-noncall-uses.ll
LLVM :: Transforms/NaCl/rewrite-prefetch.ll
LLVM :: Transforms/NaCl/rewrite-setjmp-store-error.ll
LLVM :: Transforms/NaCl/rewrite-setlongjmp-calls.ll
LLVM :: Transforms/NaCl/simplify-allocas.ll
LLVM :: Transforms/NaCl/simplify-struct-reg-signatures.ll
LLVM :: Transforms/NaCl/strip-attributes.ll
LLVM :: Transforms/NaCl/strip-branchweight-metadata.ll
LLVM :: Transforms/NaCl/strip-meta-leaves-debug.ll
LLVM :: Transforms/NaCl/strip-tbaa-metadata.ll
LLVM-Unit :: Support/SupportTests/TargetRegistry.TargetHasArchType
Expected Passes : 15361
Expected Failures : 129
Unsupported Tests : 134
Unexpected Failures: 82
make[3]: *** [CMakeFiles/check-all] Error 1
make[2]: *** [CMakeFiles/check-all.dir/all] Error 2
make[1]: *** [CMakeFiles/check-all.dir/rule] Error 2
make: *** [check-all] Error 2
rjstone@CRIMSON:~/emscripten-fastcomp/build$
ldc / D language port
Trying to build the ldc compiler for the D language against llvm-emscripten (as a first step to D->asmjs compilation).
ldc builds fine against vanilla llvm 3.5.0, 3.6.0, 3.7.0.
However, when building ldc against master branch of emscripten-fastcomp, I get errors:
$ make
[ 0%] Built target impcnvgen
[ 0%] Built target idgen
[ 0%] Building CXX object CMakeFiles/LDCShared.dir/gen/arrays.cpp.o
In file included from /home/ace/source/ldc/./gen/irstate.h:20:0,
from /home/ace/source/ldc/gen/arrays.cpp:19:
/home/ace/source/ldc/./ir/irfunction.h:130:45: error: ‘DILocalVariable’ is not a member of ‘llvm’
typedef llvm::DenseMap<VarDeclaration*, llvm::DILocalVariable*> VariableMap;
^
/home/ace/source/ldc/./ir/irfunction.h:130:45: error: ‘DILocalVariable’ is not a member of ‘llvm’
/home/ace/source/ldc/./ir/irfunction.h:130:67: error: template argument 2 is invalid
typedef llvm::DenseMap<VarDeclaration*, llvm::DILocalVariable*> VariableMap;
^
/home/ace/source/ldc/./ir/irfunction.h:130:67: error: template argument 4 is invalid
In file included from /home/ace/source/ldc/./gen/irstate.h:23:0,
from /home/ace/source/ldc/gen/arrays.cpp:19:
/home/ace/source/ldc/./gen/dibuilder.h:77:15: error: ‘DILocalVariable’ in namespace ‘llvm’ does not name a type
typedef llvm::DILocalVariable* DILocalVariable;
^
In file included from /home/ace/source/ldc/./gen/irstate.h:23:0,
from /home/ace/source/ldc/gen/arrays.cpp:19:
/home/ace/source/ldc/./gen/dibuilder.h:192:57: error: ‘ldc::DILocalVariable’ has not been declared
void Declare(const Loc &loc, llvm::Value var, ldc::DILocalVariable divar
^
CMakeFiles/LDCShared.dir/build.make:1631: recipe for target 'CMakeFiles/LDCShared.dir/gen/arrays.cpp.o' failed
make[2]: ** [CMakeFiles/LDCShared.dir/gen/arrays.cpp.o] Error 1
CMakeFiles/Makefile2:61: recipe for target 'CMakeFiles/LDCShared.dir/all' failed
make[1]: *** [CMakeFiles/LDCShared.dir/all] Error 2
Makefile:146: recipe for target 'all' failed
make: *** [all] Error 2
It seems like emscripten-fastcomp reports an llvm version of 3.7.0svn but doesn't declare some symbols which were introduced in llvm version 3.7.0, like DILocalVariable.
The ldc source code relies on version numbers to enable, using #if/#else, some parts of the code.
How can I re-align emscripten declarations to the official llvm branch?
Would it be a good idea?
How to update to LLVM 3.5?
Attempt to merge LLVM git master
I took a stab at merging llvm and clang from the git mirror master branches into the emscripten-fastcomp/clang repos. I resolved the conflicts and made a few changes which can be viewed here: https://github.com/ricejasonf/emscripten-fastcomp/commit/c24408dd6635bb5d3cbf8b913e0e778bb3ea10a5
It's mostly just name changes and whitespace stuff plus a minor change to the use of a StringRef in a warning and the elimination of CodeGenInfo which is apparently not used anymore in TargetMachine (I could be very wrong).
The fastcomp stuff with the changes compiles and emscripten's test_hello_world passes, but some tests do not pass for example test_dynamic_cast:
test_dynamic_cast (test_core.default) ... (checking sanity from test runner)
INFO:root:(Emscripten: Running sanity checks)
(test did not pass in JS engine: ['/usr/bin/nodejs'])
ERROR
======================================================================
ERROR: test_dynamic_cast (test_core.default)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/local/src/emscripten/tests/test_core.py", line 1730, in test_dynamic_cast
self.do_run_from_file(src, output)
File "/usr/local/src/emscripten/tests/runner.py", line 601, in do_run_from_file
includes, force_c, build_ll_hook, extra_emscripten_args)
File "/usr/local/src/emscripten/tests/runner.py", line 635, in do_run
raise e
Exception: Expected to find 'f()
' in '5
Invalid function pointer called with signature 'viiiiii'. Perhaps this is an invalid value (e.g. caused by calling a virtual method on a NULL pointer)? Or calling a function with an incorrect type, which will fail? (it is worth building your source files with -Werror (warnings are errors), as warnings can indicate undefined behavior which can cause this)
Build with ASSERTIONS=2 for more info.
5
It is also worth mentioning that when emscripten was generating system libraries I got several warnings like the following:
WARNING:root:generating system library: dlmalloc.bc...
/usr/local/src/emscripten/system/lib/dlmalloc.c:617:5: warning: macro expansion producing 'defined' has
undefined behavior [-Wexpansion-to-defined]
#if USE_LOCKS /* Spin locks for gcc >= 4.1, older gcc on x86, MSC >= 1310 */
^
/usr/local/src/emscripten/system/lib/dlmalloc.c:613:22: note: expanded from macro 'USE_LOCKS'
#define USE_LOCKS ((defined(USE_SPIN_LOCKS) && USE_SPIN_LOCKS != 0) || \
I'd like to figure out if any of the changes that I made are causing this, (The CodeGenInfo thing is suspicious) or if perhaps there are necessary changes I need to make in the emscripten repo.
Any help is greatly appreciated. Thank you.
Update the NaCl code?
I just ran into a very nasty bug with the NaCl/SimplifyStructRegSignatures pass that didn't remove the pure attribute (its real name is readnone I think) from functions after changing their signatures to not be pure anymore. This ended up causing a lot of test failures in the Rust tests suite.
It turns out this bug is already fixed in the PNaCl repository.
It would be nice to eventually update the emscripten code to be up-to-date with NaCl. I'm not familiar enough with how all this works to do this myself (I received a lot of help from folks on IRC just to diagnose the problem).
EMCC_FAST_COMPILER=0 does not work
Hello,
on my config (Ubuntu 13.10 Linux 3.11 64 bits), setting EMCC_FAST_COMPILER to 0 does not disable fastcomp: I still get fastcomp related warnings for exceptions.
However, unsetting the variable like this:
unset EMCC_FAST_COMPILER
works just fine and fastcomp is not used anymore.
I think this is not the documented behavior:
https://github.com/kripken/emscripten/wiki/LLVM-Backend
Regards,
remove Transforms/NaCl and other unit tests
@kripken says these can be ignored and should probably be removed so they don't cause confusion.
uname -a says:
Linux CRIMSON 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
All failures except one are in Transforms, all but four are in Transforms/NaCl
********************
Testing Time: 438.18s
********************
Failing Tests (82):
LLVM :: Transforms/BBVectorize/simple.ll
LLVM :: Transforms/InstCombine/vec_shuffle.ll
LLVM :: Transforms/LoopVectorize/interleaved-accesses.ll
LLVM :: Transforms/NaCl/add-pnacl-external-decls.ll
LLVM :: Transforms/NaCl/atomic/atomic-seq-cst-only.ll
LLVM :: Transforms/NaCl/atomic/atomic_others.ll
LLVM :: Transforms/NaCl/atomic/atomic_seq_cst.ll
LLVM :: Transforms/NaCl/atomic/fetch_and_.ll
LLVM :: Transforms/NaCl/atomic/lock_.ll
LLVM :: Transforms/NaCl/atomic/sync_synchronize.ll
LLVM :: Transforms/NaCl/atomic/val_compare_and_swap.ll
LLVM :: Transforms/NaCl/atomic/volatile.ll
LLVM :: Transforms/NaCl/canonicalize-mem-intrinsics.ll
LLVM :: Transforms/NaCl/cleanup-used-globals-metadata.ll
LLVM :: Transforms/NaCl/combine-shuffle-vector.ll
LLVM :: Transforms/NaCl/constant-insert-extract-element-index.ll
LLVM :: Transforms/NaCl/constant-vector-rematerialization.ll
LLVM :: Transforms/NaCl/expand-arith-with-overflow.ll
LLVM :: Transforms/NaCl/expand-byval.ll
LLVM :: Transforms/NaCl/expand-constantexpr.ll
LLVM :: Transforms/NaCl/expand-ctors-empty.ll
LLVM :: Transforms/NaCl/expand-ctors-emptylist.ll
LLVM :: Transforms/NaCl/expand-ctors-zeroinit.ll
LLVM :: Transforms/NaCl/expand-ctors.ll
LLVM :: Transforms/NaCl/expand-getelementptr.ll
LLVM :: Transforms/NaCl/expand-indirectbr.ll
LLVM :: Transforms/NaCl/expand-integers.ll
LLVM :: Transforms/NaCl/expand-shuffle-vector.ll
LLVM :: Transforms/NaCl/expand-small-arguments.ll
LLVM :: Transforms/NaCl/expand-struct-regs.ll
LLVM :: Transforms/NaCl/expand-tls-aligned.ll
LLVM :: Transforms/NaCl/expand-tls-bss.ll
LLVM :: Transforms/NaCl/expand-tls-constexpr-alias.ll
LLVM :: Transforms/NaCl/expand-tls-constexpr.ll
LLVM :: Transforms/NaCl/expand-tls-constexpr2.ll
LLVM :: Transforms/NaCl/expand-tls-phi.ll
LLVM :: Transforms/NaCl/expand-tls.ll
LLVM :: Transforms/NaCl/expand-varargs-attrs.ll
LLVM :: Transforms/NaCl/expand-varargs-emscripten.ll
LLVM :: Transforms/NaCl/expand-varargs-struct.ll
LLVM :: Transforms/NaCl/expand-varargs.ll
LLVM :: Transforms/NaCl/fix-vector-load-store-alignment.ll
LLVM :: Transforms/NaCl/flatten-globals.ll
LLVM :: Transforms/NaCl/globalcleanup.ll
LLVM :: Transforms/NaCl/globalize-constant-vectors.ll
LLVM :: Transforms/NaCl/internalize-used-globals.ll
LLVM :: Transforms/NaCl/life.ll
LLVM :: Transforms/NaCl/normalize-alignment.ll
LLVM :: Transforms/NaCl/pnacl-abi-internalize-symbols-pso.ll
LLVM :: Transforms/NaCl/pnacl-abi-internalize-symbols.ll
LLVM :: Transforms/NaCl/pnacl-abi-simplify-postopt.ll
LLVM :: Transforms/NaCl/pnacl-abi-simplify-preopt.ll
LLVM :: Transforms/NaCl/pnacl-abi-simplify.ll
LLVM :: Transforms/NaCl/pnacl-eh-exception-info.ll
LLVM :: Transforms/NaCl/pnacl-sjlj-eh-bug.ll
LLVM :: Transforms/NaCl/pnacl-sjlj-eh.ll
LLVM :: Transforms/NaCl/promote-i1-ops.ll
LLVM :: Transforms/NaCl/promote-integer-signatures.ll
LLVM :: Transforms/NaCl/promote-integers.ll
LLVM :: Transforms/NaCl/remove-asm-memory.ll
LLVM :: Transforms/NaCl/replace-ptrs-with-ints.ll
LLVM :: Transforms/NaCl/resolve-aliases.ll
LLVM :: Transforms/NaCl/resolve-pnacl-intrinsics-lock-free.ll
LLVM :: Transforms/NaCl/resolve-pnacl-intrinsics.ll
LLVM :: Transforms/NaCl/rewrite-assume.ll
LLVM :: Transforms/NaCl/rewrite-call-with-libfunc-argument.ll
LLVM :: Transforms/NaCl/rewrite-flt-rounds.ll
LLVM :: Transforms/NaCl/rewrite-libcalls-wrong-signature.ll
LLVM :: Transforms/NaCl/rewrite-longjmp-no-store.ll
LLVM :: Transforms/NaCl/rewrite-longjmp-noncall-uses.ll
LLVM :: Transforms/NaCl/rewrite-memfuncs-no-store.ll
LLVM :: Transforms/NaCl/rewrite-memfuncs-noncall-uses.ll
LLVM :: Transforms/NaCl/rewrite-prefetch.ll
LLVM :: Transforms/NaCl/rewrite-setjmp-store-error.ll
LLVM :: Transforms/NaCl/rewrite-setlongjmp-calls.ll
LLVM :: Transforms/NaCl/simplify-allocas.ll
LLVM :: Transforms/NaCl/simplify-struct-reg-signatures.ll
LLVM :: Transforms/NaCl/strip-attributes.ll
LLVM :: Transforms/NaCl/strip-branchweight-metadata.ll
LLVM :: Transforms/NaCl/strip-meta-leaves-debug.ll
LLVM :: Transforms/NaCl/strip-tbaa-metadata.ll
LLVM-Unit :: Support/SupportTests/TargetRegistry.TargetHasArchType
Expected Passes : 15361
Expected Failures : 129
Unsupported Tests : 134
Unexpected Failures: 82
make[3]: *** [CMakeFiles/check-all] Error 1
make[2]: *** [CMakeFiles/check-all.dir/all] Error 2
make[1]: *** [CMakeFiles/check-all.dir/rule] Error 2
make: *** [check-all] Error 2
rjstone@CRIMSON:~/emscripten-fastcomp/build$
How to integrate JSBackend with clang & llvm
I want to study JSBackend, if it produces JS source from llvm ir.
How to integrate and study[reference to any docs or something] JSBackend with llvm, clang without using Emscripten.
Use of logical or with constant operand.
Whenever I update to a newer version, I see this warning:
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:288:46: warning:
use of logical '||' with constant operand [-Wconstant-logical-operand]
unsigned Alignment = F->getAlignment() || 1; // XXX this is wrong...
^ ~
/Users/jjylanki/emsdk_git/clang/fastcomp/src/lib/Target/JSBackend/JSBackend.cpp:288:46: note:
use '|' for a bitwise operation
unsigned Alignment = F->getAlignment() || 1; // XXX this is wrong...
llc failure "LLVM ERROR: Stores must be a multiple of 8 bits" with WASM ASYNCIFY DEMANGLE_SUPPORT and DISABLE_EXCEPTION_CATCHING=0
Hi
Hopefully got the right component for reporting this. I'm getting a strange llc failure with an unholy combination of WASM ASYNCIFY DEMANGLE_SUPPORT and DISABLE_EXCEPTION_CATCHING=0.
Short log output is below and I've attached the most minimal example I can trim down along with an EMCC_DEBUG=1 output in the archive. Moving everything in to one source file seems to stop it, hence the couple of cpp files and one header.
It seems to be related to usage of boost::lexical_cast. I haven't included boost in the archive, as lexical_cast seems to require most of it...
em++ Main.cpp Test.cpp -o Main.html -std=c++11 -s ASYNCIFY=1 -O3 -s WASM=1 -s DEMANGLE_SUPPORT=1 -s DISABLE_EXCEPTION_CATCHING=0 -I /path/to/boost_1_63_0
fastcomp revision: dcde7043f5b94d5ad166347ab4cb9f3e3e0ff6ac
Thanks
Luke.
wasm-demangle-exception-catching.tar.gz
LLVM ERROR: Stores must be a multiple of 8 bits
Traceback (most recent call last):
File "C:\Program Files\Emscripten\emscripten\incoming\\em++", line 16, in <module>
emcc.run()
File "C:\Program Files\Emscripten\emscripten\incoming\emcc.py", line 1647, in run
final = shared.Building.emscripten(final, append_ext=False, extra_args=extra_args)
File "C:\Program Files\Emscripten\emscripten\incoming\tools\shared.py", line 1745, in emscripten
call_emscripten(cmdline)
File "C:\Program Files\Emscripten\emscripten\incoming\emscripten.py", line 1836, in _main
temp_files.run_and_clean(lambda: main(
File "C:\Program Files\Emscripten\emscripten\incoming\tools\tempfiles.py", line 78, in run_and_clean
return func()
File "C:\Program Files\Emscripten\emscripten\incoming\emscripten.py", line 1841, in <lambda>
DEBUG=DEBUG,
File "C:\Program Files\Emscripten\emscripten\incoming\emscripten.py", line 1742, in main
temp_files=temp_files, DEBUG=DEBUG)
File "C:\Program Files\Emscripten\emscripten\incoming\emscripten.py", line 91, in emscript
funcs, metadata, mem_init = get_and_parse_backend(infile, settings, temp_files, DEBUG)
File "C:\Program Files\Emscripten\emscripten\incoming\emscripten.py", line 167, in get_and_parse_backend
start_funcs = backend_output.index(start_funcs_marker)
ValueError: substring not found
how can we be sure we're using fastcomp?
Hello,
when I used emscripten-fastcomp the first time, I saw some warnings related to my version of clang not being the required one. Yet I'm pretty sure I followed the documentation available here:
https://github.com/kripken/emscripten/wiki/LLVM-Backend
That documentation also states that fastcomp will automatically fallback to the "old" compiler:
This means that if you use another build of LLVM - like an older one you built yourself, or one from your linux distro's repos, etc. - it will not contain fastcomp. Emscripten should then fall back to the old compiler.
So I have two questions:
- did I really dream that warning or is it displayed only "sometimes"? If so, how can I check if it's still there?
- how can I be absolutely sure fastcomp is used during compilation?
Thanks!
Unsupported constant kind in JSWriter::getConstant
Hi,
I've been trying to get Emscripten to generate JS from some custom IR that is not generated by Clang. Right now it fails code generation in the JS backend.
; ModuleID = 'WriteLine'
%System.String = type { i8*, i8* }
@0 = global [13 x i8] c"Hello, World!"
declare void @System_Void_System_Console__WriteLine_System_String_(%System.String)
declare void @System_Void_System_Console__WriteLine_System_Int32_(i32)
define void @System_Void_Program__Main__() {
call void @System_Void_System_Console__WriteLine_System_String_(%System.String { i8* inttoptr (i64 13 to i8*), i8* getelementptr inbounds ([13 x i8]* @0, i32 0, i32 0) })
ret void
}
define i32 @main() {
call void @System_Void_Program__Main__()
ret i32 0
}
With a debug build it's possible to get a backtrace:
D:\emscripten-fastcomp\build\bin\Debug>llc -march=js -filetype=asm WriteLine.ll
warning: incorrect target triple '' (did you use emcc/em++ on all source files and not clang directly?)
%System.String { i8* inttoptr (i64 13 to i8*), i8* getelementptr inbounds ([13 x i8]* @0, i32 0, i32 0) }
Unsupported constant kind
UNREACHABLE executed at D:\emscripten-fastcomp\lib\Target\JSBackend\JSBackend.cpp:1074!
Stack dump:
0. Program arguments: llc -march=js -filetype=asm WriteLine.ll
1. Running pass 'JavaScript backend' on module 'WriteLine.ll'.
0x0F46A16A (0x0000000A 0x00000000 0x014DC824 0x00C8C249), exit() + 0x13A bytes(s)
0x0F5547BC (0x015E21B8 0x014DCC3C 0x0022B712 0x0108EDB8), abort() + 0x1C bytes(s)
0x00C8C249 (0x0108EDB8 0x0108ED78 0x00000432 0x014DCCD4), llvm::llvm_unreachable_internal() + 0x89 bytes(s), d:\emscripten-fastcomp\lib\support\errorhandling.cpp, line 98 + 0x8 byte(s)
0x0022B712 (0x014DCCB0 0x015E2C80 0x00000000 0x015E2C80), `anonymous namespace'::JSWriter::getConstant() + 0x972 bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 1076
0x0022B7FB (0x014DCCB0 0x015E2C80 0x00000000 0x014DD040), `anonymous namespace'::JSWriter::getValueAsStr() + 0x4B bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 1083 + 0x14 byte(s)
0x0022BA7F (0x014DCDD0 0x015E2C80 0x0000000A 0x014DD170), `anonymous namespace'::JSWriter::getValueAsCastParenStr() + 0x9F bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 1118 + 0x12 byte(s)
0x00268469 (0x014DD09C 0x015E21B8 0x015F36F8 0x015F3D20), `anonymous namespace'::JSWriter::CH___default__() + 0x829 bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\callhandlers.h, line 135 + 0x829 byte(s)
0x00295DF1 (0x014DD6EC 0x015E21B8 0x014DEA50 0x015E21B8), `anonymous namespace'::JSWriter::handleCall() + 0x241 bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\callhandlers.h, line 1062 + 0x2E byte(s)
0x0023474B (0x015E21B8 0x014DEA08 0x014DF078 0x014DF3B0), `anonymous namespace'::JSWriter::generateExpression() + 0x2ADB bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 1614
0x0022F4B1 (0x015DFB38 0x014DF034 0x014DF01C 0x014DF158), `anonymous namespace'::JSWriter::addBlock() + 0xB1 bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 1700
0x0022F708 (0x015E2090 0x014DF330 0x01CCCCCC 0xCCCCCCCC), `anonymous namespace'::JSWriter::printFunctionBody() + 0xD8 bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 1725
0x0022952B (0x015E2090 0x014DF3A4 0x014DF3B0 0xCCCCCCCC), `anonymous namespace'::JSWriter::printFunction() + 0x2AB bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 1932
0x00235804 (0x015E54F0 0x014DF350 0x0022923E 0x014DF364), `anonymous namespace'::JSWriter::printModuleBody() + 0xC4 bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 1946
0x00229266 (0x014DF364 0x014DF380 0x015E54F0 0x014DF3A4), `anonymous namespace'::JSWriter::printModule() + 0x16 bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 2379
0x0022923E (0x014DF364 0x014DF380 0x014DF46C 0x015E1DB8), `anonymous namespace'::JSWriter::printProgram() + 0x1E bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 2374
0x002291EB (0x015D8B18 0x014DF8D8 0x014DF478 0x00000000), `anonymous namespace'::JSWriter::runOnModule() + 0xBB bytes(s), d:\emscripten-fastcomp\lib\target\jsbackend\jsbackend.cpp, line 2391 + 0x2A byte(s)
0x00A88BD9 (0x015D8B18 0x014DF4BC 0x7EFDE000 0xCCCCCCCC), llvm::MPPassManager::runOnModule() + 0x1C9 bytes(s), d:\emscripten-fastcomp\lib\ir\passmanager.cpp, line 1608 + 0x17 byte(s)
0x00A891F1 (0x015D8B18 0x014DF5D4 0x014DF8D8 0x000D5BF9), llvm::PassManagerImpl::run() + 0x101 bytes(s), d:\emscripten-fastcomp\lib\ir\passmanager.cpp, line 1703 + 0x1B byte(s)
0x00A87C1D (0x015D8B18 0x014DF928 0x00000000 0xCCCCCCCC), llvm::PassManager::run() + 0x1D bytes(s), d:\emscripten-fastcomp\lib\ir\passmanager.cpp, line 1739
0x000D5BF9 (0x015D1BF8 0x015CE4F8 0x00000000 0xCCCCCCCC), compileModule() + 0x1109 bytes(s), d:\emscripten-fastcomp\tools\llc\llc.cpp, line 378
0x000D6347 (0x00000004 0x015D1BF8 0x015CCBD8 0x33051FDF), main() + 0xE7 bytes(s), d:\emscripten-fastcomp\tools\llc\llc.cpp, line 195 + 0xD byte(s)
0x00CDC249 (0x014DF98C 0x75B533AA 0x7EFDE000 0x014DF9CC), __tmainCRTStartup() + 0x199 bytes(s), f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 536 + 0x19 byte(s)
0x00CDC38D (0x7EFDE000 0x014DF9CC 0x77EB9F72 0x7EFDE000), mainCRTStartup() + 0xD bytes(s), f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 377
0x75B533AA (0x7EFDE000 0x7877C3FA 0x00000000 0x00000000), BaseThreadInitThunk() + 0x12 bytes(s)
0x77EB9F72 (0x00CDC380 0x7EFDE000 0x00000000 0x00000000), RtlInitializeExceptionChain() + 0x63 bytes(s)
0x77EB9F45 (0x00CDC380 0x7EFDE000 0x00000000 0x00000000), RtlInitializeExceptionChain() + 0x36 bytes(s)
The problem is the usage of an LLVM ConstantStruct in the IR which the Emscripten LLVM JS backend does not know how to deal with.
Is it feasible to implement support for this in the backend?
Reference: xen2/SharpLang#6
Aliases metadata is always empty
Both aliases.ll and global-aliases.ll define aliases with global linkage, but when running llc on either file, the "aliases" section of metadata is {}
This is related to some upstream libc compatibility issues, where Emscripten refers to symbols defined in libc headers, but the definition of those functions is implemented as an alias. Fastcomp successfully resolves the aliases internally, but Emscripten is then unable to reference the aliases.
Broken module error compiling JSMESS
/0/home/dfjustin/jsmess/third_party/emscripten/emcc -O3 -s DISABLE_EXCEPTION_CATCHING=2 -s TOTAL_MEMORY=33554432 -s EXCEPTION_CATCHING_WHITELIST='["__ZN15running_machine17start_all_devicesEv"]' -s EXPORTED_FUNCTIONS="['_main', '_malloc', '__Z14js_get_machinev', '__Z9js_get_uiv', '__Z12js_get_soundv', '__ZN10ui_manager12set_show_fpsEb', '__ZNK10ui_manager8show_fpsEv', '__ZN13sound_manager4muteEbh', 'SDL_PauseAudio']" /0/home/dfjustin/jsmess/third_party/mame/messjaguar.bc -o /0/home/dfjustin/jsmess/build/jaguar/messjaguar.js --pre-js /0/home/dfjustin/jsmess/templates/default/pre.js --post-js /0/home/dfjustin/jsmess/templates/default/post.js
Wrong types for attribute: byval nest noalias nocapture sret
i32 (%class.chd_file.9385*, i8*, i32, i32, i32, i32*, %class.chd_file.9385*)* @_ZN8chd_file6createEPKcyjPjRS_
Broken module found, compilation aborted!
0 opt 0x0000000000ccb4a5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37
1 opt 0x0000000000ccb883
2 libpthread.so.0 0x00002b288b81ecb0
3 libc.so.6 0x00002b288c67f445 gsignal + 53
4 libc.so.6 0x00002b288c682bab abort + 379
5 opt 0x0000000000c8b7f3
6 opt 0x0000000000c8b5f6
7 opt 0x0000000000c7810a llvm::FPPassManager::runOnFunction(llvm::Function&) + 314
8 opt 0x0000000000c782fb llvm::FPPassManager::runOnModule(llvm::Module&) + 59
9 opt 0x0000000000c7857a llvm::MPPassManager::runOnModule(llvm::Module&) + 378
10 opt 0x0000000000c78e6c llvm::PassManagerImpl::run(llvm::Module&) + 444
11 opt 0x0000000000c791fa llvm::PassManager::run(llvm::Module&) + 10
12 opt 0x00000000004f8360 main + 7392
13 libc.so.6 0x00002b288c66a76d __libc_start_main + 237
14 opt 0x00000000004f3965
Stack dump:
0. Program arguments: /0/./home/dfjustin/emscripten-fastcomp/build/Release/bin/opt /tmp/tmpOZ97Sr/messjaguar.bc -strip-debug -internalize -internalize-public-api-list=main,malloc,_Z14js_get_machinev,_Z9js_get_uiv,_Z12js_get_soundv,_ZN10ui_manager12set_show_fpsEb,_ZNK10ui_manager8show_fpsEv,_ZN13sound_manager4muteEbh,DL_PauseAudio,free,malloc,free,emscripten_GetProcAddress -globaldce -pnacl-abi-simplify-preopt -pnacl-abi-simplify-postopt -enable-emscripten-cxx-exceptions -emscripten-cxx-exceptions-whitelist=__ZN15running_machine17start_all_devicesEv -o /tmp/tmpOZ97Sr/messjaguar.bc.opt.bc
1. Running pass 'Function Pass Manager' on module '/tmp/tmpOZ97Sr/messjaguar.bc'.
2. Running pass 'Module Verifier' on function '@_ZN8chd_file6createEPKcyjPjRS_'
Traceback (most recent call last):
File "/0/home/dfjustin/jsmess/third_party/emscripten/emcc", line 1490, in <module>
shared.Building.llvm_opt(final, link_opts)
File "/0/home/dfjustin/jsmess/third_party/emscripten/tools/shared.py", line 1173, in llvm_opt
assert os.path.exists(target), 'Failed to run llvm optimizations: ' + output
AssertionError: Failed to run llvm optimizations:
make: *** [/0/home/dfjustin/jsmess/build/jaguar/messjaguar.js] Error 1
Is juj's pthreads still alive and kicking?
After some time of inactivity I am trying to revive my attempt on porting JamVM to Emscripten.
I just want to know whether the development of pthreads support in Emscripten is still continued or whether focus/effor will be shifting towards WebAssembly now.
I know this question should rather be posted on juj's repository, but there is no Issue tracker there.
Thanks!
Assertion failure at ExpandI64.cpp:626 building JSMESS
I saw exceptions have been added so I tried building JSMESS with fastcomp (maybe prematurely). The following output results:
/home/dfjustin/jsmess_vitorio/third_party/emscripten/emcc -O2 -s DISABLE_EXCEPTION_CATCHING=0 -s ALIASING_FUNCTION_POINTERS=1 -s OUTLINING_LIMIT=20000 -s TOTAL_MEMORY=33554432 -s EXPORTED_FUNCTIONS="['_main', '_malloc', '__Z15ui_set_show_fpsi', '__Z15ui_get_show_fpsv']" /home/dfjustin/jsmess_vitorio/third_party/mame/messcoleco.bc -o /home/dfjustin/jsmess_vitorio/build/coleco/messcoleco.js --pre-js /home/dfjustin/jsmess_vitorio/templates/default/pre.js --post-js /home/dfjustin/jsmess_vitorio/templates/default/post.js
Warning: Variable __init_array_start not referenced
Warning: Variable __init_array_end not referenced
Warning: Variable __fini_array_start not referenced
Warning: Variable __fini_array_end not referenced
SplitArgs.find(V) != SplitArgs.end()
/home/dfjustin/emscripten-fastcomp/lib/Transforms/NaCl/ExpandI64.cpp : 626
LLVM ERROR: fail
Traceback (most recent call last):
File "/home/dfjustin/jsmess_vitorio/third_party/emscripten/emcc", line 1758, in <module>
shared.Building.llvm_opt(final, link_opts)
File "/home/dfjustin/jsmess_vitorio/third_party/emscripten/tools/shared.py", line 1179, in llvm_opt
assert os.path.exists(target), 'Failed to run llvm optimizations: ' + output
AssertionError: Failed to run llvm optimizations:
make: *** [/home/dfjustin/jsmess_vitorio/build/coleco/messcoleco.js] Error 1
emcc build halts
Hey,
When using the fastcomp compiler, for some reason, the build halts immediately after trying to run the first command:
Creating obj/emscripten-stat/__pch/haxe/hxcpp.h.gch...
emcc -Iinclude -c -fvisibility=hidden -fpic -fPIC -DEMSCRIPTEN -Wno-parentheses -Wno-null-dereference -Wno-unused-value -Wno-format-extra-args -Wno-bool-conversion -Wno-warn-absolute-paths -DSTATIC_LINK -DHXCPP_VISIT_ALLOCS -I/home/joshua/Development/Haxe/hxlibc/include -frtti -x c++-header -o obj/emscripten-stat/__pch/haxe/hxcpp.h.gch /home/joshua/Development/Haxe/hxlibc/include/hxcpp.h
We get a little bit more information, the first time after pulling the latest source:
Creating obj/emscripten-stat/__pch/haxe/hxcpp.h.gch...
emcc -Iinclude -c -fvisibility=hidden -fpic -fPIC -DEMSCRIPTEN -Wno-parentheses -Wno-null-dereference -Wno-unused-value -Wno-format-extra-args -Wno-bool-conversion -Wno-warn-absolute-paths -DSTATIC_LINK -DHXCPP_VISIT_ALLOCS -I/home/joshua/Development/Haxe/hxlibc/include -frtti -x c++-header -o obj/emscripten-stat/__pch/haxe/hxcpp.h.gch /home/joshua/Development/Haxe/hxlibc/include/hxcpp.h
WARNING root: (Emscripten: system change: 1.13.2|i386-pc-linux-gnu|/home/joshua/Development/Emscripten/emscripten-fastcomp/build/bin|3.3 vs 1.12.2|i386-pc-linux-gnu|/home/joshua/Development/Emscripten/emscripten-fastcomp/build/bin|3.3, clearing cache)
ERROR root: Emscripten, llvm and clang versions do not match, this is dangerous (1.13.2, 1.12.2, 1.12.2)
ERROR root: Make sure to use the same branch in each repo, and to be up-to-date on each. See https://github.com/kripken/emscripten/wiki/LLVM-Backend
INFO root: (Emscripten: Running sanity checks)
Is there any simple way to get more information about where or why it stops compilation?
Assertion in JSBackend/Relooper.cpp during linking
When compiling a project with fastcomp emscripten I'm getting the following assertion during linking:
../lib/Target/JSBackend/Relooper.cpp:152: void Block::AddBranchTo(Block*, const char*, const char*): Assertion `!contains(BranchesOut, Target)' failed.
The code was compiling fine with the older emscripten setup. Any reason for the assertion?
Here is the assert output including the command line:
/home/kostas/develop/prj/cheesy/ext/emscripten/em++ -s TOTAL_MEMORY=268435456 -g -s TOTAL_MEMORY=268435456 -g --embed-file /home/kostas/develop/prj/cheesy/shooter/../assets/run@/ shooter/CMakeFiles/Shooter.dir/src/core/World.cpp.o shooter/CMakeFiles/Shooter.dir/src/ui/MainUI.cpp.o shooter/CMakeFiles/Shooter.dir/src/Construct.cpp.o shooter/CMakeFiles/Shooter.dir/src/AudioPlayer.cpp.o shooter/CMakeFiles/Shooter.dir/src/util/GameUtils.cpp.o shooter/CMakeFiles/Shooter.dir/src/boot/GameApp.cpp.o shooter/CMakeFiles/Shooter.dir/src/boot/glfw/GLFWPlatform.cpp.o shooter/CMakeFiles/Shooter.dir/src/boot/glfw/main.cpp.o shooter/CMakeFiles/Shooter.dir/src/entity/Sprite.cpp.o shooter/CMakeFiles/Shooter.dir/src/entity/SpriteLayer.cpp.o -o Shooter.html -rdynamic libEngine.a libExt.a && :
llc: ../lib/Target/JSBackend/Relooper.cpp:152: void Block::AddBranchTo(Block*, const char*, const char*): Assertion `!contains(BranchesOut, Target)' failed.
0 llc 0x0000000000df67ef
1 llc 0x0000000000df6a6c
2 llc 0x0000000000df64ef
3 libpthread.so.0 0x00007fe92192d880
4 libc.so.6 0x00007fe920b73389 gsignal + 57
5 libc.so.6 0x00007fe920b74788 abort + 328
6 libc.so.6 0x00007fe920b6c4a6
7 libc.so.6 0x00007fe920b6c552
8 llc 0x00000000005a2701
9 llc 0x00000000005821ce
10 llc 0x0000000000582df5
11 llc 0x0000000000582f4d
12 llc 0x0000000000585412
13 llc 0x00000000005853ef
14 llc 0x000000000058550d
15 llc 0x0000000000cfa3de
16 llc 0x0000000000cfa9d4
17 llc 0x0000000000cfabdf
18 llc 0x00000000004076dd
19 llc 0x0000000000406756
20 libc.so.6 0x00007fe920b5fb05 __libc_start_main + 245
21 llc 0x00000000004060a9
Stack dump:
0. Program arguments: /home/kostas/develop/prj/cheesy/ext/emscripten-fastcomp/build-linux/bin/llc /tmp/tmpGCwvfL/Shooter.bc -march=js -filetype=asm -o /tmp/tmp94wqa2.4.js -emscripten-assertions=1 -O0
1. Running pass 'JavaScript backend' on module '/tmp/tmpGCwvfL/Shooter.bc'.
Thanks
Build is broken: Undefined symbol llvm::createExpandInsertExtractElementPass
Fresh build from current incoming:
[1180/1704] Linking CXX shared library lib/libLTO.dylib
FAILED: : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -std=c++11 -fcolor-diagnostics -O3 -DNDEBUG -dynamiclib -Wl,-headerpad_max_install_names -Wl,-dead_strip -Wl,-exported_symbols_list,/Users/bruce/Development/emscripten-fastcomp/build/tools/lto/LTO.exports -o lib/libLTO.dylib -install_name @rpath/libLTO.dylib tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o tools/lto/CMakeFiles/LTO.dir/lto.cpp.o lib/libLLVMX86CodeGen.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86AsmParser.a lib/libLLVMX86Desc.a lib/libLLVMX86Info.a lib/libLLVMX86Disassembler.a lib/libLLVMJSBackendCodeGen.a lib/libLLVMJSBackendDesc.a lib/libLLVMJSBackendInfo.a lib/libLLVMLTO.a lib/libLLVMMC.a lib/libLLVMMCDisassembler.a lib/libLLVMSupport.a lib/libLLVMX86CodeGen.a lib/libLLVMAsmPrinter.a lib/libLLVMSelectionDAG.a lib/libLLVMX86Desc.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a lib/libLLVMX86Info.a lib/libLLVMMCDisassembler.a lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMLinker.a lib/libLLVMObjCARCOpts.a lib/libLLVMipo.a lib/libLLVMScalarOpts.a lib/libLLVMInstCombine.a lib/libLLVMProfileData.a lib/libLLVMObject.a lib/libLLVMMCParser.a lib/libLLVMBitReader.a lib/libLLVMVectorize.a lib/libLLVMTransformUtils.a lib/libLLVMipa.a lib/libLLVMAnalysis.a lib/libLLVMTarget.a lib/libLLVMMC.a lib/libLLVMCore.a lib/libLLVMSupport.a -lcurses -lpthread -lz -lm -Wl,-rpath,@executable_path/../lib && :
Undefined symbols for architecture x86_64:
"llvm::createExpandInsertExtractElementPass()", referenced from:
llvm::JSTargetMachine::addPassesToEmitFile(llvm::legacy::PassManagerBase&, llvm::formatted_raw_ostream&, llvm::TargetMachine::CodeGenFileType, bool, void const*, void const*) in libLLVMJSBackendCodeGen.a(JSBackend.cpp.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I suspect @jfbastien.
unresolved symbol on exceptions
Hello,
I'm using emscripten (incoming) with emscripten-fastcomp (incoming) and I get an error at linkage. Here is the full command line:
/home/promethe/Projects/minko/tools/lin/scripts/emcc.sh bin/html5/release/minko-example-frustum.bc -o bin/html5/release/minko-example-frustum.html -O2 --closure 1 -s CLOSURE_ANNOTATIONS=1 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s DISABLE_EXCEPTION_CATCHING=0 -s TOTAL_MEMORY=268435456 --preload-file bin/html5/release/asset || bash /home/promethe/Projects/minko/tools/lin/scripts/fail.sh bin/html5/release/minko-example-frustum.bc
/opt/emscripten/emcc bin/html5/release/minko-example-frustum.bc
INFO root: =======================================
INFO root: bootstrapping relooper...
INFO root: bootstrap phase 1
INFO root: bootstrap phase 2
INFO root: bootstrapping relooper succeeded
INFO root: =======================================
error: unresolved symbol: _ZNSt9exceptionD0Ev
aborting from js compiler due to exception: Aborting compilation due to previous errors | undefined
Traceback (most recent call last):
File "/opt/emscripten/emscripten.py", line 1405, in <module>
_main(environ=os.environ)
File "/opt/emscripten/emscripten.py", line 1393, in _main
temp_files.run_and_clean(lambda: main(
File "/opt/emscripten/tools/tempfiles.py", line 39, in run_and_clean
return func()
File "/opt/emscripten/emscripten.py", line 1401, in <lambda>
DEBUG_CACHE=DEBUG_CACHE,
File "/opt/emscripten/emscripten.py", line 1288, in main
jcache=jcache, temp_files=temp_files, DEBUG=DEBUG, DEBUG_CACHE=DEBUG_CACHE)
File "/opt/emscripten/emscripten.py", line 185, in emscript
assert '//FORWARDED_DATA:' in out, 'Did not receive forwarded data in pre output - process failed?'
AssertionError: Did not receive forwarded data in pre output - process failed?
Traceback (most recent call last):
File "/opt/emscripten/emcc", line 1525, in <module>
final = shared.Building.emscripten(final, append_ext=False, extra_args=extra_args)
File "/opt/emscripten/tools/shared.py", line 1276, in emscripten
assert os.path.exists(filename + '.o.js') and len(open(filename + '.o.js', 'r').read()) > 0, 'Emscripten failed to generate .js: ' + str(compiler_output)
AssertionError: Emscripten failed to generate .js:
Post-build command failed for project bin/html5/release/minko-example-cube.bc
So the problem seems to be entirely related to exception.
What am I doing wrong?
Thanks for the amazing work! It's incredible to see close to 1 million LOC now compiling to fast into js...
New warnings in JSTargetMachine: getSubtargetImpl
There are new warnings about getSubtargetImpl overrides / hiding in JSTargetMachine.
LLVM configure does not work
I'm trying to build the latest Emscripten-LLVM+Clang on a Linux (Ubuntu 12.04) host. I cloned the master branch from emscripten-fastcomp and the master branch from emscripten-fastcomp-clang into tools/clang.
Then I created a build-directory and run ../configure --enable-optimized --disable-assertions --enable-targets=host,js in it. The output is the following: https://gist.github.com/ma0ho/f71632fbbbfe7b5116aa .
I'm wondering about checking for clang... no. And finally it ends with config.status: error: cannot find input file: ../tools/clang/include/clang/Config/config.h.in. The path should be ../tools/clang/include/llvm/clang/Config/config.h.in.
As I said before, I clone the master branch for both, llvm and Clang. Therefore it should not be a version conflict, right?
noise on stderr
I need to interpret my emsciptified program's output (it's llvm-as and I'd like to parse the error messages)
Currently, Module.printErr is a bit noisy, I am getting messages like
pre-main prep time: 5 ms
Calling stub instead of sigprocmask()
...
is there a way to get the program's stderr output without the added messages by emscripten's runtime?
Logical error performed by the Optimization of double to float conversion.
Hi,
I am Alexandre and have been working with Emscripten for a little while and I am quite impressed to the capabilities of Emscripten. We have been working on prototyping a port of the Wwise sound engine to Emscripten. So far so good.
(Currently using \1.29.0 straight from the installer as my Emscripten environment.)
I have been investigating on an issue that was initially blamed to be caused by a rounding error on a Float32 type variable. (internally js will use doubles)
It was clear from the start that this was caused by optimizations -O1 -O2 or -O3, and it is already sorted out that specifying -s PRECISE_F32=1 or --llvm-opts 0 do make the problem go away.
Understanding that we wanted to preserve the optimizations we proceeded to pad the code against bad rounding and imprecisions, but I ended up on this:
The simplified behavior I am witnessing is the following:
//////////////////////////////////////////////////////////////////////////////////////////////
// Pseudo code representation of the error of the compiler:
// Don’t try this one, to get real repro you need fValueB to be a parameter inside a struct of the
// function passed in reference.
//////////////////////////////////////////////////////////////////////////////////////////////
double dblVal = 0.99999999362240710177;
float fValueA = dblVal;
float fValueB = fValueA;
if (fValueA == fValueB)
printf("Values are the same\n");
if (fValueA >= 1.f)
printf("A >=1 \n");
if (fValueB >= 1.f)
printf("B >=1 \n");
//////////////////////////////////////////////////////////////////////////////////////////////
I understand the passing of double to float can make a rounding inaccuracy and taht fValueA and fValueB could be >=1 after conversion.
But then surprisingly I get:
-------OUTPUT:---------
Values are the same
B >= 1
My understanding is that the optimizer made two optimizations, each one was valid separately, but not if both was done because they were self invalidating.
Optimization 1: the double is never used and is only assigned to floatA, so we can consider is the same value.
Optimization 2: the floatB is same as the floatA
But then the optimizer preserved floatA in the double world and kept supposing floatB was in the float world because the format was enforced by the type that was passed in reference to the function, which was an illegal assumption since then float A was not same as floatB anymore.
The conversions from double to float that was supposed to be executed on the line:
float fValueA = dblVal;
But optimization did not think it mattered and only made it in the floatB.
And the real code to repro the problem is the following, but it needs some more repro stepd to repro it:
//////////////////////////////////////////////////////////////////////////////////////////////
//File main.cpp
//////////////////////////////////////////////////////////////////////////////////////////////
# include <emscripten.h>
static unsigned int uiPreventIfOptimizeValue = 0;
struct StructToFillContainingPhase
{
float fPhase;
};
// This function is asking to fill a value passed in reference (the phase)
// it also Ensure phase is in range [ 0 <= phase < 1 ]
inline void GenerateValueLessThanOne( StructToFillContainingPhase& io_myStructToFill )
{
float fNewPhase = 0;
```
// In my original problem, I did not have any double, only floats.
// But for the purpose of reproing this bug in a smaller setup, i enforced the usage of a double explicitely.
volatile double dblAlexValue = 0.0;
if (uiPreventIfOptimizeValue == 0 )
{
// This is my trick to force the compiler to optimize the computations without considering dblAlexValue as a constant number, since it appears to fix the issue.
// dblAlexValue must be non deterministically initialized to the exact value I need to repro the problem.
dblAlexValue = 0.99999999362240710177;
}
// I identified the following line to be the culprit of a bad decision of the optimization is doing.
// the non-optimized version does it right and there is no bug.
// My belief is that the optimization thinks fNewPhase = dblAlexValue is a pointless operation and can be ignored, but a transformation from double to float does cause change in data.
// There might(will) be some loss of precision.
// This loss of precision is accepted and legal and we have to live with it.
// But the decision of the compiler does (only when optimizing) to believe this assignation is facultative and that fNewPhase and dblAlexValue are the same value is illegal and to not perform the other assignation "io_myStructToFill.fPhase" later will be fatal.
fNewPhase = dblAlexValue;
printf("dblAlexValue : %.20f\n", dblAlexValue); // will print 0.99999999362240710177
printf("fNewPhase : %f\n", fNewPhase); // will print 1.000000
// I also made sure that fNewPhase hex value is exactly 0x3F800000, which is very very exactly 1.0f
// printf("fNewPhase : %.20f\n", fNewPhase);
// unsigned int * pREK = reinterpret_cast<unsigned int*>(&fNewPhase);
// printf("%8x\n", *pREK);
// And here comes the problem, the assignation: "fNewPhase = dblAlexValue" was not done yet or the machine is in fact using the registry dblAlexValue instead of fNewPhase here
// Ensure phase is in range [ 0 <= phase < 1 ]
while (fNewPhase >= 1.f)
{
// never passes here.
fNewPhase -= 1.f;
}
if (fNewPhase < 0.f || fNewPhase >= 1.f)
{
// This printf will not print. is ok.
printf("This would be impossible\n");
}
//assert( fNewPhase >= 0.f && fNewPhase < 1.f ); // will not assert
if (fNewPhase < 0.f || fNewPhase >= 1.f) // checking opposite condition. just in case
{
// will not print
printf("The Assert should have complained\n");// will not assert
}
// Here we assign the float to the value that neded to be filled, a float,
io_myStructToFill.fPhase = fNewPhase;
if (io_myStructToFill.fPhase >= 1.f)// Here again, the system is making the if on the wrong value!
{
// will Print!!!!!!!!!!!
printf("Last line of the function Call GenerateValueLessThanOne() : io_myStructToFill.fPhase %f\n", io_myStructToFill.fPhase);
}
if (fNewPhase >= 1.f)// Here again, the system is making the if on the wrong value!
{
// will not print
printf("Last line of the function Call GenerateValueLessThanOne() : fNewPhase %f\n", fNewPhase);
}
```
}
static void main_loop()
{
// Note here that StructToFillContainingPhase is a structure that contains a float.
// If it was simply a float, there would be no repro.
StructToFillContainingPhase MyStructToFill;
GenerateValueLessThanOne( MyStructToFill );
if (MyStructToFill.fPhase >= 1.f)
{
// Detect the error and Bail out.
printf("The function provided me an illegal value\n");
emscripten_cancel_main_loop();
}
}
int main( int argc, char *argv[] )
{
emscripten_set_main_loop(main_loop, 0, false);
```
return 0;
```
}
//////////////////////////////////////////////////////////////////////////////////////////////
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.